[SOLVED] DisplayDepth not working on AC Origins

Hi,

I know some of you succeeded in using DIsplayDepth (because I saw some screenshots with it) but It doesnt work on my two computers so...do I need to do something in special to make it work ? It works on Nier Automata but not on AC Origins so I wonder why.

Thank you

If it doesn't work, as in: you see either a black or white screen, it might be you have to change the depth settings in the settings tab (e.g. set the value from 0 to 1).

On the settings tab, set RESHADE_DEPTH_INPUT_IS_REVERSED to 1, and RESHADE_DEPTH_INPUT_IS_LOGARITHMIC to 1, then go back to the HOME tab and click 'Reload'. DisplayDepth will then show the depth buffer properly (black up front, white in the back)

(although logarithmic depthbuffer or not doesn't really make things change a lot in ACO)

Thank you Otis ! I will try what you said as soon as I can play AC again

See you on Flickr

Reshade seems to recognize ACO as an online game so depth display isn't working correctly. Going into offline mode or cutting internet connection doesn't help, maybe something to to with their DRM. A pity since AC4 and Unity work fine on my end. That being said the depth map in ACO does get shown abeit flickering as is usually the case in online games so if you only want to take screenshots that should be possible with a bit of timing. You might have to wait a short while until the depth map shows up for an instant. And set MXAO to "reversed".
Edit: Otis kinda sounds like it's working for him, at least the part with logarithmic depth.

There's a ongoing event currently having all three god trials and another quest but offline mode should see the game sending and receiving zero so there shouldn't be any problems with the depth buffer as a result of said traffic if that's used. Game definitively uses logarithmic depth but apparently ReShade occasionally grabs the wrong buffer and thus it breaks depth detection though I haven't seen this behavior myself and I'm also not too sure what's breaking it.

Definitely not on my end, but maybe I'm just getting it wrong. This is what it looks like without any changes:


This is with Logarithmic set to 1 in the preprocessor settings leading to heavy flickering:


Setting only Reversed to 1 does the trick:


Reversed and Logarithmic together looks equally wonky:

On topic: I kid you not, at night (ingame) the depth buffer is working flawlessly. As soon as I wait until morning it's gone only showing occasionally. Working again when I wait til nightfall.

On/offline has nothing to do with it, see: reshade.me/forum/releases/3744-3-1?start=60#25166 and further.

Reshade at the moment picks the wrong depth buffer sometimes, which makes it end up empty. It's currently unclear why this happens. Debugging it didn't reveal the cause, only that it picks the wrong buffer. Next couple of days I have abit of time and will try again to see if I can dig up some more info about what's going on and hopefully that'll lead to something which will reshade pick the right buffer in all cases.

FYI: Depth works as long as the HUD is turned off. Thanks to Merc for mentioning it in the Database . Counts for subtitles as well.
My questions about Logarithmic Depth still stands, though.

I have the same problem with AC4 pls fix asap.

For that issue it sounds more like the depth buffer distance setting in ReShade might need to be extended to account for the increase in view distance, default is 1000.0 and that probably corresponds to different things in different games depending on how those handle distance and how far you can see at least for when logarithmic depth isn't involved.

As for Origins the only flicker I've noticed with depth effects have been the temporal AA since it works by using a slight jittering effect, I do primarily use a modified version of ReShade working through SpecialK however which has a few workarounds for games relying on multi-threaded rendering and working around shader effects such as fog and most recently also various solutions for handling UI elements. Based on 3.0.8 and I don't think the current version has merged in the 3.1.0 commits yet (Those that it could use.) though the only "downside" is that it's dependent on SpecialK itself and it can be a bit overwhelming to set up since there's so many different options.


EDIT: It seems to work pretty much the same in 3.1.0 though the UI elements need to be off first (Such as from the camera tools or just using the photo mode and waiting a few seconds.) since they otherwise interfere with the depth detection.

farm5.staticflickr.com/4639/24462960617_81bf92bbeb_o.jpg
farm5.staticflickr.com/4690/39326428311_5892e4f4f3_o.jpg
farm5.staticflickr.com/4647/24462960237_c4dc02d6a8_o.jpg

And while not the easiest to capture in a screenshot the temporal effect and jitter can be seen in the bush to the side of this temple building.

@Jbeckman the specialK fork of reshade does have a fix for the lock issue currently in reshade 3.x it seems but indeed also a lot of other code which isn't really interesting if you're not using specialK. not sure it fixes it in all cases (it still seems to use locks, which IMHO is unneeded, as all objects involved are used by a single thread and thus don't need locks) but it at least makes an effort to get rid of the central bottleneck in the runtime where all the drawcalls end up and which is likely the reason why in reshade drawcalls to indirect d3d render calls (used by origins a lot) are ignored. This leads to the depth buffer used by the renderer to not have a lot of calls and therefore not be picked. The current system worked in d3d9/10 with a single threaded renderer but it doesn't anymore in the world of multithreaded deferred contexts: some refactoring is needed to fix this so the right depth buffer is tracked with the right amount of calls so the right depth buffer is picked automatically.

Kaldaien has also forked over a few of the changes which were then merged into ReShade 3.1.0 though it's been updated further since then improving support for games such as Okami which despite being a port from a older PS3 code base (In turn updated from the PS2 original release.) Capcom appears to have overhauled it quite extensively for this new version although the 30 FPS cap is still in due to how much is tied into this.

Updates to SpecialK and it's ReShade build can also periodically change or break compatibility and as you said the ReShade version itself is pretty stripped down and reliant on SpecialK to function at all though it's also possible to run both the custom and standard version of ReShade through SpecialK so I keep both around.
(And some games such as Ghost Recon Wildlands thanks to EAC doesn't really play nice with custom injected .dll files making the official version of ReShade the only alternative short of circumventing EAC and playing offline.)


There has also been a few commits to ReShade after the 3.1.0 release but I don't know how important these are although some of the commits look interesting for version 3.1.1 or what the next release will be called.
github.com/crosire/reshade/commits/master

I still have quite a lot to learn on how some of these things work, it's mostly from following discussions and such and then trying updated versions in games and seeing how it works. ReShade has come quite a long way now and is working pretty well for the most part for being a generic injector meant to just work without any specialized compatibility tweaks or a per-program internal compatibility profile or similar setup which I find really impressive.

Though it also does mean that some games that differ from the norm are more susceptible to breaking when it comes to compatibility or the way depth detection and the like is done. Focus on newer API's and methods such as the increase in compute shader usage (AC: Origins has a ton of these.) might also require some work although it'll be a while yet before we see DirectX 12 or Vulkan taking over from the existing DirectX 11 graphics API though DX11 is also seeing a few updates here and there although I am not all too sure how much of these are used in the actual games.
(I know D3D11.1 is a requirement for a few titles which affects Windows 7 and it's up to version 11.4 now but I don't think many games explicitly supports or makes use of these newer features.)


EDIT: Something like this.
steamcommunity.com/sharedfiles/filedetails/?id=1233865979

Whereas the official version of ReShade is pretty simple to set up and what I use for the majority of the games I have installed currently for the games running through SpecialK it's possible to do that but also go a bit further using the shader functionality to bypass UI elements and effects such as fog.

I see it as a interesting alternative but both versions have their uses and setting up SpecialK can be complicated for a few games in addition to other possible compatibility problems that ReShade mostly manages to avoid.

3.0.8 and newer version of ReShade also fixes several bugs and issues in addition to some possible performance bottlenecks and later versions will hopefully fix even more as Crosire finds time to continue development, open source also allows for other people to contribute but with how complex the ReShade code base no doubt is there's not been all that many commits to the project yet but there's been some at least. Same also goes for the actual shader repository which also sees periodic updates.



For this game? Well something with the UI elements seems to periodically block the depth buffer or interfere with it's compatibility.
One of the compute shaders also occasionally confuses the algorithm ReShade uses to determine the depth buffer. (More on that from OtisInf's post in the 3.1 topic.)

And there's a possibility of the temporal AA routine and the way it jitters to also interfere with depth effects causing a noticeable flicker or shimmer as a result.


EDIT: Also not too sure how easily these are to work around or fix, depth being cut off or affected by overlays isn't anything new but disabling the HUD isn't really the answer since these elements are kinda useful for regular gameplay. HUD toggle from the camera tools might be the best alternative for this for now.

AA might have to be disabled and then either rely on injected FXAA or SMAA from ReShade or go downsampling if you have a strong enough GPU for it.

And that compute shader might require changes for ReShade itself so it gets the correct depth buffer hooked.


EDIT: But like I said I'm no expert or anything, it's interesting to read up on though and the game is a good initial case for how future titles might work since the Anvil Next engine here is pretty advanced from what I can tell. (And also quite demanding. )
Makes for a good trial and test game though game engines such as Frostbite, UE4 and Cry-Engine or even Unity are also advancing with each update.

But it'll be a while before games actually use these later versions of these engines and most in-house "AAA" style development tends to be on custom engines.
(Whereas say a few years ago UE3 was the big thing in the industry leading by quite a margin and UE2.x did pretty well too but UE3 really took off.)


No idea what the next Anvil Next engine game will be, for Ubisoft then next up I think that's Far Cry 5 running on the new Dunia engine using features such as photogrammetry for environmental detail and whatever else they've added or updated.
(While also making use of some AMD features it might end up using some NVidia tech again, kinda curious that it wasn't used for AC Origins actually.)

But I suppose that's getting a bit off topic.

Problem currently is that there are simply a lot of calls on modern multi-threaded deferred engines which are not tracked/logged and therefore aren't taken into account for depthbuffer detection, which results in the wrong one being picked in cases where there are more than 1 depth buffer with the same size as the screen. Everything is also done on the runtime class so multiple threads making draw calls on their own deferred contexts all end up in the same function in the runtime which is using a lock so only one can be in that function at any given time, causing a bottleneck, if the missing draw call tracking is added. The specialK variant solves this somewhat but with a different lock so it still uses locking (as far as I could tell from browsing it on github) and this can be solved with almost no locks (only 1 for commandlist-drawcall counters but this is minor)

I've refactored the code for depthbuffer detection/tracking as a lot doesn't do much as it's a left over it seems from v1 or earlier, but ran into a problem with where things are stored, so I hope to have fixed that by tomorrow so I can see if this truly solves things properly. I don't see why not, but it will be a bit of work to make it fit into the code base.

If that works I'll post a pull request on github so it can be merged (after crosire likely tells me to rewrite a couple of things because it's not good C++ )

Good news is: I have it working now. Bad news is: I still need 1 lock and this still makes it too slow (16fps in 1280x720 on a 1070 ;( ) so I have to look into whether I can speed this up a bit. It did solve a depth buffer selection problem on the other test game I use, bulletstorm FCE in windowed mode, it now selects the proper depth buffer. But the performance in multi-threaded systems is still way too low, so not done yet.

Fixed everything, it's superfast now, with 1 issue: it has 3 depth stencils, where 2 are 1 pixel too high for the window height and 1 matches the window height. The one it should pick is 1 pixel too high so it picks the wrong one... as there's just 1 to choose from which matches the window

Very odd it has a height of the window with 1 pixel height difference with some of the depth buffers the game uses. In full screen it works OK of course, as the depth buffer then matches the window height reshade works with. Almost there

(edit) AC:O seems to use an even number for depth stencil height, so if the client area in the window has a height that's even (check with SRWE), the depth buffer has that too and everything works great. If the client area has a height that's uneven, the depth buffer height is still even and thus it doesn't match. Easy fix, with a heuristic check.

OtisInf wrote: Fixed everything, it's superfast now, with 1 issue: it has 3 depth stencils, where 2 are 1 pixel too high for the window height and 1 matches the window height. The one it should pick is 1 pixel too high so it picks the wrong one... as there's just 1 to choose from which matches the window

Very odd it has a height of the window with 1 pixel height difference with some of the depth buffers the game uses. In full screen it works OK of course, as the depth buffer then matches the window height reshade works with. Almost there

(edit) AC:O seems to use an even number for depth stencil height, so if the client area in the window has a height that's even (check with SRWE), the depth buffer has that too and everything works great. If the client area has a height that's uneven, the depth buffer height is still even and thus it doesn't match. Easy fix, with a heuristic check.

Thank you for your work on this, amazing!

I wonder how many other games will benefit from this too

Martigen wrote:

OtisInf wrote: Fixed everything, it's superfast now, with 1 issue: it has 3 depth stencils, where 2 are 1 pixel too high for the window height and 1 matches the window height. The one it should pick is 1 pixel too high so it picks the wrong one... as there's just 1 to choose from which matches the window

Very odd it has a height of the window with 1 pixel height difference with some of the depth buffers the game uses. In full screen it works OK of course, as the depth buffer then matches the window height reshade works with. Almost there

(edit) AC:O seems to use an even number for depth stencil height, so if the client area in the window has a height that's even (check with SRWE), the depth buffer has that too and everything works great. If the client area has a height that's uneven, the depth buffer height is still even and thus it doesn't match. Easy fix, with a heuristic check.

Thank you for your work on this, amazing!

I wonder how many other games will benefit from this too

I'll try some like Tomb raider which doesn't have a depth buffer in v3 to see if it now pops up.

Everything works now. I also added support for resolution scaling, so in e.g. AC:O if you use resolution scaling of say 140% it still works (also e.g. when you set it to a lower value, e.g. 70%). It seems a bit faster than the current code as well so that's a bonus, overall.

I'll do some cleanup, reviewing and fix a minor issue in 3.1 where the # of drawcalls is always 0 in 'statistics', but that's minor, then a PR and let's hope there aren't any problems crosire can think of so it can be merged

All done. PR: github.com/crosire/reshade/pull/38

OtisInf wrote: All done. PR: github.com/crosire/reshade/pull/38

Thankyou for doing this Otis! I just started AC:O myself

Uh, do you have binaries you can share?