Marty McFly's Ambient Obscurance (MXAO) with IL
- Marty McFly
-
Topic Author
- Wolfmeister1010
-
I wish there were examples on the web for me to see right now haha.
- Chaosrik
-
- GP-Unity
-
- Marty McFly
-
Topic Author
- thalixte
-
GP-Unity wrote: I'm using the latest version of Reshade with MXAO 3.1.0 (the one with blending modes) and in the few games i've tested it doesn't seem to work as intended. I have to increase the value for sample radius and ambient occlusion to really high amounts (around 50) to try and get the expected results. This does have the side effect of overly bold AO (if that makes sense). I do make sure the preprocessor definitions are accurate for the games. I'm assuming this problem might be tied to possible depth access changes made in Reshade's latest version?
Have you tried with the in-game anti-aliasing disabled ?
- Uncle Crassius
-
GP-Unity wrote: I'm using the latest version of Reshade with MXAO 3.1.0 (the one with blending modes) and in the few games i've tested it doesn't seem to work as intended. I have to increase the value for sample radius and ambient occlusion to really high amounts (around 50) to try and get the expected results. This does have the side effect of overly bold AO (if that makes sense). I do make sure the preprocessor definitions are accurate for the games. I'm assuming this problem might be tied to possible depth access changes made in Reshade's latest version?
Curious which games you tried. And a screenshot or two might illustrate the problem.
- GP-Unity
-
High sample radius
NO AO
AO
AO DEBUG
METAL GEAR RISING
High AO amount but applied to a soft degree
NO AO
AO
AO DEBUG
I've pushed AO FINE SCALE up in all cases, to make the AO more apparent. I have spent time working through each of the values but i believe this issue might be due to how the new version of Reshade functions. Worked perfectly before. Also bold and banding AO is not too evident in the screenshots but definitely in motion, i had to really rework the values to reduce the bold AO though, whilst managing a decent sample radius. MGR is a DX9 game, while Life Is Strange: BTS is DX11.
- Uncle Crassius
-
- Marty McFly
-
Topic Author
- NattyDread
-
Also, mxao settings can go beyond their recommended (caped) values. Why not just crank up the radius to some silly value. Who cares it's too high if it looks good.

Marty, any plans on adding an option that defines how far a front object can shadow the geometry behind it?
Chaosrik wrote: Great shader. Just trying to get it to work with American Truck Simulator. Have managed to get it working but only with in-game graphic scaling of 100% - not with 400%. Anyway to change it so it can cope with scaling as its only a quarter size in the corner of screen ?
Resolution scaling breaks reshade depth detection same way as MSAA does. You can try maybe to render the game at 4k and use SRWE to scale back the game to your native res. Not sure how good SRWE scaling is quality wise tho.
btw, where can I find MXAO 3.1.0? Is it officially released?
- Chaosrik
-
- Sunesha
-
Awesome,Marty McFly wrote: I wanted to upload it to github but then I made some amazing progress: a rewritten sample placement allows me to drop the sample counts of all quality presets, so "very low" for example looks same with 4 samples (new code) and 8 samples (old code) so I went ahead and lowered all qualities respectively this should boost performance a lot with same visuals. What I need to refine is the blur code, I made a rather vast change to it but it's hard to tweak right now and I'd prefer if it could work without user interaction just like the old one.
[strike]I'll continue working on this, got another2 ideas which I'd like to try out after that, then I'll release and update the github one.[/strike]
Tested both, turned out beautifully. MXAO just got faster!
I have been using the 3.10 version( pastebin.com/raw/Gn3EUMyf ) for awhile without problems.
Faster and faster it goes. As usual I stand impressed that this shader just get better and at same time more economic. I hope you solve the blur code, waiting patiently for public consumption version

- NoMansReshade
-
As well as "GTAO" (Ground Truth Ambient Occlusion). Detailed here: iryoku.com/downloads/Practical-Realtime-...direct-Occlusion.pdf
- Martigen
-
Wait... is SMAA not honouring the depth buffer properly?Chaosrik wrote: Ok, thanks. I ended up using DSR, works fine. However I've come across a problem when using MXAO with SMAA (using the depth buffer). I had to flip the depth buffer to get MXAO to work with the game but the buffer is now upside down for SMAA predication (checked with SMAA debug). Anyway to fix this ? SMAA works well without predication but I thought I could improve it.
Looking quickly at the shader there's a couple of references to Reshade::DepthBuffer, but all the other depth-based shaders appear to use Reshade::GetLinearizedDepth(texcoord). Could that be the problem?
@Crosire might be able to advise. If it is incorrect good bug catch

- Chaosrik
-
Martigen wrote:
Wait... is SMAA not honouring the depth buffer properly?Chaosrik wrote: Ok, thanks. I ended up using DSR, works fine. However I've come across a problem when using MXAO with SMAA (using the depth buffer). I had to flip the depth buffer to get MXAO to work with the game but the buffer is now upside down for SMAA predication (checked with SMAA debug). Anyway to fix this ? SMAA works well without predication but I thought I could improve it.
Looking quickly at the shader there's a couple of references to Reshade::DepthBuffer, but all the other depth-based shaders appear to use Reshade::GetLinearizedDepth(texcoord). Could that be the problem?
@Crosire might be able to advise. If it is incorrect good bug catch
Yeah I saw that too. Not sure why SMAA should be different. I'm sure they'll be a reason. Maybe a way to change smaa.fx ?
- Marty McFly
-
Topic Author
NoMansReshade wrote: Not that it's necessarily anything impressive, I'm just curious of your take on a method of AO dubbed "NNAO" (Neural Network Ambient Occlusion). This method is detailed on this paper: theorangeduck.com/media/uploads/other_stuff/nnao.pdf
As well as "GTAO" (Ground Truth Ambient Occlusion). Detailed here: iryoku.com/downloads/Practical-Realtime-...direct-Occlusion.pdf
I did check both of them out quite a while ago

NNAO is a quite creative take on AO but sadly, it still needs various samples to generate AO so it's essentially a shady way to compute AO from depth values (neural networks are a blackbox, you don't really know what's going on inside them).
GTAO on the other hand aims to be as close as possible to raytraced ground truth (and does quite a good job at it). I do have my own implementation of it modeled after the paper (seems to be very close as I get the same trigonometry count they mentioned after optimization) but the 0.5ms target mentioned in the paper is only reached by aggressive spatial and temporal supersampling. As we apply AO on top of the final image, physical correctness is tossed overboard. Using its way to calculate occlusion on ReShade would mean additional workload with no visual gain.
If there was any good improvement in any AO technique I happen to find, MXAO would receive it. Trust me or not, but MXAO really is among top 10% of SSAO implementations. Intel ASSAO should be better for small radii, ENB SSAO is much superior for GI. Most of MXAO's performance hit is the setup of the textures which are given in other environments, so on Unity for example MXAO would be very very fast.
- mbah.primbon
-
Chaosrik wrote:
Martigen wrote:
Wait... is SMAA not honouring the depth buffer properly?Chaosrik wrote: Ok, thanks. I ended up using DSR, works fine. However I've come across a problem when using MXAO with SMAA (using the depth buffer). I had to flip the depth buffer to get MXAO to work with the game but the buffer is now upside down for SMAA predication (checked with SMAA debug). Anyway to fix this ? SMAA works well without predication but I thought I could improve it.
Looking quickly at the shader there's a couple of references to Reshade::DepthBuffer, but all the other depth-based shaders appear to use Reshade::GetLinearizedDepth(texcoord). Could that be the problem?
@Crosire might be able to advise. If it is incorrect good bug catch
Yeah I saw that too. Not sure why SMAA should be different. I'm sure they'll be a reason. Maybe a way to change smaa.fx ?
AFAIK.
SMAA only need the raw depth buffer. I was use SweetFX's SMAA as reference when i update the shader.

- JBeckman
-
Chaosrik wrote:
Martigen wrote:
Wait... is SMAA not honouring the depth buffer properly?Chaosrik wrote: Ok, thanks. I ended up using DSR, works fine. However I've come across a problem when using MXAO with SMAA (using the depth buffer). I had to flip the depth buffer to get MXAO to work with the game but the buffer is now upside down for SMAA predication (checked with SMAA debug). Anyway to fix this ? SMAA works well without predication but I thought I could improve it.
Looking quickly at the shader there's a couple of references to Reshade::DepthBuffer, but all the other depth-based shaders appear to use Reshade::GetLinearizedDepth(texcoord). Could that be the problem?
@Crosire might be able to advise. If it is incorrect good bug catch
Yeah I saw that too. Not sure why SMAA should be different. I'm sure they'll be a reason. Maybe a way to change smaa.fx ?
If it's SMAA and depth I wonder if it's related to what Kaldaien mentioned for SpecialK and the modification he did to SMAA.fxh
(You don't need SK itself just that shader file.)
gitlab.com/Kaldaien/SpecialK/tags
Scroll down to sk_0_8_50 and grab the attached SMAA.fxh file.
If you then compare that to the ReShade file here.
github.com/crosire/reshade-shaders/tree/master/Shaders
github.com/crosire/reshade-shaders/blob/master/Shaders/SMAA.fxh
(Right click on raw and save-as.)
#if RESHADE_DEPTH_INPUT_IS_UPSIDE_DOWN
float3 neighbours = SMAAGatherNeighbours(float2 (texcoord.x, 1.0-texcoord.y), offset, SMAATexturePass2D(depthTex));
#else
#endif
#if RESHADE_DEPTH_INPUT_IS_REVERSED
neighbours = float3 (1.0, 1.0, 1.0) - neighbours;
#endif
(I used the Compare 2.0 plugin for Notepad++ but there's probably other tools for it too.)
Those lines were added, there might also be differences for C a bit above that but it's related to a different commit entirely.

github.com/crosire/reshade-shaders/commi...42b6545a60c322c62700
From how Kaldaien explained it it has something to do with this:
steamcommunity.com/groups/SpecialK_Mods/...c1480982971156691987
+ Corrected ReShade's SMAA shader so that edge-detection when using depth respects the "upside down" pre-processor definition.
The fixed SMAA shader that can do depth-edge detection in Unity engine games is included in the 0.8.50 release notes. I cannot package SweetFX, etc. shaders with my mods. But I can link you to corrected shaders as need be.
I don't think he made a pull request for it though.
And I'm not sure if this would only be for Unity Engine and maybe some other game out there requires UpsideDown=1 for depth buffer settings so it might have littler effect for logarithmic or reversed settings if there's anything with these.
EDIT: Life is Strange Before the Storm? It should work then, LIS used UE3 but LIS:BTS switched to Unity so perhaps this fixes it?
I don't really know how it all works due to my very limited understanding of shaders and this code but it's just something I recalled when I read the post here.

EDIT: Oh right the full thing would look something like this for copy/pasting it more easily.
/**
* 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
float2 delta = abs(neighbours.xx - float2(neighbours.y, neighbours.z));
float2 edges = step(SMAA_DEPTH_THRESHOLD, delta);
if (dot(edges, float2(1.0, 1.0)) == 0.0)
discard;
return edges;
}
- Chaosrik
-
