Marty McFly's Ambient Obscurance (MXAO) with IL

Both the AO and the DoF shader either work perfectly if ReShade finds the correct depth buffer, or not. Your case is that ReShade doesn't find the correct depth buffer. Nothing related to a specific shader.

---

Testing time everyone!

pastebin.com/LBGQ3inF

See last page for more information.

Cool, I tested the new version. Didn't experience any big performance difference to the prior beta version in this thread. I retested everything as I got from my Cyprus workstation to my sweden workstation(So cannot compared to earlier fps report). In the case of Human: Fall Flat(Unity game opengl) I got better results compared to the older version where it was a bit strange. Though I really just it may be game acting up

The two layer ao, Love it. It took me while wrap my head around how to set it up. But I see more or less no noticable hit in performance. I really hope it survives to the final version.

Test methodology:

System:

Good, that reflects my expectations.
The reason why the performance is only marginally better than 2.0 stock is because I kinda traded performance with quality. MXAO switches to miplevels of the depth buffer for far away objects (miplevels = downscaled versions of the depth buffer, reading from them is faster but also more inaccurate). This introduces some flickering and hazyness around objects because depth data isn't 100% correct, but it greatly improves performance. Now this new update significantly improved fps on my end, but I decided to improve quality instead so I turned down the mipmap usage. This lowered performance again, down towards the 2.0 performance but also reduced hazyness and flickering a lot.

EDIT: What resolution are you playing these games in? 1920x1080?

EDIT2: Might be some differences in performance because same radius settings don't give the same visual result now anymore. Hence I changed the radius param range to [0,20]. Maybe check how shader behaves with same-looking radius values instead of same radius values. Only if it's not too much hazzle, that is.

To check 2 files together easily, rename technique, all UI vars and all textures & samplers. Why the latter is needed, idk, but it's effective. That way you don't have to switch files.

Marty McFly wrote: Good, that reflects my expectations.
The reason why the performance is only marginally better than 2.0 stock is because I kinda traded performance with quality. MXAO switches to miplevels of the depth buffer for far away objects (miplevels = downscaled versions of the depth buffer, reading from them is faster but also more inaccurate). This introduces some flickering and hazyness around objects because depth data isn't 100% correct, but it greatly improves performance. Now this new update significantly improved fps on my end, but I decided to improve quality instead so I turned down the mipmap usage. This lowered performance again, down towards the 2.0 performance but also reduced hazyness and flickering a lot.

I agree with your choice concerning the miplevels. They look good in this version. It was a bit hazy in earlier version I tried. But not that noticable more than in debug mode.

Marty McFly wrote: What resolution are you playing these games in? 1920x1080?

Yes, 1080P with exception the Human:Flat which I use 2715X1527. my experience is that MXAO performance scales with resolution. But my fps is from me standing in empty warehouse in Splinter celll, and a garage in Hitman. I usually lock it down 30 or 40 fps in stealth games. If it is for my video recording I like lock it down. Otherwise I go unlocked usually borderless fullscreen,

There is the Steam Summersale tommorrow I believe. So I have new games to setup and then I share my thoughts concerning plain image quality.

Also try see how looks with a bigger sceene with larger drawdistance. Usually I start fading at 180-300 and fade out at 400-600. Though it really depends on the game itself. Then I can see how it looks. Because today tests was mostly maximum 20-40 m renderdistance.

Marty McFly wrote: EDIT2: Might be some differences in performance because same radius settings don't give the same visual result now anymore. Hence I changed the radius param range to [0,20]. Maybe check how shader behaves with same-looking radius values instead of same radius values. Only if it's not too much hazzle, that is.

I saw that you change radius range. I played around with extreme values and didn't really register a change in the FPS. Maybe it depends on sample value, I rarely use bigger than 32.

Marty McFly wrote: To check 2 files together easily, rename technique, all UI vars and all textures & samplers. Why the latter is needed, idk, but it's effective. That way you don't have to switch files.

Cool will try that out. Before I just swapped files and press reload Which sometimes didn't get my original values for MXAO:

Been using the 2.1.001 all day at work to play Fallout 4
My machine there is an uber-powerful amd x2 250 with a whopping 4GB of ram and a geforce 750ti. Yeah!
Anyway noticed with 2.1.001 is 1-3 fps faster than the version before, but it looks way better now, with much less shimmering and the shadows blend in properly. Good job

Edit: tried it at home where I have an amd a10 with 8Gb ram and a geforce 1060. Didn't notice any fps hit even with both ao's and il turned on.

Sunesha Yes, MXAO scales a lot with image size. It's one of the effects that usually is among those which take the biggest frame time portion of any game. As all so-called pixel shaders run, you guessed it, per pixel, their execution time is proportional to pixel count. It's just that AO is the only ReShade shader capable of bringing any video card to its knees because a) the same radii are really large compared to the screen size, 50% is common so video card can't use its cache for low sample radii like DoF and b) sample pattern is random (at least to the video card, instead of box blur of one directional blur) so again, cache awareness not given.

I've seen now that a lot people use DSR, a lot more than I thought. Hence I'm reintroducing the size scale parameter from older versions, to calculate MXAO in lower resolution. If you run your game in native resolution, you can easily squeeze some fps out of MXAO without losing much quality. Or on your 1920x1080 screen, your game can execute in 7680x4320 while MXAO has the option to still execute in 1920x1080, resulting in NO quality loss, because the AO (almost) doesn't benefit from computing in DSR. ENBSeries has the source texture scale param to downscale the input as well but as we're using miplevels already, no sense in that.

Dazaster That's how it should be Glad you like it! What's your overall opinion of MXAO compared to similar techniques (HBAO+, Alchemy AO...)?

---

Re-implemented size scale, this time properly. For those who do not know what it does, it allows to compute AO in lower resolution. A setting of 0.5 means that only 0.5*0.5 = 25% of the pixels onscreen are processed. *Some* quality decrease but HUGE performance benefit.

pastebin.com/SgPe6iA7

Marty McFly wrote: I've seen now that a lot people use DSR, a lot more than I thought. Hence I'm reintroducing the size scale parameter from older versions, to calculate MXAO in lower resolution. If you run your game in native resolution, you can easily squeeze some fps out of MXAO without losing much quality.

Even without DSR, it can be useful for high DPI monitors like the 27" 4K monitor I use. With that feature, I can use MXAO @ 2560x1440 instead of 4K which should still be good enough looking on a 27" monitor but should save some nice amount of performance.

Zarathustra wrote:

Marty McFly wrote: I've seen now that a lot people use DSR, a lot more than I thought. Hence I'm reintroducing the size scale parameter from older versions, to calculate MXAO in lower resolution. If you run your game in native resolution, you can easily squeeze some fps out of MXAO without losing much quality.

Even without DSR, it can be useful for high DPI monitors like the 27" 4K monitor I use. With that feature, I can use MXAO @ 2560x1440 instead of 4K which should still be good enough looking on a 27" monitor but should save some nice amount of performance.

For resolutions like these, you can go down to Full HD for AO I think. The quality differences are mostly only visible in debug mode so I'd recommend to tweak the other AO params in debug and set the size scale when in normal mode.

In case I missed it how does one set up two layers of AO? pre-processor setting?

This is a great update, never knew the resolution scale option could be so useful even when running games at native monitor res. Two layer option should be enabled by default instead of via pre-processor settings. Other than that, would love to see this added to Reshade's repository.

Yes change MXAO_TWO_LAYER value to 1.

ClearRenderTargets = true;
There's this line in the pass section that I never seen before. Is it a reshade 3.0 only feature?
Is there any documentation about what it does?

Great, the 'size scale' option makes it possible to use MXAO even for resolutions above 4k. I only extended the size scale range to 0.25 because I play some games in 8k.

I wished this option would be available for games with heavy particle effects so that those could be run at lower resolution. I always try to run games @ highest resolution possible in order to get the best anti-aliasing. But particles usually don't have much aliasing if any. And particle effects are one of the main causes for frame rate drops in many games.

Zarathustra, I expect every DSR user to be tech savvy enough to make this change, you can enter fixed numbers outside the ranges in the UI as well. For casual users 0.5 to 1.0 is fine, I guess.

piltrafus, almost no ReShade shader makes use of stencil, check SMAA, it does exactly the same to process only the detected edges.

GP-Unity, I believe double layer is something for advanced users, also it's not compatible to older config files because a setting of 1.0 for both layers is identical to disabled option, but due to a ReShade bug, the float2 defaults to 1.0 0.0 which disables the second layer and halves the AO intensity.

That's fair, but no chance of just the scale option being present by default?

Also, would you consider indirect lighting compositing modes? e.g. screen, add, overlay etc. Alternatively, could an individual indirect lighting shader work? I've mentioned before to you the possibility of setting individual sample radius values between AO and IL, and you said it probably couldn't be done in one shader. I have tried duplicating MXAO.fx to try the different sample radius thing, but that doesn't seem to work properly in some games (interference maybe?). One interesting thing about using only IL, is that a low sample count of even 3 in MXAO settings seems sufficient (with a lot of blurring), and there isn't a significant performance drop. With IL being disabled by default, and given how much further the effect could go in theory, you should probably consider focusing on IL on its own and seeing what it's capable of. I'm aware that only on-screen colour values can be utilised which makes true IL basically impossible, but i have analysed your IL implementation without AO in numerous games to see how accurate it is, and it already does a good job enhancing overall lighting. It could still definitely do with compositing modes either way. I could see MXIL/MXGI being a thing .

I'll tell you what I wrote before concerning different blending modes: those add, screen, Overlay are generic methods from Photoshop that are unfit for blending AO and IL properly. It needs custom ones to look right, people like PirateKitty just added them because they couldn't come up with own ones. Bottom line, different blending modes like the current ones, yes, maybe, but those you named or any other from Photoshop, no.
About two times same shader, I think renaming technique, all textures/samplers and ui params should work, that's what I do to compare different AO builds.

I have played games for couple a days with the latest version. Awesome to have size scale again. It works very well with DSR. My usual scenario is that use DSR with low polygon indie games. It helps with shimmering, which I am allergic to. So with size scale I have performance enough to use smooth normals, which really improves the look in this kinds of games.

As I stated before, IL is really a viable option performance wise now. The two layer AO is already a standard for me.

I did some visual test in Skyrim SE. I think it is working well with big drawing distance. I used 200-420 and looked fine. Usually I use around 180-360 in that game.

So this was my overall thoughts. BTW I encountered no bugs or glitches over my 12-16 hours of playing. To be noted I didn't experience this either with GitHub version

So everything works as intended? Good BTW I found that most of the performance overhead of the AO is now merely the setup of the textures and the passes themselves. I see only a small fps difference between 8 AO samples and 0. On my laptop, that is. Would like to see how it performs on an environment like Unity.

Marty McFly wrote: So everything works as intended? Good BTW I found that most of the performance overhead of the AO is now merely the setup of the textures and the passes themselves. I see only a small fps difference between 8 AO samples and 0. On my laptop, that is. Would like to see how it performs on an environment like Unity.

I have tons of Unity games. Overall the engine's own SSAO algorithm is quite expensive compared to similar solutions in other games. I will do to sample scaling fps test in two different unity games maybe today or tomorrow.

I think you done wonders with performance while still offering new things. You are light years ahead the competition, best looking AO for sure

So tested around a bit with some Unity games. I also used sizescale function in a game where used the double resolution(2715x1527>1920x1080), I used sizescale=0,707 which I believe should be 50%. I gained some performance with not too noticable impact on image quality. To be exact it was 57fps>66fps when used 16 samples. A very good improvement.


SAMPLE IMPACT ON FPS IN UNITY GAMES
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
Test methodology:

System: