qUINT

  • Marty McFly
  • Topic Author
More
5 years 9 months ago #41 by Marty McFly Replied by Marty McFly on topic qUINT

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
More
5 years 9 months ago #42 by moriz1 Replied by moriz1 on topic qUINT

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
More
5 years 9 months ago - 5 years 9 months ago #43 by JBeckman Replied by JBeckman on topic qUINT
Guild Wars 2 is still only DirectX 9 isn't it?

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.)
Last edit: 5 years 9 months ago by JBeckman.

Please Log in or Create an account to join the conversation.

  • Marty McFly
  • Topic Author
More
5 years 9 months ago - 5 years 9 months ago #44 by Marty McFly Replied by Marty McFly on topic qUINT
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.
Last edit: 5 years 9 months ago by Marty McFly.

Please Log in or Create an account to join the conversation.

  • moriz1
More
5 years 9 months ago #45 by moriz1 Replied by moriz1 on topic qUINT

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
More
5 years 9 months ago - 5 years 9 months ago #46 by e371 Replied by e371 on topic qUINT

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.
Last edit: 5 years 9 months ago by e371.

Please Log in or Create an account to join the conversation.

  • Uncle Crassius
More
5 years 9 months ago - 5 years 9 months ago #47 by Uncle Crassius Replied by Uncle Crassius on topic qUINT
Is it possible to have the DOF shader give blurred edges if the foreground is out of focus? Was hoping for the qUINT one to feature it. Is it technically impossible?

400
Last edit: 5 years 9 months ago by Uncle Crassius.
The following user(s) said Thank You: MaxG3D, AssassinsDecree

Please Log in or Create an account to join the conversation.

  • Marty McFly
  • Topic Author
More
5 years 9 months ago - 5 years 9 months ago #48 by Marty McFly Replied by Marty McFly on topic qUINT
@e371: There's no way for me to reproduce this, code differences are too small in order to cause this. I don't have Morrowind so I can't test either..
@Uncle Crassius: Haven't done it yet, it's one of the things I have still planned. DoF will probably receive yet another rewrite.
Last edit: 5 years 9 months ago by Marty McFly.
The following user(s) said Thank You: Tom Yum 72, WalterDasTrevas, AssassinsDecree

Please Log in or Create an account to join the conversation.

  • Uncle Crassius
More
5 years 9 months ago #49 by Uncle Crassius Replied by Uncle Crassius on topic qUINT

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
More
5 years 9 months ago #50 by Chavolatra Replied by Chavolatra on topic qUINT
i need LUT.fx for make luts.png in photoshop or Lightroom.fx accept neutral lut.png ?

Please Log in or Create an account to join the conversation.

  • Marty McFly
  • Topic Author
More
5 years 9 months ago #51 by Marty McFly Replied by Marty McFly on topic qUINT
Lightroom doesn't read LUT's. It displays a LUT onscreen, all color filters are storing their changes inside this LUT. Once done tweaking, just take a screenshot, crop the LUT and load it with LUT.fx. Then disable all the color effects except LUT.fx, done.
The following user(s) said Thank You: WalterDasTrevas

Please Log in or Create an account to join the conversation.

  • AssassinsDecree
More
5 years 9 months ago - 5 years 9 months ago #52 by AssassinsDecree Replied by AssassinsDecree on topic qUINT
Hey Marty, so I hardly know how to explain this, and I thought maybe I was just imagining it happening at first, but upon further testing, it happens consistently.

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
Last edit: 5 years 9 months ago by AssassinsDecree.

Please Log in or Create an account to join the conversation.

  • Marty McFly
  • Topic Author
More
5 years 9 months ago - 5 years 9 months ago #53 by Marty McFly Replied by Marty McFly on topic qUINT
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.
Last edit: 5 years 9 months ago by Marty McFly.
The following user(s) said Thank You: AssassinsDecree

Please Log in or Create an account to join the conversation.

  • Zantiag0
More
5 years 9 months ago - 5 years 9 months ago #54 by Zantiag0 Replied by Zantiag0 on topic qUINT
(Sorry for repeat the message, I have said this on the MXAO post but I don't know if you will read that post because it's "old")

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.

Last edit: 5 years 9 months ago by Zantiag0.

Please Log in or Create an account to join the conversation.

  • AssassinsDecree
More
5 years 9 months ago #55 by AssassinsDecree Replied by AssassinsDecree on topic qUINT

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
More
5 years 9 months ago #56 by Alabrand Replied by Alabrand on topic qUINT
For some reason ADoF doesn't work properly in FFXIV. No matter what I do the background won't change to the intended effect. Instead what happens is that the foreground is permanently blurry, but it's not the good kind of blurry. FWIW, the older and normal DoF shaders in the regular Reshade package works perfectly fine. Do you know what the issue is?

Please Log in or Create an account to join the conversation.

  • F D B
More
5 years 9 months ago #57 by F D B Replied by F D B on topic qUINT
Where can I make a donation to you Marty?
The Lightroom Shader is everything that's right in this world. Everything I've ever dreamed of!
I can't thank you enough.
The following user(s) said Thank You: Qsimil, AssassinsDecree

Please Log in or Create an account to join the conversation.

  • Marty McFly
  • Topic Author
More
5 years 9 months ago #58 by Marty McFly Replied by Marty McFly on topic qUINT
Hey man thanks for considering! I do have a Patreon ; i used to have a paypal donate button but that isn't possible anymore with a private account, everyone wants money for nothing these days... I guess I should propagate this a bit more :cheer: Hope you like the other shaders, too. And don't forget, I'm open for any suggestions, bug reports and so on.
The following user(s) said Thank You: Qsimil

Please Log in or Create an account to join the conversation.

  • Viper_Joe
More
5 years 9 months ago #59 by Viper_Joe Replied by Viper_Joe on topic qUINT
The brilliance of qUINT cannot be overstated; there really are too many shaders out there and a lot of them are rather situational. I've always used only a select few "essential" ones, namely DPX and LumaSharpen from the main repo, along with Ioxa's shaders (and recently, Fu-Bama's shaders), and now qUINT has joined that group.

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.

Warning: Spoiler!


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
More
5 years 9 months ago - 5 years 9 months ago #60 by Scorpio82CO Replied by Scorpio82CO on topic qUINT
thats maybe that you want to turn off the lightroom shader?, other thing is that you use other effects than lut shader.. only just going to work lut shader, the other instance is put the lut shader at the bottom of the list
If this doesn´t work try to put over the lut a shader called S-curve, and adjust the values,
Last edit: 5 years 9 months ago by Scorpio82CO.

Please Log in or Create an account to join the conversation.

We use cookies
We use cookies on our website. Some of them are essential for the operation of the forum. You can decide for yourself whether you want to allow cookies or not. Please note that if you reject them, you may not be able to use all the functionalities of the site.
Ok Decline
More information