Welcome, Guest.
Username: Password: Remember me

TOPIC: Confused about global pre-processor definitions

Confused about global pre-processor definitions 7 months 5 days ago #1

Hello. This may be a simple question, but I can't figure this out for the life of me.

My issue is modifying the global pre-processor definitions doesn't seem to do anything. At least, not with SMAA.

For example, in the DUSK game that recently came out, the depth buffer is upside down. So I tried changing RESHADE_DEPTH_INPUT_IS_UPSIDE_DOWN to 1, reloaded ReShade, and nothing seems to have happened; the SMAA debug mode still shows the depth buffer as being upside down.

What am I missing? This has also been a problem with Witcher 3 in the past, but I shrugged it off.
Last Edit: 7 months 5 days ago by JJohnson1988.
The administrator has disabled public write access.

Confused about global pre-processor definitions 7 months 5 days ago #2

SMAA does not respect those settings. That's a long-standing bug in that specific effect.
Cheers, crosire =)
The administrator has disabled public write access.
The following user(s) said Thank You: JJohnson1988

Confused about global pre-processor definitions 7 months 5 days ago #3

Good to know, and thanks for the quick reply. :)
The administrator has disabled public write access.

Confused about global pre-processor definitions 7 months 5 days ago #4

There are some modified versions of the SMAA effect on this forum too but that was a while back and I haven't kept track on if it's part of the updated SMAA.fx file on the Github repository already or was for things now fixed in the ReShade core.

I might have to look that up again since I mentioned it and all and see what it really did. :)

EDIT: There's the first one.
reshade.me/forum/shader-presentation/187...h-il?start=600#26984
Ok so I had a look at SMAA. Yes, it indeed grabs the unlinearized, unflipped, un-whatever raw depth buffer. Raw sauce, no ketchup. As far as I see, there are 2 options, each with their own (dis)advantages:

Add a prepass that creates a linearized depth buffer so all intrinsic SMAA calls read that one - just like it was in the ReShade framework. When porting it over to RSFX 3.0, crosire apparently made a mistake. This means 1 new pass and 1 new texture, so we have some more video mem usage but other than that, no big changes. Also very fast, as there's no need to linearize the depth data when sampling (can quickly build up when reading it a lot of times, MXAO does the same to prevent this).

Track down every place where original depth texture is read and patch it directly there so instead of just reading it, it's linearized directly after being sampled. This means huge code restructurements, as many functions are called with both color and depth texture, so when being called with depth texture, it needs a special treatment and so on. This would also place the linearization functions into SMAA directly as sometimes depth is gathered (4 neighbour pixels read with 1 call) and the ReShade linearize depth function in ReShade.fxh can't do that. Meaning that every future change to the linearization functions would require changing them in SMAA as well. TL;DR: chaotic code changes, hard to do, hard to maintain, 100x depth samples = 100x linearize math (performance costy), easy on video memory as it needs no new pass.


I think you already guessed it, I opted for the first one. I'm writing this so you don't think I was just being lazy - option 2) is very inferior in almost all accounts.

I haven't tested it in-depth but it should work, at first glance:

EDIT: And the second one is a modification to the core SMAA.fxh file (The source file for SMAA I think.) not from ReShade but a modification from SpecialK but it's that file and the two can be merged if it still applies.

gitlab.com/Kaldaien/SpecialK/tags/sk_0_8_50
+ Corrected ReShade's SMAA shader so that edge-detection when using depth
respects the "upside down" pre-processor definition

>> (Use attached SMAA.fxh)

I don't know the shader file language well enough to say exactly how this works though, I can compare the two via something like Notepad++ and the compare add-on and merge the differences but not truly understand them. :)

(Might not apply to logarithmic and reversed if it just fixes upside-down which is primarily Unity Engine I think?)
(So it would need additional tuning for the other two and maybe even combinations such as reversed and logarithmic.)

EDIT: And with ReShade 3.4.0 and higher and modifications to SMAA.fx (But not the .FXH file I think.) I do not know how much these apply if at all, sounds like the definitions are still problematic but that's above my understanding and current knowledge about ReShade. :)


EDIT: And I guess if these somehow still apply someone could eventually update the Github repository with whatever changes are needed, I think the latest few for SMAA mainly affect predication (Off by default since it's not always a advantage now.) and updates to the description of certain variables or something like that.
Also the changes to ReShade 4.0 compatibility with the sliders I think is what those do.
Last Edit: 7 months 5 days ago by JBeckman.
The administrator has disabled public write access.
The following user(s) said Thank You: JJohnson1988

Confused about global pre-processor definitions 7 months 5 days ago #5

Thanks for those. I found this code in the latter:
/**
 * Depth Edge Detection
 */
float2 SMAADepthEdgeDetectionPS(float2 texcoord,
                                float4 offset[3],
                                SMAATexture2D(depthTex)) {
#if RESHADE_DEPTH_INPUT_IS_UPSIDE_DOWN
    float3 neighbours = SMAAGatherNeighbours(float2 (texcoord.x, 1.0-texcoord.y), offset, SMAATexturePass2D(depthTex));
#else
    float3 neighbours = SMAAGatherNeighbours(texcoord, offset, SMAATexturePass2D(depthTex));
#endif
#if RESHADE_DEPTH_INPUT_IS_REVERSED
    neighbours = float3 (1.0, 1.0, 1.0) - neighbours;
#endif
So It looks like it should also work with a reversed depth buffer. No idea about logarithmic.
Last Edit: 7 months 5 days ago by JJohnson1988.
The administrator has disabled public write access.

Confused about global pre-processor definitions 7 months 5 days ago #6

Yeah I just went through comparing it against the Github files. Seems both would still apply although for this particular question the second file is more important having worked in support for reversed and upside-down definitions from ReShade.fx or the preprocessor settings. :)
(EDIT: Or well it affects how the shader works when these are encountered or set.)

Logarithmic might not be as important, my initial understanding was that more recent games particularly using open world settings utilized this and reversed together as a form of infinite depth for very long view distances and taking into account z buffer issues and flickering or similar that can apply.

Might not be required if reversed is supported, I believe the earlier ReShade builds (Prior to 3.0?) had reversed automatically use logarithmic and then it was separated into it's own preprocessor definition.

I don't quite remember but it should be easy to just test and see if these code additions work to correct the shader not respecting the definition settings. :)
Last Edit: 7 months 5 days ago by JBeckman.
The administrator has disabled public write access.

Confused about global pre-processor definitions 5 months 6 days ago #7

I know this post is a bit old, but I am having the exact same problem, except with display depth. Editing global preprocessor definitions doesn't do anything with display depth on and use preprocessor definitions checked. That means there is no way to edit the global preprocessor definitions, which means DOF and other effects that use depth are permanently messed up.

In case it matters, the game is question is Fallout 4.
The administrator has disabled public write access.

Confused about global pre-processor definitions 5 months 6 days ago #8

Did you checked "Use Preprocessor Definitions" variable of Display Depth on variable editor?
Last Edit: 5 months 6 days ago by seri14.
The administrator has disabled public write access.

Confused about global pre-processor definitions 5 months 2 days ago #9

Yes, that is what lets me know that editing the definitions does nothing.
The administrator has disabled public write access.

Confused about global pre-processor definitions 5 months 2 days ago #10

You need to reload after changing them.
Cheers, crosire =)
The administrator has disabled public write access.