3.1

Elex was recently updated with a temporal anti-aliasing method. (Curiously they refer to both SMAA T2X which does exist and FXAA T2X which I don't think exists unless they added a custom temporal solution to FXAA 3.11 for this.) Could be that it's interfering but that would only be if this is used and TAA tends to show up more as jittering from what I've tested.

EDIT: And after a quick test then yeah even with the custom SpecialK ReShade it shows up as a uniform color, well that can't be too difficult to track down.

EDIT: Yeah UI interference, toggling off the HUD first resolves it.

farm5.staticflickr.com/4730/39240441062_fc1c1fb2b9_o.jpg

farm5.staticflickr.com/4685/39240440662_10e8c2b53a_o.jpg

UI off, depth buffer clearly visible. Done via the debug keys which well it took a while to track down the new address for the patch for the debug key activator again. I haven't played the game in some time now waiting for updates first.

Anyways, moving on.
farm5.staticflickr.com/4684/39269195551_2e7e927547_o.jpg

farm5.staticflickr.com/4601/39240440292_def677d71a_o.jpg

UI on, depth buffer is, well it's off due to some screen overlay likely from one of the UI shaders.


EDIT:

Test.rar
www37.zippyshare.com/v/J9vhhIzi/file.html

That's the modified .CE table file for Cheat Engine for toggling the debug keys on, CTRL+H toggles the HUD if these are enabled, CTRL+Insert toggles free camera and there's quite a few others found in the ConfigDefault.XML file which lists all of them and their (default and modifiable.) key bindings.

Or in plain text and saved as a .CE file it's.

<?xml version="1.0" encoding="utf-8"?>
<CheatTable CheatEngineTableVersion="0">
<CheatEntries>
<CheatEntry>
<ID>0</ID>
<Description>"Debug Keys"</Description>
<LastState Value="1" RealAddress="140DC9888"/>
<VariableType>Byte</VariableType>
<Address>140DC9888</Address>
</CheatEntry>
</CheatEntries>
</CheatTable>

Just that.
(Steam version of the game, static address so likely not compatible with GOG and earlier versions.)
(This might work for those: www.reddit.com/r/elex/comments/78or21/enable_debug_keys_ingame/ )

Hello I have problem with MXAO and DoF (probably something with depth). They work perfect in Asasins Creed Black Flag till I increase "enviroment detail" from low to normal, then they start working like random, as I rotate with camera and move they enable and disable..

UPDATE: I barely fixed this with multisampled AA (2x and more) but it doesnt work 100%, needs your update.

OtisInf wrote: Ok, found the depth buffer selection issue and how to fix it. The main issue is that the current code looks like it's based on an engine mainly rendering on the immediate context. However those days are over, more and more gets done using deferred contexts in parallel or using indirect rendering using compute shaders. The problem in the current code is that it is single threaded: all calls doing a draw end up in on_draw_call in the runtime which is marked as a critical section with a mutex, forcing all threads going through it one by one, on top of that also pulling information from the GPU/driver state which could cause a stall. Also, it's not to be said the 'active depthstencil' as pulled from the API state in a deferred context is the current one, it's a deferred context after all, the state is to be determined when the command list is executed, or am I mistaken in this?

....

I've now implemented this, see PR: github.com/crosire/reshade/pull/38 hopefully it's OK and it can be merged :) Cheers!

JBeckman wrote: Elex was recently updated with a temporal anti-aliasing method. (Curiously they refer to both SMAA T2X which does exist and FXAA T2X which I don't think exists unless they added a custom temporal solution to FXAA 3.11 for this.) Could be that it's interfering but that would only be if this is used and TAA tends to show up more as jittering from what I've tested.

EDIT: And after a quick test then yeah even with the custom SpecialK ReShade it shows up as a uniform color, well that can't be too difficult to track down.

EDIT: Yeah UI interference, toggling off the HUD first resolves it.

farm5.staticflickr.com/4730/39240441062_fc1c1fb2b9_o.jpg

farm5.staticflickr.com/4685/39240440662_10e8c2b53a_o.jpg

Thanks JB Damn, the HUD is kind of useful! Especially bringing up inventory etc. I guess there's no work around to do both

With the above change from OtisInf it might be possible to get at the depth buffer depending on how the game works with the UI shaders and whatever overlay is possible blocking depth detection when the HUD elements are visible.

I looked into it a bit but this game is one of those that gets a little bit unstable when you poke around with the shaders during runtime, mostly a problem with compute shaders (AC: Origins, don't toggle the shader controlling draw distance, it'll kill the game and likely crash the display driver as framerate goes to zero. ) but some games have quirks with how the regualr pixel and vertex shaders are managed.

In fact this might be usable for a number of games although how the depth buffer is handled or culled by some titles can still be a problem.
(Some games clearing it after X frames for example or you only have some partial depth information such as the first-person hands and gun models.)

Going to require some testing though hopefully it can work for a number of games though it'll depend on what's blocking depth detection.
(Games like Nier Automata and AC Origins where ReShade periodically grabs the wrong one will at least be resolvable now, games where some overlay is blocking depth might be a bigger hurdle however.)

I don't think engines work like that. They might have multiple depth buffers for multiple actions, like 3D scenes and the overlays on top of them, lights etc. Some have the same resolution as the screen, others aren't. That reshade picked the wrong one at times in some games comes from the fact it collected drawcalls based on some functions and ignored others, which led to some depth buffers receive less calls collected on them than there actually were. Resulting in the wrong one being picked at times.

I dont have nier automata nor elex so I can't test it whether it solves it, but at least with the change reshade gets a more accurate view on how many drawcalls are made using which buffer so selecting one based on screen resolution + # of drawcalls is then resulting in the better pick in many (if not all) cases. Vertices counting is done too but the drawcalls which were ignored in 3.1 don't have a vertex count (as it's coming from the compute shader) so it's not likely that's going to be a reliable heuristic.

If there are still false positives, we could add an option where the user could pick from either 'drawcalls', 'drawcalls + vertices' or 'vertices' to be used for picking the depthbuffer but I doubt it will be needed. We'll see

Hmm could be, every engine is a bit different after all and to simplify it greatly they kinda do their own things within the confines of the DirectX or OpenGL API which well sometimes things go wrong ha ha, that's beyond the scope of ReShade though how some game engines follow standards, or don't.
(Not that I'm an expert though, it's interesting to read up some more in-depth info on how some of these things work or are implemented however.)

For the game examples I actually used Nier Automata because the issue at least sounds very similar where one of the compute shaders for lighting is sending out a ton of calls which periodically confuses ReShade and you get a sort of bleed effect, similarly though a bit different in scope something that game does with compute shaders just isn't very good thus the whole white screen crash on both AMD and Nvidia GPU's until newer drivers worked around the thing though even that only reduced it but couldn't fully resolve the issue. (Game sold well enough but Square just didn't invest much into patching it.) so if this pull request can tighten up the depth detection routine it should help though it remains to be tested.

Elex is almost certainly a overlay, I would assume it's something akin to maybe the way the HUD is rendered onto the screen and thus why toggling it off via the debug commands just disables the entire thing and the depth buffer is no longer blocked at least with how ReShade picks up on it.

Also something that differs heavily from one engine to another and also between various middleware such as Scaleform I believe used in several Unreal Engine titles among other things. (Hard Reset is a interesting one using a 3D model for the UI elements, that's not too common I believe.)

Whereas for older games it can be scripted through some in-house solution or using texture elements and what not and in other instances it's controlled through some shader routine.
(Almost miss the elaborate textured UI's of old games but those don't scale well to higher display resolutions to say nothing of different aspect ratios.)

I still have a lot more to learn but it should be fun to see how the commit will work in some of these cases, even if it might not help in older titles it might still be useful for forward compatibility with upcoming releases if more games keep using the compute shader system though eventually Vulkan and DirectX 12 might see a increase in usage too and that's going to be a entirely new set of challenges I'm guessing if ReShade has any long term plans for compatibility with these API's.
(No doubt really complicated to implement though, though DX11 isn't going away anytime soon so not a major priority just yet. )

Assassin's Creed Origins should be resolved at least and unlike Nier Automata it also has some really impressive looking environments though Ubisoft didn't implement any Gameworks features so you get a somewhat simpler system for ambient occlusion (SSBC, modified a bit no doubt but probably similar to when it was first used.) so depth dependent shader effects for that, depth of field and what not could be pretty handy.

Assuming other effects like the games temporal AA isn't interfering at least, that can at least be disabled though.
And nothing against Nier Automata for actually playing the game but the environments are pretty flat and devoid of detail whereas for AC Origins Ubisoft had a sizeable team of people going crazy with the various zones in the game ha ha.
(Unsure if it beats the amount of props used in some other open world games but it's impressive even so though for screenshot purposes LOD can be a real pain.)


Well in any case thanks for the detailed explanations of this issue and for the code commit too, hopefully that makes it into 3.1.1 or what the next version will be called whenever that's getting released.

Hi, OtisInf,

I made a year ago a very simple progressive lumasharpen, using the same technique as the TW3 embedded sharpen technique, ie a degressive sharpen strength relying on the depth buffer, that decreases the sharpening strength by steps, according to the distance from the player.
It worked well for TW3, but it did not work for AC Origins. So i presumed there was a problem with the depth buffer detection. I was about to post on this forum, in order to find a solution, when i saw your posts treating the exact same problem. As i had no time to spend on it IRL (and not your competences), i decided to wait and see if you could find a solution to it.
Then, today i cloned your reshade modifications from github, and built it. I must admit it is very impressive !!! A very big thk you for this. It seems to work as intended, and even with ACO AA enabled, depth buffer data are now availables.
Here are some screens to proof that it works:
DisplayDepth shader:

Modified lumasharpen (degressive by steps in debug mode):

Unfortunately, sometimes (for instance, when senu flies above some areas), there should be a miss in the detection algorithm, and the screen goes to full white, or full black (with DisplayDepth Shader), or the gray layers disappears (with my own degressive sharpening shader). It rarely happens, and when it is the case, it is just a flickering.

Except this very little pb, again, a big big thk U for this, and i hope Crosire will commit your updates soon (maybe for a Reshade v3.2.0).

Thanks for testing / feedback! I hope you used the code I committed later this afternoon as the earlier code contained a memory leak

The buffer miss might be caused by the occasional network traffic that's sent by the game on random intervals. Glad it's just a flickering so not a bug somewhere. Do you have Nier automata as well? Or Elex? Could you test it with those games as well?

OtisInf wrote: Thanks for testing / feedback! I hope you used the code I committed later this afternoon as the earlier code contained a memory leak

Yes, i used the latest commit (0252407...)

OtisInf wrote: The buffer miss might be caused by the occasional network traffic that's sent by the game on random intervals. Glad it's just a flickering so not a bug somewhere. Do you have Nier automata as well? Or Elex? Could you test it with those games as well?

I play offline, so i don't know if network traffic can have an effect on the buffer detection.
You know, this flickering is only visible in debug mode. Maybe with an SSAO implementation, it may become visible, but with a sharpening shader it is not, so i don't mind...
Unfortunately, i don't own those two games. But i can test on TW3 or Mass Effect Andromeda, if i find some time to do it

Ok, made the test with TW3. Of course, buffer selection works as there is less buffers used by the game than in ACO.
But, the interesting thing is that i can reproduce the buffer selection fail. It happens when i move the camera in a certain angle, looking at the sky but having some objects in front of the camera, and it does not flickers, but it remains if i do not move the camera.

Here are the screenshots (on those where buffer selection fails, i should see some vertices in another grey scale, but it is not the case):

Prodousier wrote: UPDATE: I barely fixed this with multisampled AA (2x and more) but it doesnt work 100%, needs your update.

thalixte wrote: Ok, made the test with TW3. Of course, buffer selection works as there is less buffers used by the game than in ACO.
But, the interesting thing is that i can reproduce the buffer selection fail. It happens when i move the camera in a certain angle, looking at the sky but having some objects in front of the camera, and it does not flickers, but it remains if i do not move the camera.

Here are the screenshots (on those where buffer selection fails, i should see some vertices in another grey scale, but it is not the case):

Hmm. I'll see if I can reproduce that too next week. Setting a breakpoint here:
github.com/FransBouma/reshade/blob/maste...11_runtime.cpp#L1010
will get hit when it switches to another buffer. It might be in games where no indirect/drawauto calls are issued, a vertex + drawcall count heuristic is perhaps a better deal. This switch can be done automatically (if an indirect / drawauto call is issued, switch to drawcall count only).
The breakpoint at that location could show in the debugger that there are e.g. 2 buffers with equal drawcall count or almost the same drawcall count.

(edit) I can't reproduce it... I look up to the sky (depthbuffer reversed + logarithmic set to 1) and use displaydepth to show the depth buffer, but it's always picking the right one, gerhalt is always visible, things are always OK... while this is of course good, if there's a problem it should show up somehow I think.. You're sure your test is OK and it shows it picks the wrong buffer? As in: display depth shows a black/white screen ?

OtisInf wrote: (edit) I can't reproduce it... I look up to the sky (depthbuffer reversed + logarithmic set to 1) and use displaydepth to show the depth buffer, but it's always picking the right one, gerhalt is always visible, things are always OK... while this is of course good, if there's a problem it should show up somehow I think.. You're sure your test is OK and it shows it picks the wrong buffer? As in: display depth shows a black/white screen ?

Yes, i think my test is OK. But i don't use the same settings as yours (depthbuffer not reversed + logarithmic set to 0), and i made a slight modification in the DisplayDepth shader:
(edit) I made a new test with your settings (depthbuffer reversed + logarithmic set to 1) and the original displaydepth shader, and i was able to reproduce the buffer detection fail. It happens in a certain angle, looking at the sky with Geralt in front, the screen then turn to full black with your settings...

Screenshots:

Just before the fail:

Very slight move to left + very slight move to up:

Ok... Could you test something?

If you change this line:
github.com/FransBouma/reshade/blob/maste...ter_tracker.cpp#L129

with:
if ((depthstencil_info.vertices_count * (1.2f - float(depthstencil_info.drawcall_count) / _drawcalls)) >= (best_info.vertices_count * (1.2f - float(best_info.drawcall_count) / _drawcalls)))

(this is the original test calculation)

Then recompile and use that version in the witcher and see if you can reproduce it with that. If not, the heuristic based solely on drawcall count is not usable in all cases and we need to automatically switch between them.

Is this in a certain location in the witcher 3 or it doesn't matter?

OtisInf wrote: Ok... Could you test something?

If you change this line:
github.com/FransBouma/reshade/blob/maste...ter_tracker.cpp#L129

with:
if ((depthstencil_info.vertices_count * (1.2f - float(depthstencil_info.drawcall_count) / _drawcalls)) >= (best_info.vertices_count * (1.2f - float(best_info.drawcall_count) / _drawcalls)))

(this is the original test calculation)

Then recompile and use that version in the witcher and see if you can reproduce it with that. If not, the heuristic based solely on drawcall count is not usable in all cases and we need to automatically switch between them.

Is this in a certain location in the witcher 3 or it doesn't matter?

So the code is this one, right ?I compiled it, but the screen goes to full black if i enable displaydepth, with your settings... The location doesn't seem to matter...

Hmm, that's strange. Could you create a save game for the witcher3 at the location where you can reproduce it so I can load that savegame and check it out here?
TIA

OtisInf wrote: Hmm, that's strange. Could you create a save game for the witcher3 at the location where you can reproduce it so I can load that savegame and check it out here?
TIA

For sure ! Here it is: TW3 save

(edit) Here are two videos that illustrate the buffer fail. It seems that it happens, in TW3, when the number of vertices drops below a given treshold: TW3 buffer detection videos

Hey guys, I'm using Reshade 3.1 in the Game Transport Fever. It's working OK, except for one thing. When you choose any tool to build roads and tracks you gain a dot in the point of your cursor, it's gray if not connected and blue if connected to a valid node in the network, but, this dot disappear when using Reshade.

I tested and is not any effect, is simple the use of the DLL that causes it to vanish. I tested putting only the DLL in the game folder without any shader.

Can anyone point me to a solution or any way to report what is happening in a way a fix can be made some day?

Thanks.

@thalixte: weird! I load your save file, but everything keeps on working here... No matter what angle I take, or where I move the player ... I also downgraded every gfx setting to 'low' as you suggested that the # of vertices dropped below a given threshold so I thought perhaps it's the gfx settings I have (everything maxed) but... nope 1920x1200... works like a charm. Will try other resolutions now but I don't know what triggers it on your part...

(edit) windowed mode, 1440x900 or so, no problem either... very odd. ..

Will now install the photomode mod to see if I can reproduce it without gerhalt's ass in the way

(edit) I remembered I could just use Ansel and I can't reproduce it with that either. Flying around, like you in your video, same spot, using displaydepth, not a problem at all, right depth buffer is chosen every time, looking at a clear sky, all OK... really weird.