Manual depthbuffer flip

I know there is research going on on how the depthbuffer in Unity Engine games can be flipped back in ReShade, though there is no guarantee there will be a solution.

Maybe an extra line of code for Unity Engine games could be added to where the depthbuffer is called (if that is even the right term, I have no idea about programming languages) so we can comment/outcomment the line if we are using ReShade with Unity games?

I've come across this message board entry on Guru3d and wouldn't be asking about this if I was able to do the same with the ReShade framework version. It seems to be structured differently or has different written code (or I have overlooked it)

Well, that would be my suggestion as there are quite a few Unity engine games I'd like to use with ReShade.

Another thing/A question:

Display Depth
#define RFX_Depth_z_near 0.01
#define RFX_Depth_z_far 100.00

In common_settings, how are these values determined? They seem to work with many games but seem to be different for Unity games. Why is that?
Changing these numbers I can get a "normal" looking framebuffer in some games, but is ReShade still working correctly when doing this?

On the settings...

Up to, I think, ReShade 0.15 the values were:

RFX_Depth_z_near 1.00
RFX_Depth_z_far 100.00

Then in 0.16 onwards z_near has defaulted to 0.01. Now, for me, in Dragon Age: Inquisition this creates a depth buffer that is almost entirely black. So I've been editing it back to 1 each time. However, I've not seen anyone else complain about the default depth settings, so wondering if it's just me or if these values really should be returned to 1-100. Does anyone else using depth buffer features notice a difference?

On that note, would having incorrect values here affect depth-based effects (like SMAA predication)? Or is it purely a visual display?

Janson wrote: I know there is research going on on how the depthbuffer in Unity Engine games can be flipped back in ReShade, though there is no guarantee there will be a solution.

Maybe an extra line of code for Unity Engine games could be added to where the depthbuffer is called (if that is even the right term, I have no idea about programming languages) so we can comment/outcomment the line if we are using ReShade with Unity games?

I've come across this message board entry on Guru3d and wouldn't be asking about this if I was able to do the same with the ReShade framework version. It seems to be structured differently or has different written code (or I have overlooked it)

Well, that would be my suggestion as there are quite a few Unity engine games I'd like to use with ReShade.

Another thing/A question:

Display Depth
#define RFX_Depth_z_near 0.01
#define RFX_Depth_z_far 100.00

In common_settings, how are these values determined? They seem to work with many games but seem to be different for Unity games. Why is that?
Changing these numbers I can get a "normal" looking framebuffer in some games, but is ReShade still working correctly when doing this?

idk if reshade will be able to work like that unity has/does its depth for objects in a way its not usually there nvidia posted up a explanation on how to apply hbao+ on their website using unity 5 tho might take a look at that

I'm not sure if this is helpful in any way but a few weeks back I was checking for the depthbuffer range in Oddworld New N Tasty, and I found it relatively easy. I've also realised that dof was working but was upside down, so it was useless.
I then went on to other games and deleted the ReShade version I've placed in Oddworld. Very recently I've come back to that game and tried the newest release of ReShade... I'm suddenly not able anymore to find the depth range, it stays black all the time. I kick myself for not writing down what version and configuration/settings I've used when I got it right but I failed to recreate it using some older versions too. I would try out every version available but I don't know if MartyMcFlys Master Effects are still availabe that I've used with that specific ReShade version.

Well, it will be a real hassle going through all differnt versions and configurations but what I'm trying to say is, there was depth buffer access available once and dof working (though flipped), I'm not technically proficent enough to put it in better terms than that. I guess the reasons why are known to Crosire (only guessing here) but they are not easy to solve and clash with the generic concept at the moment.

Martigen wrote: Then in 0.16 onwards z_near has defaulted to 0.01. Now, for me, in Dragon Age: Inquisition this creates a depth buffer that is almost entirely black. So I've been editing it back to 1 each time. However, I've not seen anyone else complain about the default depth settings, so wondering if it's just me or if these values really should be returned to 1-100. Does anyone else using depth buffer features notice a difference?

On that note, would having incorrect values here affect depth-based effects (like SMAA predication)? Or is it purely a visual display?

Sorry to bump but I've not received an answer to these two questions. Does anyone with more knowledge know?

Martigen wrote: On that note, would having incorrect values here affect depth-based effects (like SMAA predication)? Or is it purely a visual display?

It does not affect SMAA, since SMAA uses the raw depth input. Other depth-based effects like DoF, AO etc however are affected, they use the linearized depth input calculated with those values (the same one used to visualize it on screen).

hi all What opens must what line ?? please

hi bro please how to open ?wath line

I'm very much also interested in this. Would it be possible to have such a feature in the future releases?
I've just tried AC: Unity and it was a second game (besides W3) I tried that uses a flipped Logarithmic depth buffer.

It causes issues with McFX depth based effects, most notable on ambient occlusion and it creates some strange halo like effect on DoF.

Here's how AO is also flipped like the DB:



Here's how it should be:



Got it like this by using SSAO and setting BrighteningAmount to negative value and disabling DarkeningAmount. This "trick" is doable only on SSAO method (the poorest method IMO) tho.

The first ss reminds me of an old PS1 and PS2 game called Echo Night haha

i had asked about this but my reply was far from helpful and after looking at it there needs to be a statement like with the logarithmic buffering fix so that the actual shaders dont need messed with. Instead by doing it like i mentioned it will be read first and know before applying the effect once it goes to get the depth buffer, or at least thats the way i took reading it.

That's what I'm hopping for. A simple switch to invert the depth buffer like with log depth but I guess it's not that easy as changing a couple of lines of code.
The Witcher 3 is a pretty huge title that has an inverted depth buffer, AC: Unity too and I'm sure it's something that will happen even more with future big games.
Who is "responsible" for this? Crosire or Marty?

NattyDread wrote: Who is "responsible" for this? Crosire or Marty?

The author of whoevers shaders you are using. So Marty, Lucifer, ...

NattyDread wrote: That's what I'm hopping for. A simple switch to invert the depth buffer like with log depth but I guess it's not that easy as changing a couple of lines of code.
The Witcher 3 is a pretty huge title that has an inverted depth buffer, AC: Unity too and I'm sure it's something that will happen even more with future big games.
Who is "responsible" for this? Crosire or Marty?

pretty sure marty its considered depth based , and adding things like this into the dll file may be just more useless code to put in as not every game uses the same method and being honest here reshades method of grabbing depth isnt 100% great some games may be useable with it but by no means does that mean the effect looks good sometimes i wonder why depth work was even done most of the shaders dont use it to help with things

The "inverted" depth isn't ReShade's fault, it's fully the fault of the depth linearization shader code from whichever package you are using. Just so that is clear. It's nothing that can be "fixed" inside the ReShade binaries.

crosire wrote:

NattyDread wrote: Who is "responsible" for this? Crosire or Marty?

The author of whoevers shaders you are using. So Marty, Lucifer, ...

your a super helpful person who is great at communicating with people on a basis they understand. I get this is in your freetime but some of your replies to people leave a lot to be desired your a jerkoff you got all these posts on here requesting help or info on how something works and no one assigned on this site to help explain the goal whats going on what your planning to do when your alloted time Lucifer and marty are great at explaining things and making it clear when people are ignorant to something but in a helpful way allowing them to go figure out what they were saying your replies are yep the dog crossed the road , its dead. Everyone is sitting there scratching their head trying to figure out what you said its not always the most helpful to some people so im now going to go post a suggestion assuming you read this of a way i think would be useful for this project

Sorry. I was answering a simple question with a simple answer.

ReShade grabs the depthbuffer. It then binds it to the shaders so they can read from it, directly, ReShade does not touch the depthbuffer in any way (Mainly because that's not even possible. Neither Direct3D nor OpenGL allow it, unless rendered to a separate texture and altered there, which would cost lots of performance for nothing).
Now the shader is responsible for retrieving the depth data and to do some useful stuff with it. Problem is, games use different methods to write to the depthbuffer in the first place. Up to recently it was almost always filled linearly, meaning the value 0 was right before the camera and 1 was far away. This however produces artifacts known as Z-fighting if range is very high (which is getting more and more common with todays open world titles). A new way of storing depth was developed, using a logarithmic scala. You can read more about it here: outerra.blogspot.de/2012/11/maximizing-d...uffer-range-and.html . The article also proposes an even better distribution of the depth values, by reversing the whole buffer.
So now that the shader gets the raw depth input, it somehow needs to convert that back to some usable (and consistent across games) values, which can be used as input for the DOF, AO etc. shaders. That's where that logarithmic depth option from the framework comes in. Enabling it modifies the depth values to look similar as if the game used a normal, linear depth distribution, allowing DOF etc. to produce the same output. It currently is lacking a third option for games using a reversed logarithmic depthbuffer however.

I hope this explains the whole thing a little bit more in-depth (no pun intended) and as to why it's something which needs to be done in shader code, rather than the binaries. If not, feel free to ask further .

Ok, 10 years later -I figured out how to do this for Marty's McFX:

open the "ReShade/McFX/Util.h" and change the line
return depth = (exp(depth * log(2f)) - (1f-0.0045*(1f-pow(abs(depth * log(300f)),100))))/0.056f;

to
return depth = (exp(depth * log(2f)) - (1f-0.0045*(1f-pow(abs(depth * log(300f)),100))))/-0.1f;

Dividing it with a negative value seams to invert the depthbuffer linearization...or whatever... Kinda super logical but it took me forever to find the line that does this. I was mostly messing around in SSAO.h.
Only tested on Witcher 3 and this value (-0.1) works well for it.

If you want to see the difference first turn on AO (I would suggest SSAO), save (see how weird it is?) and then edit the above - BOOM
This fixes the DoF also.

For AO, you indeed need to adjust GetLinearDepth() in McFX/Util.h. DoF uses the linearized depth buffer in Reshade.fx. So if you need to have depth flipped in the DoF, you need to adjust the lines starting at line 72 in Reshade.fx.

So for flipped depth in AO, change the lines 60-64 in McFX\Utils.h so it looks like:

Dividing by -0.1 works to make it a negative value, but it also multiplies it by 10

Welp. Any ideas on how to flip the depthbuffer in 1.1.0? I'm not seeing the values and lines described.