qUINT
- Marty McFly
-
Topic Author
rubyruby wrote: Aha, alright.
Yeah I only noticed it because I tried to use the overlay to make a LUT from the shaders I was using previously, but I just used Ioxa's CreateLUT for that in the end instead.
It's been great otherwise, I've been having fun with it all day (: thanks again!
Using that one will create the same result as there's no difference between the Lightroom LUT and that one, both will receive the (slightly off) adjustments.
Please Log in or Create an account to join the conversation.
- moriz1
-
Marty McFly wrote: Strange problems keep showing up I have literally no explanation for. Nothing changed from latest public MXAO and qUINT MXAO, it's just impossible. Are you really sure that you don't use both shaders together or older configs together with it? Try using the latest ReShade.fxh (not from qUINT but from the repo), I wasn't aware of any changes made to it.
Can you show me screenshots from both your config tab and the tab with the preprocessor options and stuff?
i am MOST DEFINITELY not enabling both shaders at the same time. you can see it in the screenshots i posted previously. for each screenshot, only one MXAO shader was enabled. there's no chance that the two were interfering with each other. i event went into my config file, deleted all instances of MXAO, and remade matching profiles on both. no change in behavior.
the ReShade.fxh from the repo is indeed different from the one you provided, but none of the differences should make any difference, since it seems to be only different in that it has a few extra global functions and variables, which your shaders aren't using.
here are my preprocessor definitions:
RESHADE_DEPTH_LINEARIZATION_FAR_PLANE=1000.0
RESHADE_DEPTH_INPUT_IS_UPSIDE_DOWN=0
RESHADE_DEPTH_INPUT_IS_REVERSED=0
RESHADE_DEPTH_INPUT_IS_LOGARITHMIC=0
pretty bog standard stuff.
the "old" MXAO i'm using is this exact version: pastebin.com/13NsGwtn
Please Log in or Create an account to join the conversation.
- JBeckman
-
Perhaps something changed in regards to that and results differ depending on API and limitations with D3D9 compared to D3D11 ?
Well obviously the shader still works so it's not completely broken but there could be some differences in how it works or acts.
That's the only thing that I can think of that comes to mind at least unless you and Marty both tested the same game and the same API when comparing results.
EDIT: Well that and maybe compare without the .FXH file, remove or comment out the include from the MXAO shader and see if it results in any differences, if all that file does is help with some HDR problem it's not going to do much for D3D9 AFAIK but the file doesn't really seem to have much in it and I doubt the game in question uses any special formats or anything.
(DXGI 1.5+ in D3D11 and D3D12 only of which only D3D11 is of interest in ReShade since D3D12 isn't supported at all plus it requires Windows 10 also.)
Well I could be wrong of course, suggestion might be useless. It seems like a possibility at least due to differences between DirectX versions.

(And since the shader was already compared.)
Please Log in or Create an account to join the conversation.
- Marty McFly
-
Topic Author
@moriz1: I found one single difference (no idea why it's like that tho) that might explain the differences, even though I cannot explain them.
yours:
sample_indirect_lighting *= saturate(dot(-sample_normal, occlusion_vector) + rsqrt(occlusion_distance_squared) * 4.0) * saturate(1.0 + falloff_factor * occlusion_distance_squared * 0.25);
qUINT:
sample_indirect_lighting *= saturate(dot(-sample_normal, occlusion_vector) * rsqrt(occlusion_distance_squared) * 4.0) * saturate(1.0 + falloff_factor * occlusion_distance_squared * 0.25);
+ -> *
Curiously enough I spotted it when skipping through the file by hand instead of a diff checker.
The angle between normal and occlusion vector is n*v / length(n) and not + length(n) so qUINT version is correct. Why there's a "+" in that code, no idea. I compared the github version which still has my old IL code, and saw little difference there.
Please Log in or Create an account to join the conversation.
- moriz1
-
Marty McFly wrote: I'm testing and developing my shaders on Witcher 3 (DX11) and GTASA (DX9) so in theory, API differences should be ruled out.
@moriz1: I found one single difference (no idea why it's like that tho) that might explain the differences, even though I cannot explain them.
yours:sample_indirect_lighting *= saturate(dot(-sample_normal, occlusion_vector) + rsqrt(occlusion_distance_squared) * 4.0) * saturate(1.0 + falloff_factor * occlusion_distance_squared * 0.25);
qUINT:sample_indirect_lighting *= saturate(dot(-sample_normal, occlusion_vector) * rsqrt(occlusion_distance_squared) * 4.0) * saturate(1.0 + falloff_factor * occlusion_distance_squared * 0.25);
+ -> *
Curiously enough I spotted it when skipping through the file by hand instead of a diff checker.
The angle between normal and occlusion vector is n*v / length(n) and not + length(n) so qUINT version is correct. Why there's a "+" in that code, no idea. I compared the github version which still has my old IL code, and saw little difference there.
i believe you are correct. changing the + to * made the old version of MXAO match the output as the qUINT version.
with that said, i prefer the "wrong" version. the application of IL seems to be a lot smoother and seems to make more sense.... perhaps there's another bug somewhere up the chain, and this bug just happens to reverse some of its effect?
btw, the old version of MXAO is from this post: reshade.me/forum/shader-presentation/187...h-il?start=600#27384
Please Log in or Create an account to join the conversation.
- e371
-
Marty McFly wrote: Strange problems keep showing up I have literally no explanation for. Nothing changed from latest public MXAO and qUINT MXAO, it's just impossible. Are you really sure that you don't use both shaders together or older configs together with it? Try using the latest ReShade.fxh (not from qUINT but from the repo), I wasn't aware of any changes made to it.
Can you show me screenshots from both your config tab and the tab with the preprocessor options and stuff?
It still not worked. I'm tried clean install reshade, different settings, and even diferent game installs - nothing helps. The MXAO included in reshade by default - works perfectly, but your new qUINT MXAO complately not worked in my Morrowind with DX9.
By the way, first time i faced with similar thing when i installed reshade 3.2.0 over 3.0.8.182, after that one of your MXAO beta(3.40.60) stops worked like that, and still not works with reshade 3.4. So maybe this problem appeared with version 3.1/3.2 and related to some reshade changes.I don't know.. i'm bewildered a bit.
Please Log in or Create an account to join the conversation.
- Uncle Crassius
-
Please Log in or Create an account to join the conversation.
- Marty McFly
-
Topic Author
@Uncle Crassius: Haven't done it yet, it's one of the things I have still planned. DoF will probably receive yet another rewrite.
Please Log in or Create an account to join the conversation.
- Uncle Crassius
-
Marty McFly wrote: @Uncle Crassius: Haven't done it yet, it's one of the things I have still planned. DoF will probably receive yet another rewrite.
I see. Good to know, thanks.
Please Log in or Create an account to join the conversation.
- Chavolatra
-
Please Log in or Create an account to join the conversation.
- Marty McFly
-
Topic Author
Please Log in or Create an account to join the conversation.
- AssassinsDecree
-
So it seems like any tweaks I make to Lightroom in one preset somehow change the same settings in my other presets as well. For example, I increased the saturation of red to 1.0 for some testing purposes and then in a preset I had never even tweaked Lightroom in already had the new setting, instead of vanilla settings of "0".
How is this possible, or rather (since i won't understand whatever the technical reason probably is), is this the intended behavior? It doesn't happen with any shader I've encountered so far outside of qUINT. I think the same this is happening with the ADOF.
Thanks so much!
EDIT: Seems it doesn't impact presets which already have qUINT settings, just ones which are new/never had qUINT settings. I was trying to add Lightroom to an older preset of mine and it had settings from when I last adjusted Lightroom in a different preset, but when I returned to a preset which had different Lightroom settings already, they were untouched from when I last tweaked that preset itself. I hope I'm bearing clear, please let me know if I should explain further. So this isn't a huge deal, but I do wonder how if it is supposed to behave this way. In terms of your ADOF, the situation is actually quite beneifical actually as I'm trying to normalize the DoF in all my AC presets with this new amazing one!
Cheers,
Merc
Please Log in or Create an account to join the conversation.
- Marty McFly
-
Topic Author
Please Log in or Create an account to join the conversation.
- Zantiag0
-
Hi, I have tested MXAO with cemu and it works great with Breath of the Wild and Super Mario 3d world, it worked with GTA V too.
But on some games it doesn't work, like on Mafia II or in PCSX2 emulator (i tried Spy vs Spy game, I think it will look amazing with MXAO). Why? It just doesn't works, and on the debug options, one option gives me a white screen and another option gives me a black screen. I have readed and I think is because the depth buffer or something like that. Is there any fix for play on these games? (and more that I want try, like Bully: Scholarship Edition)
And thanks so much to Marty for make this awesome effect (I don't know how to call it), I have a video of Breath of the Wild with MXAO and some others effects like Bloom or ambient lighting.
Please Log in or Create an account to join the conversation.
- AssassinsDecree
-
Marty McFly wrote: That's standard ReShade behaviour, keeping settings when switching to a config that didn't have this shader previously. At least, it has always been doing this for me. So you have variable foo at 1 in config A. Switch to config B that never had this shader yet, it'll add foo to config B and inherit that 1. Change it there to 5, config B will have 5, A still 1. Switch back to A (which already contains a setting for this shader), it switches to 1. Makes perfect sense.
Oof, you are right! Sorry I can't believe I never noticed this before. Sorry to trouble you. Still can't get over how great Lightroom is and the Advanced DoF. Thank you again!
Please Log in or Create an account to join the conversation.
- Alabrand
-
Please Log in or Create an account to join the conversation.
- F D B
-
The Lightroom Shader is everything that's right in this world. Everything I've ever dreamed of!
I can't thank you enough.
Please Log in or Create an account to join the conversation.
- Marty McFly
-
Topic Author

Please Log in or Create an account to join the conversation.
- Viper_Joe
-
Lightroom, in particular, is absolutely phenomenal -- it's everything anyone could ever ask for. There is, however, one weird thing about it and I'm not sure what's causing it: when I finally load the LUT with LUT.fx after using GIMP to crop it from a screenshot, it doesn't look the same as when I have Lightroom enabled.
It's not a huge difference and it doesn't look objectively worse, but it looks different enough for me to know it's not all in my head; for instance, the LUT.fx screenshot clearly has a greenish tint and slightly overblown whites, for some reason. I double-checked that nothing but the effect specified is enabled in both instances and that I'm using the default luma/chroma amount settings of LUT.fx. Any idea what might be causing this? I suspected that GIMP was the problem (even though I literally only use it to crop the LUT and then export it with the default settings as a .PNG file), but then I tried cropping the LUT with Paint.NET and the same thing happened, so I don't know what I'm doing wrong.
Please Log in or Create an account to join the conversation.
- Scorpio82CO
-
If this doesn´t work try to put over the lut a shader called S-curve, and adjust the values,
Please Log in or Create an account to join the conversation.