qUINT

MXAO 3.4.3 , qUINT is new


oops，↑，qUINT_mxao.fx

Well I did change the IL math a bit to more accurately reflect how surfaces will scatter their colors, so a bit of a difference is to be expected.
Tweak the AO and IL intensities a bit and you'll be fine. Also, if you tweak preprocessor settings inside the files, the changes won't apply globally.

Hello Marty, any clue why this is happening?
The game is Guild Wars 2 (DX9), i have MXAO_SMOOTHNORMALS set to 1 but i can still clearly see the polygon edges.

change this parameter，But it's the same as before.

ColorMask for ssr is IT possible？

The Blacks-to-Whites value range diagram is really useful, thank you. I was using your old wip version of Lightroom ages ago and never fully understood the difference between blacks and shadows, and whites and highlights. This makes it really clear.

Super_Poopsy There are limits what can be smoothed, if the model is too low poly, MXAO can't do much without killing off detail. But you _should_ at least see a difference, try taking a screenshots with it on and off and check for difference. Also remembet that you need to reload the shader when tweaking any preprocessor option.
UTwelve I still don't see the issue, everything looks normal in my eyes.
hunt1hunt Yes.
amobae Thanks I tried to mimic Photoshop curves tool without having the ability to place custom nodes as Photoshop does. I settled for a different kind of spline curve since the Photoshop lagrange seems to spaz out extremely with certain values.

Seems like I got the near blur thingy pretty much figured out. Now comes the optimizing....yay...

The IL implementation is definitely different between this version of MXAO and the one in the standard repo. I'm currently using a very stylised and IL-heavy setting and I've had to adapt the settings a lot to make it look similar in the new version. The IL doesn't transition/blend as smoothly and has a harder cut-off point/harder edges. It's manageable with a few tweaks. I haven't spent enough time with it yet to say whether I think it's better, worse, or simply different.

The difference between the Ultra and Maximum quality setting seems larger than before. I couldn't tell much difference in the old one, but in debug view it's really quite noticeable in the new version. Ultra doesn't cut it, tbh (I am a picky b*tch tho).

Smoothnormals also doesn't seem to work as well as before (it's a constant fight in this game when using IL, but even more so with this new version).

The new Lightroom and Bloom shaders are on point, and omg SSR is a million miles away from what RBM used to be. It's so much easier to work with, and a lot more flexible. I played around with it last night to simulate a wet floor in a rain shower . It's exceptional and you'll have to prise it out of my cold, dead hands.

I'm struggling a bit with the new ADoF. I did a bunch of comparisons last night with the old one (the one in the standard repo). My main gripes with the old/standard one have always been a) the transition from focus to blur can often be very messy and introduce a lot of aliasing (regardless of where I place it in the load order), and b) the near blur plane has always encroached into the foreground as soon as I start setting the focus point at anything more than very close, even with near blur set to 99999 or whatever. It didn't used to do this, I'm sure, but it has for a long time now. None of the others in the DOF.fx shader do it.

Anyway, on point a, the transition seems better in the new ADoF. I forgot to check how it performs in terms of point b, but I didn't want to make a final comment on that until you'd finished the new near blur stuff anyway.

In the old ADoF I always had to increase the blur radius when hotsampling, as it didn't scale. Blur strength does scale in the new ADoF though, which is nice. However, there seems to be far greater reliance on this gaussian blur setting in the new one (which I presume is a reworked version of the smoothing blur setting in the old one?), and that doesn't scale, so I have to increase that instead. This gaussian setting seems to be the only thing that softens bokeh, but the downside is the rest of the blur ends up looking more fake. The old ADoF had a more pleasing clarity to it while still having soft bokeh edges. The new ADoF can at times feel more akin to a smudge on a lens (which is essentially what gaussian blur does).

Additionally, the bokeh quality setting in the new ADoF reduces the size of the bokeh the higher you go. It didn't do that in the old version. I'm finding I'm having to keep switching between a low quality setting of 2 and the maximum of 25 (I use 32 as standard in the old ADoF) to get results similar to what I'm used to, depending on the scene.

Thankfully, unlike MXAO, both ADoFs can be used at the same time (or, rather, can be present at the same time), so for the time being I'm switching between them depending on which looks better. For tricky transitions I'll use the new version, but for general stuff I'll probably stick with the old one. The new version blurs 'out', and the old one blurs 'in' - I don't know how better to explain that, but if you blurred an entire scene, the edges of objects smudge outwards in the new version, whereas in the old version they shrank inwards. I think the old version looks a lot better. It's all about that clarity of blur, rather than smudginess.

Still, I don't want to come in here and bash you -- you work damn hard on these, and I'm grateful. They're the shaders that add realism, that add that extra something that helps bring it all together, and I'm glad we have you working so hard to bring us great stuff. We all have our preferences though, and we all use shaders in different ways with different goals in mind, so I thought you might appreciate one person's experience after having extensively used your MXAO and ADoF for some time now.

I look forward to seeing what you keep bringing us.

Just uploaded a quick comparison of what I mean about blurring in and out.

It's not the best example (I started adding CA in later shots, and I don't want to use those as comparisons because it's not a like-for-like) and I'll take more focusing on hard lines, but you can see the old ADoF looks like a more realistic implementation of dof (imo, anyway) in terms of how light works in a lens. The light bleeds into the objects it borders, rather than the objects bleeding into the light.

I mean, it's a really minor niggle, and it's all likely down to personal preference, but for me the old/standard ADoF edges ahead in terms of realistic application. Even if it's not 100% accurate, the effect it produces appears more realistic.

(Apols for the high grain -- it's set high because it doesn't scale with hotsampling, and these are native res shots because it's easier to get similar results since both versions of ADoF require different accommodations to scale properly when hotsampling.)

About the IL, I might revert, will see what other people say. In the games I tested it, it looked more correct. And please, don't worry about how AO looks in debug, there can be a mile sized difference in debug and no visual difference in regular use. I wrote a raytraced (actually conetraced) AO for ReShade, it looks like a render in debug mode but not substantially better than MXAO in non-debug.

I haven't touched the same count or anything in the qUINT MXAO so Ultra should look same in theory. The filter now is a bit more relaxed so it misses less edges, maybe that's it (filter is disabled on Maximum because on 255 samples it's converging 100%).

About the ADoF: since the main blur kernel isn't depending on the pixel grid, upscaling is easy. Now gaussian blur must blur pixel perfect so I decided to make it blur N pixels instead of X% of screen size. If you'd run a huge resolution, blur size of gaussian would be insane and be slower than the actual bokeh filter. The old ADoF's gaussian blur is basically this one set to 0.

Blur size reducing when you raise quality is most likely a side effect of some safety precaution to make it compile faster on DX9. I predivide some radius by the ring count (so setting it to 30 means division by 30), but limit the ring loop to increase to a maximum of 25, means that the outermost ring is multiplied with 25/30 instead of 30/30. If you use a value <= 25, you have 25/25 for example so raising the quality beyond 25 won't increase it but further reduce the blur radius. This shouldn't be noticeable though if you stay within the given UI value ranges.

The way the edges grow is due to the optimized way the bokeh weighting works. The old one did this:

Now the fact that this norm basicaly converges to the maximum tap (larger components grow exponentially large so if curve = infinity, the largest component is infinitely larger than the rest) means that I can skip this whole exponent shit and approximate it by interpolating by the arithmetic mean (curve == 1) and the maximum (curve == inf).
This is not 100% correct but much faster than the curve stuff since computing a curve means 9 full rate instructions (more than 2 cycles) where max() is 1 full rate (1/4 cycle) per sample tap.
That's why the bokeh response is a tiny bit different than computing the mathematically correct curve but a ton faster. In theory, a gamma of 2.2 is 100% correct in terms of energy conservation so the blur looks same brightness as the unblurred source (Otis if you're reading this, this might be useful for your DoF) - actually sRGB but it's commonly approximated with 2.2 gamma.

As you apparently don't care about performance, you might benefit from re-adding this older option. I'm in the process of rewriting the DoF entirely to have proper near blur, a more beautiful far blur etc so I'll definitely take this into account and possibly implement a different bokeh highlighting.

Thank you so much for your quick and thorough reply, Marty.

I'll take another read of it -- I'm an end user with near zero knowledge of how shaders are put together, so the maths goes over my head, but I'm trying to follow as best I can. I suppose it's not as useful to you when someone just says "it looks like x but I think it looks better as y" without an understanding of what goes into making it look a certain way!

You're right, performance isn't a huge issue to me. I think there are different types of ReShade users: those who want a preset they can play with all the time, that must make the game look good while still allowing it to be playable; and those who want the same but with the option for added bells and whistles that might well grind performance to a halt for the perfect screenshot. I fall into the latter group and spend ages tweaking settings per shot sometimes (so the more options the better imo), but of course you as a shader author have to maintain a balance so everyone can get the benefit without giving yourself an impossible amount of work, that's understandable.

For the moment I'm more than happy to switch between the old and new ADoF as required - they both certainly have their strengths - and will look forward to what happens as you continue development on it. I'm excited to try out the near blur stuff. Will there be any changes to the way the near plane encroaches on the foreground? Being able to set a high near plane value and effectively banish near blur entirely is really useful to some shots, but it's not possible with ADoF (new or old) at the moment. I don't know enough to understand why the other dof.fx shaders are different.

I'd be interested to know a bit more about the fine and coarse AO settings in MXAO. I have two layer enabled, but when I change the value of either they seem to have exactly the same effect (in both old and new MXAO). I don't know what I expected, but I suppose it was that coarse would deal with larger, more ambient shadowing and fine with more detailed shadowing -- but I suspect I've got this completely wrong.

The old DoF had various features that were just useless for 99% of the users so I ripped them out and cut the amount of tweakables down. Actually telling me "I want it to look like X" is the most helpful - some people with rarely any idea what they talk about give me a huge paragraph full of nonsense throwing together a bunch of programmer buzzwords.

The near blur curve max value should remove any near plane blur, does it not? I explicitly gave a high upper limit so the user can do this - I never use near blur so I use that value set to maximum all the time.

The fine and coarse AO work like this: In a checkerboard pattern, the fine AO radius multiplier reduces the sample radius so for every "white" chessboard pixel you have full radius, for every "black" one you have full radius times fine AO radius mult. The Fine and Coarse AO intensity mult basically control the AO in the white and black chessboard pixels. The perceived intensity of the AO goes down a bit since for areas the coarse AO applies on, only half of the pixels contain AO, the rest is white so you might need to crank up the overall intensity a bit to see it properly. I'm not satisfied with the feature and I plan to remove it somewhen soon since I'm in the process of rewriting MXAO to do a proper occlusion integral, it'll maybe be slower but will look a lot better.

This of course will happen after the DoF is finished, which will take quite some while. If you're interested in alpha/beta testing, you might want to check out my Patreon since I dispense my WIP shaders via my Discord (this is pretty new so no worries if you haven't noticed yet, I didn't advertise this anywhere properly).

Marty McFly wrote: The near blur curve max value should remove any near plane blur, does it not? I explicitly gave a high upper limit so the user can do this - I never use near blur so I use that value set to maximum all the time.

It works for the other versions of dof included in the standard dof.fx file (matso, gnumbers etc), but not for ADoF in that file, nor the new ADoF. I can't remember if it's always been like this--I think there was discussion quite some time ago on here, someone else mentioning similar, but I can't remember the outcome. I know I stumbled across the discussion when I was looking for a solution after I noticed it happening in GTAV. I may have only just started using ADoF at that point, or it might have been introduced with an update to it, I'm sorry I can't remember more clearly.

What seems to happen is if I move the focal plane (I only use manual focus) anywhere farther into the distance than maybe 0.01 or 0.02 it starts to bring near blur into the foreground, but it doesn't appear to be tied to the main blur strength - it's almost like it's some kind of basic blur, quite weak but very noticeable, idk. it's odd.

I'll try to get some examples to show you.

Edit: I was wrong, it doesn't happen with the new one (not that I can see anyway). With the old version the blurring is slight, but enough to take the sharpness off the in-focus objects.

Heyo Marty! It's me again, hope you're doing well. I have to say, I'm in love with qUINT so far. MXAO and Bloom are for me pretty much flawless and Lightroom does absolute wonders for poorly colour-managed games. Unfortunately, no comments about ADoF yet because without mouse AF it's honestly pretty hard for me to test it out like I normally do with DoF. Hopefully that's something you're planning to add in the future. Also, I'd rather wait until you're done with the near-plane bleed stuff too.

About SSR, it works really really well. I feared it was going to be almost gimmicky, since it affected all faces in a scene, but give it the right conditions and wowie does it work some magic. Find a rainy scene, turn on SSR, slap on some DepthHaze and DoF, and bam:

There are a few glaring artifacts here and there, but that's probably because I had my SSR settings really cranked just playing around and getting that proper "wet surface" look. I would like to ask though, is normal biasing possible for SSR? You can tell there's some flat shading issues occurring on the fisherman statue's belly and face, as well as the lamp in general. However, they are pretty low-poly models so the effect's likely more exaggerated.

Onto the rest of the qUINT suite, I'd first like to respond to some of the other issues other users have posted about, since for the most part I managed to mitigate those on my side. I'm not entirely too sure what UTwelve was trying to bring up, but there's that "fuzzy" look to it that really only goes away when quality's cranked up to Maximum (sometimes Ultra or Auto). It kills frames, but something else I noticed is that when set to Maximum, dropping the render scale down to 0.5 still looks good enough and returns most of the frames. I had a similar "polygon"/flat-shading issue as Super Poopsy (since TS4 is in nature a pretty low-poly game), I found that you just have to crank normal bias really high ( something like 0.6-0.8 ) and set sample radius & AO amount higher to compensate for any loss.

I do have a question about MXAO, what do the AO/IL blend types mean and how do they work? I can't really tell a difference flipping through them, sometimes one will make AO darker, sometimes it just looks the same.

Thanks for all your work, Marty.
Also, is your discord patron-only? It would be nice to have it open for discussion, but I understand if it's a secret club kinda deal.

Marty McFly wrote: This is not 100% correct but much faster than the curve stuff since computing a curve means 9 full rate instructions (more than 2 cycles) where max() is 1 full rate (1/4 cycle) per sample tap.
That's why the bokeh response is a tiny bit different than computing the mathematically correct curve but a ton faster. In theory, a gamma of 2.2 is 100% correct in terms of energy conservation so the blur looks same brightness as the unblurred source (Otis if you're reading this, this might be useful for your DoF) - actually sRGB but it's commonly approximated with 2.2 gamma.

Interesting. I'm also in the process of rewriting it as I recognized the way I blur is really too expensive, and I need to do it differently to make sure the situations where there's a lot of difference between near/far plane blurs properly. Worked on understanding Jimenez2014 further but there's something missing, and code contains a catch22 so there's something they're not telling which is essential. I ran into this tutorial however: catlikecoding.com/unity/tutorials/advanc...ring/depth-of-field/ which is for unity but explains near/far plan blur separation (and thus different averaging) in one pass. This tutorial is interesting with respect to the remarks above, as it describes a different formula for brightness reduction, see point 4.7: weighted average of the colors in the pre-filter pass.

About your curves for blur ranges: They work when the camera is further away from the subject, but I always have had problems with them when the camera is close to the subject, e.g. in a portrait, where you want to have e.g. the eyes in focus and from there on already have things go out of focus rather quickly (like behind the ears it should already be out of focus more or less) That's very hard to do with the adof curves (at least I couldn't get it to work). Something to consider in your rewrite

The near plane bleed you're having now looks cool. My guess you used tiles for near plane to get max CoC for in-focus/farplane pixels next to near-plane pixels so the near plane pixels properly bleed?

amobae Well, good to see that it works out, I knew that this issue existed in the old file, hence I modified the focusing to accommodate for that.

altokitty thanks for all the compliments Mouse based AF is something I have been hesitant to add because it won't get remembered when you restart the game so it's not persistent. About the SSR, I suppose it could really benefit from smoothed normals, even more than MXAO. Probably need to do a much more complex filter than the current one will need to see about that one. The fuzzy look of MXAO is _probably_ the more relaxed filter - I fixed the offsets so it doesn't produce any kind of pattern anymore and made it more aggressive.
Trust me, you only see that in debug.

If the filter misses some parts and the AO pattern comes through, you definitely see it in regular mode, hence I decided to make it a bit more aggressive.

Most people tweak MXAO until it looks good in debug and then switch to normal, that's not the way its supposed to be. Sometimes you can go several quality levels lower with no problems, even if it looks somewhat bad in debug.

My Discord is still a bit under construction (hence I haven't advertised it yet) but it's not Patron-only, only special ranks with beta/alpha access are patron only. I can understand though if you're not willing to donate just to join it, hence it's open.

OtisInf Well, tiles is the way to go since it allows you to make scatter as gather fast enough (the current filter is still a lot slower than my current DoF). What I've posted on those screenshots is actually a pretty idiotic but working solution which I might keep, however I made the ring binning based approach from A life of a bokeh work and it just looks better - I went ahead and just ignored the UE4 source code and wrote it down what I thought it should look like and apparently, it works. It's however very slow due to the insane amount of ALU but I run it in full screen. Haven't optimized it in any way yet but I don't want to do this until it's perfect. What I need is some post filtering, I spend the last days trying to devise a sort of iterative median or anything that doesn't react on outliers that much.

Mouse based AF is something I have been hesitant to add because it won't get remembered when you restart the game so it's not persistent.

What does this mean exactly? I haven't had any issues with mouse AF with the old shaders and Otis' current one, but then again I'm one of those users that only toggles DoF while taking screenshots and not during regular play.

The MXAO comments are interesting, I always thought debug was there to help users properly config things. I do switch between debug and regular often while configuring though, and my comments about the fuzziness and how I fixed it actually came from configuring without debug view. I had noticeable fuzziness with sample count lower than Very High, though I suspect that's probably MXAO struggling with the very poor depth buffer in TS4 (something about the DB in that game is very odd, it's incredibly small compared to other games and makes configuring for it somewhat tricky). Other games work just fine with Medium and sometimes lower samples.

Asking again in case you missed it, how do the different AO/IL blend types work? Just curious as to whether there's a "recommended" option out of the few.

As for the Discord, I actually couldn't find an invite link, hence me asking about it. Maybe I'm just blind. But I think I'll let you set it up proper before joining anyways.

By the way, and I'm just curious, is the RT AO concept you were working on now completely scrapped? How did it actually match up to your current and future AO methods, visually? I understand if the diminishing returns performance-wise were too great, but I do have to wonder if RT AO works any better than current AO.

altokitty wrote: What does this mean exactly? I haven't had any issues with mouse AF with the old shaders and Otis' current one, but then again I'm one of those users that only toggles DoF while taking screenshots and not during regular play.

Regular config settings are stored in the config file, whereas the last clicked mouse position isn't. So if you boot up the game again, the mouse position is reset and your previous focus point is lost. That means you can't ship the config with a preconfigured focus position, hence I was hesistant to add yet another switch to enable/disable this behaviour.

The MXAO comments are interesting, I always thought debug was there to help users properly config things. I do switch between debug and regular often while configuring though, and my comments about the fuzziness and how I fixed it actually came from configuring without debug view. I had noticeable fuzziness with sample count lower than Very High, though I suspect that's probably MXAO struggling with the very poor depth buffer in TS4 (something about the DB in that game is very odd, it's incredibly small compared to other games and makes configuring for it somewhat tricky). Other games work just fine with Medium and sometimes lower samples.

Hmm, can you show me some screenshots or possibly short video of that? What radii do you use? The fuzzyness of AO is proportional to the radius, Medium might work on low radii where for huge radii, higher qualities are needed, hence the "Auto" option which just scales the sample count with radius. Also it might be advisable to change the far plane value (RESHADE_DEPTH_LINEARIZATION_FAR_PLANE) to something lower or higher, whatever works best (use DisplayDepth shader to tweak).

Asking again in case you missed it, how do the different AO/IL blend types work? Just curious as to whether there's a "recommended" option out of the few.

Pasting the math here probably wouldn't help you. They are just some artistic choices which I thought to look correct - AO should be integrated into lighting system but since that isn't possible on ReShade, I just had to find some blending modes that happened to look correct. I prefer the first one which is probably the intended one but people requested different blending modes (listing "Overlay", "Soft Light" etc which have no relevation to this whatsoever but I wanted to prevent custom builds with weird modes showing up so I added some other ones). The main differences are that blend type 0 applies IL multiplicatively, type 1 adds it up somewhat based on luma, 2 is a really weird one that takes color difference into account so IL doesn't cause oversaturation if IL color and original color are similar, 3 is basically 0 computed in sRGB (approximated).

As for the Discord, I actually couldn't find an invite link, hence me asking about it. Maybe I'm just blind. But I think I'll let you set it up proper before joining anyways.

discord.gg/sMg8Qg

Feel free to join, I plan to post my progress there mostly since it kinda drowns in the screenshot thread.

By the way, and I'm just curious, is the RT AO concept you were working on now completely scrapped? How did it actually match up to your current and future AO methods, visually? I understand if the diminishing returns performance-wise were too great, but I do have to wonder if RT AO works any better than current AO.

Cone traced AO is still on my HDD and maybe I will add it some day but it's just too slow for the visual gain. There's better ways to achieve this than brute force cone tracing and since the cone directions are purely random, it needs a different kind of denoiser than MXAO has - that's a major problem since all current denoisers for raytraced data heavily depend on temporal reprojection, something that isn't possible on ReShade. I even had a screen-space voxelizer as a proof-of-concept going a while ago but that produced too coarse AO and its static overhead made it useless for ReShade.

Compilation error in OpenGL for MXAO and Lightroom (game: Neuro 2006, RUSSIAN HIDDEN GEM!)

pastebin.com/7Fb2ePUF

(Your Bloom shader is awesome man, awesome)

Regular config settings are stored in the config file, whereas the last clicked mouse position isn't. So if you boot up the game again, the mouse position is reset and your previous focus point is lost. That means you can't ship the config with a preconfigured focus position, hence I was hesistant to add yet another switch to enable/disable this behaviour.

Oh, hm. Isn't mouse AF supposed to be dynamic in nature though? The point of it is to easily change the focus point, isn't it? And why not just have mouse AF along with regular coord-based AF, like it's always been done? Forgive me for questioning, don't quite understand why so.

Forgot to mention, the AO fuzziness I encountered is yet again likely an extraordinary case. It really only happens in tricky scenes where there's a thin object just on top of another object (i.e. glasses on a character's face). I can try to gather screenshots, but it really should be a non-issue that I was just commenting on. Thanks for the explanation about the blend types, by the way. Still honestly can't tell the difference between them though.

Oh well, I guess it's somewhat a shame that we won't get to see RT AO anytime soon. It does leave me curious about something, isn't SSR ray-traced as well? According to the config settings anyway. This is me just being not well-read so I don't understand how any of this shader stuff actually works, what are the differences between the ray-tracing in SSR and that in AO and why is SSR not that heavy of a performance hit in that case?

Also, about that screen-space voxelizer. You don't mean a shader that turns everything into cubes, do you? Or do you actually mean something like voxel-based GI techniques and all?