Depth buffer detection modifications

Thanks mate : )

The settings didn't work at first, but when I changed the vsync to adaptive vsync instead of double buffer it magically worked Very happy now, also because my titanfall 2 tools are finally done so screenshotting WITH DoF is always better than without

OtisInf wrote: Thanks mate : )

The settings didn't work at first, but when I changed the vsync to adaptive vsync instead of double buffer it magically worked Very happy now, also because my titanfall 2 tools are finally done so screenshotting WITH DoF is always better than without

You're welcome Didn't thought vsync settings could have an impact (i own a gsync monitor)... Glad i could help you

thalixte wrote: Sorry to hear that, but my modifs only concist in retrieving the existing depth buffer, not modifying it. Maybe you could ask Marty Mc Fly to help you in this way

You can ignore the RE4 issues I posted, I just didn't have the preprocessor settings for MXAO right.

I haven't had a chance to play very far into RE4 yet, but after correcting the settings it seems to be working very well aside from cutscenes; the depth buffer access appears to stop during most of them for some reason. The codec calls never work; MXAO's debug view just shows a while screen until the scene is over. The view out the window as Leon approaches the first house also doesn't work. On the other hand, when the truck is being driven off the cliff at the start and when Leon runs into the house after being swarmed, AO works. Not sure why some realtime scenes behave differently than others.

Otherwise, the game seems to be crashing on my fairly frequently. Has anyone else tested RE4 and had this issue?

@thalixte it turned out to be the adaptive resolution shit they have in the game. If I set it to '60' it works, if I set it to another value (e.g. 0 to turn it completely off) it doesn't. Very odd, but alas, better this than nothing. The depth buffer captured can be a bit different than the framebuffer, as they appear to render models differently in this one, but I'll manage

OtisInf wrote: @thalixte it turned out to be the adaptive resolution shit they have in the game. If I set it to '60' it works, if I set it to another value (e.g. 0 to turn it completely off) it doesn't. Very odd, but alas, better this than nothing. The depth buffer captured can be a bit different than the framebuffer, as they appear to render models differently in this one, but I'll manage

Ok, good to know

Here are two new dlls:
d3d9_32bits.zip
d3d9_64bits.zip

Those new files introduce two new settings (only for directx9):
The first one allows you to select the flag clearing number, aka. the flag used by the game to specify what type of depthStencilSurface it tries to clear. This setting can help avoiding artefacts in game when depth map is breaked. Its default value is 6 (the value that works for most of the games i tested).

The second one adds the ability to remove the test that forces the Reshade library to only retrieve depth textures that fit the dimensions of the viewport. It is necessary to disable this test in games like Vanquish, because the depth texture is embedded in a 4096x4096 square

So with this new 32bit dll, Vanquish has a working depth buffer if you disable the "restrict depth buffer dimensions to viewport" checkbox

thalixte wrote: Those new files introduce two new settings (only for directx9):
The first one allows you to select the flag clearing number, aka. the flag used by the game to specify what type of depthStencilSurface it tries to clear. This setting can help avoiding artefacts in game when depth map is breaked. Its default value is 6 (the value that works for most of the games i tested).

Is the new "DepthBufferClearingFlagNumber" setting expected to affect the original "Post-processing" retrieval method? It seems to cause visual glitches where they were absent before. I'll do more detailed testing in the evening today.

conan2k wrote: Is the new "DepthBufferClearingFlagNumber" setting expected to affect the original "Post-processing" retrieval method? It seems to cause visual glitches where they were absent before. I'll do more detailed testing in the evening today.

No, the DepthBufferClearingFlagNumber setting only affects the "Before clearing stage" retrieval mode. If you select "Post process", it does not use this setting.

Will change my code in order to hide this setting if "Post process" retrievial mode is set, so you won't be disturbed by it. Thks for the feedback.

Have you tried to do a reload after changing to "Post process" retrieval mode ?

MXAO is flicking is Resident evil revelations 1.
Do you can have fix depth buffer in this game ?

Chavolatra wrote: MXAO is flicking is Resident evil revelations 1.
Do you can have fix depth buffer in this game ?

Why are you using thalixte’s custom dll? That game has always had depth buffer access and works perfectly.

thalixte wrote: Here are two new dlls:
d3d9_32bits.zip
d3d9_64bits.zip

Those new files introduce two new settings (only for directx9):
The first one allows you to select the flag clearing number, aka. the flag used by the game to specify what type of depthStencilSurface it tries to clear. This setting can help avoiding artefacts in game when depth map is breaked. Its default value is 6 (the value that works for most of the games i tested).

The second one adds the ability to remove the test that forces the Reshade library to only retrieve depth textures that fit the dimensions of the viewport. It is necessary to disable this test in games like Vanquish, because the depth texture is embedded in a 4096x4096 square

So with this new 32bit dll, Vanquish has a working depth buffer if you disable the "restrict depth buffer dimensions to viewport" checkbox

Great work, thanks a lot! Played a bit and it seemed fine at first. After a while black shapes started to occur randomly that I couldn't manage to get rid of with different settings. Wonder if it's just a side effect of the unusual texture format.

Uncle Crassius wrote:

thalixte wrote: Here are two new dlls:
d3d9_32bits.zip
d3d9_64bits.zip

Those new files introduce two new settings (only for directx9):
The first one allows you to select the flag clearing number, aka. the flag used by the game to specify what type of depthStencilSurface it tries to clear. This setting can help avoiding artefacts in game when depth map is breaked. Its default value is 6 (the value that works for most of the games i tested).

The second one adds the ability to remove the test that forces the Reshade library to only retrieve depth textures that fit the dimensions of the viewport. It is necessary to disable this test in games like Vanquish, because the depth texture is embedded in a 4096x4096 square

So with this new 32bit dll, Vanquish has a working depth buffer if you disable the "restrict depth buffer dimensions to viewport" checkbox

Great work, thanks a lot! Played a bit and it seemed fine at first. After a while black shapes started to occur randomly that I couldn't manage to get rid of with different settings. Wonder if it's just a side effect of the unusual texture format.

Did you test in post processing mode ?

New version hides Depth buffer clearing flag number setting if "Post process" retrieval mode is set:

thalixte wrote: Did you test in post processing mode ?

Tested in both modes with different settings for flags and clearing. Failed to mention that the sixth clearing (or the sixth other setting, tried both) wouldn't work and always switched back to default.

Uncle Crassius wrote:

thalixte wrote: Did you test in post processing mode ?

Tested in both modes with different settings for flags and clearing. Failed to mention that the sixth clearing (or the sixth other setting, tried both) wouldn't work and always switched back to default.

Ok. It is normal that sixth mode return to default, as default clearing flag is 6.

thalixte wrote:

Uncle Crassius wrote:

thalixte wrote: Did you test in post processing mode ?

Tested in both modes with different settings for flags and clearing. Failed to mention that the sixth clearing (or the sixth other setting, tried both) wouldn't work and always switched back to default.

Ok. It is normal that sixth mode return to default, as default clearing flag is 6.

Ah, haha, makes sense, then, thanks for clearing that up.

Uncle Crassius wrote:
Ah, haha, makes sense, then, thanks for clearing that up.

Yes

So, changed the "Depth buffer clearing flag number" dropdown list, in order to make it clearer. Removed the default value, and replaced it with "None" value (remove the filter on the flag number). Default value is still 6.

Strange for Vanquish. Just tested it, and did not see any artifact, except if i do not filter the clearing number (white square due to some HUD texture)...Note that if you specify a specific clearing number, and choose MXAO, some MXAO stuff can remain in cinematics, because the last good depth buffer texture is still used (EDIT: fixed in the last version)...

thalixte wrote:

conan2k wrote: Have you tried to do a reload after changing to "Post process" retrieval mode ?

No. I thought that Depth Buffer Retrieval-related settings don't require a reload when changed. Does your question mean that the reload is actually required in some specific situations?

conan2k wrote: No. I thought that Depth Buffer Retrieval-related settings don't require a reload when changed. Does your question mean that the reload is actually required in some specific situations?

Yes, that's what i meant. Normally, changing the depth buffer detection settings should not need a reload...

@Uncle Crassius, could you test Vanquish with this new one ?
d3d9_32bits.zip
d3d9_64bits.zip

The settings i use:
[DEPTH_BUFFER_DETECTION]
DepthBufferRetrievalMode=1
DepthBufferClearingNumber=3
DepthBufferTextureFormat=0
DepthBufferClearingFlagNumber=6
RestrictDepthBufferDimensions=0

thalixte wrote:

conan2k wrote: No. I thought that Depth Buffer Retrieval-related settings don't require a reload when changed. Does your question mean that the reload is actually required in some specific situations?

Yes, that's what i meant. Normally, changing the depth buffer detection settings should not need a reload...

@Uncle Crassius, could you test Vanquish with this new one ?
d3d9_32bits.zip
d3d9_64bits.zip

The settings i use:
[DEPTH_BUFFER_DETECTION]
DepthBufferRetrievalMode=1
DepthBufferClearingNumber=3
DepthBufferTextureFormat=0
DepthBufferClearingFlagNumber=6
RestrictDepthBufferDimensions=0

Played for over an hour and works like a charm. Didn't even change any settings, just changed the dll. You are now officially my hero.

Tested Styx 1 (Unreal Engine 3.x, - game own Ambient Occlusion, Motion Blur and Depth of Field all disabled) and the result is always the same: DB is correctly retrieved (see Display Depth) with "Third" or "Fourth" but MXAO gives this result:

(and the player character shadow is erratic - in the screenshot there's no shadow at all)