Confused about global pre-processor definitions
- JJohnson1988
- Topic Author
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.
Please Log in or Create an account to join the conversation.
- crosire
Please Log in or Create an account to join the conversation.
- JJohnson1988
- Topic Author
Please Log in or Create an account to join the conversation.
- JBeckman
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.
Please Log in or Create an account to join the conversation.
- JJohnson1988
- Topic Author
/**
* 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
Please Log in or Create an account to join the conversation.
- JBeckman
(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.
Please Log in or Create an account to join the conversation.
- aaronth07
In case it matters, the game is question is Fallout 4.
Please Log in or Create an account to join the conversation.
- seri14
Please Log in or Create an account to join the conversation.
- aaronth07
Please Log in or Create an account to join the conversation.
- crosire
Please Log in or Create an account to join the conversation.