qUINT

I'm having issues in both Mass Effect 2 and ME3 - maybe these just don't work, then again, this thread shows it is possible? I'm a noob at this stuff. I've got the QUINT shaders, but I keep getting an error with ADOF failing to compile. In "statistics" it gives this error: "... qUINT_dof.fx(608,17-61): error X3548: in ps_3_0 uints can only be used with known-positive values, use int if possible".

When I click on "edit" for qUINT_dof.fx, the particular line with the error is: "uint3 chromaMode = (uint3(0,1,2) + iADOF_ShapeChromaMode.xxx) % 3;".

Any help would be appreciated.

That's a known bug, change the uint to int, that should work but gives warnings on DX11. Until I get git working again on my system, I can't push any fixes yet.

Hi, thanks for the reply. I actually worked this out yesterday, and while it did remove the error message I was receiving, I was still getting no depth buffer access. I had to download Thalixte's d3d9.dll to enable depth buffer access for dx9 titles (like Mass Effect 2 and 3). While mxao, dof etc work now after a lot of work to figure everything out, they still look far from perfect. I'll need to spend some time trying to get the settings right, dof is being a particular pain. Regardless, thanks for the help, much appreciated.

This is fixed in the next ReShade update: github.com/crosire/reshade/commit/e2ee01...01b91438cca63be41331

Hi, Crosire !

The pb is that the new update does not embed the PR i made for d3d9. Have you found some time to check it ?

Best regards

Hi Marty,

Not sure if this is necroing the thread or not (long time lurker, 1st post), but I'm having trouble with the Lightroom shader, but only with one game so far (Star Wars Knights of the Old Republic 2), that does not give me an issue with other shaders, including depth-buffer based ones like MXAO and ADOF. Additionally, Lightroom has worked for me in other games, like Fallout New Vegas.

Perhaps it's due to being OpenGL? I think I recall Crosire mentioning that OpenGL games can only handle so many Reshade shaders at once? I'm not sure.

Anyways, anytime I activate Lightroom, my screen glitches out like the following:



I've played with all the pre-processor definitions, swapping the shader orders, nothing prevents it.

Anyways, I would like to give an enormous amount of praise to the no-hassle approach that qUINT takes, I want a small list of shaders that can do a lot of things instead of a huge buffet-type thing.

Great work as always, Marty!

EDIT: I have Reshade 4.2.1, the most current Steam version of the game, 2nd latest drivers for my GTX 1080 (don't want to mess up my nVidia Inspector bits for my dx9 games ATM), and I have the most current version of qUINT from your github installed.

Yes, this is a known bug, can't fix it at the moment since for some odd reason, git won't work so I can't update the repository. Latest update of Lightroom has an optimization where it uses an internal LUT to render the color grading to and afterwards reads it, instead of doing the expensive color grading on the entire image. Now I use screen coordinates to construct the LUT and in OpenGL, vertical axis is flipped so the LUT is entirely buggy.

Any news? Can't you upload the new release package via other channels (sharing services) ?

Yes, got git working finally. Jeez, I tried everything short of a Windows reinstall. Now OpenGL is giving me major hickups - I think I fixed that problem with the LUT you have, since it's merely caused by the handedness of the coordinate systems in OGL vs DirectX. I'm testing on Quake 2 and for some reason, the shader doesn't draw to the right half of the 4K LUT I use internally to process the CC.

Apparently, when the LUT texture size exceeds the screen size, ReShade refuses to draw to the areas outside (so for Full HD, a LUT with a width of <= 1920 is OK) but that must work so it's a ReShade bug. Can't really verify that I fixed this particular problem of yours if ReShade acts up.

Updated qUINT, see github for more details.

Besides some super minor stuff, a huge update to MXAO just went live!
MXAO (as you maybe know) is based on Alchemy AO and therefore, along with HBAO+ and ASSAO which all work more or less the same, state of the art of 2012-2014.

Nowadays, SSAO in any form is considered a solved problem and not much effort is going into it anymore since current-gen solutions are as good as it gets with screen-space data. GI is done with more sophisticated tech and then there's Ray Tracing knocking on the door.

Current state of the art method of computing SSAO is called Ground-Truth Ambient Occlusion, short GTAO. It's a fairly new method from Activision, which is considered an upgrade to HBAO and tries to estimate the occlusion as physically accurate as possible.
Since there is no official source code available, only broken implementations of third parties around, I had to come up with my own take on it, which is now live. It's enabled by a new preprocessor define MXAO_HQ (see file content), it is a tiny bit slower than regular MXAO, radius behaves a bit different, Angle bias is not used and right now there's no IL, I'm currently trying to figure out how to properly integrate that.

To show you what it can do, here's a comparison to off vs on (open in 2 tabs and switch back and forth). Overall the occlusion looks more plausible and isn't just blanketed everywhere surfaces meet in in angle.

OFF:

ON:

Marty McFly wrote: Apparently, when the LUT texture size exceeds the screen size, ReShade refuses to draw to the areas outside (so for Full HD, a LUT with a width of <= 1920 is OK) but that must work so it's a ReShade bug. Can't really verify that I fixed this particular problem of yours if ReShade acts up.

Yeah, it is a ReShade bug. Hadn't had any luck tracking that down yet.

Marty McFly wrote: Updated qUINT, see github for more details.

Besides some super minor stuff, a huge update to MXAO just went live!
MXAO (as you maybe know) is based on Alchemy AO and therefore, along with HBAO+ and ASSAO which all work more or less the same, state of the art of 2012-2014.

Nowadays, SSAO in any form is considered a solved problem and not much effort is going into it anymore since current-gen solutions are as good as it gets with screen-space data. GI is done with more sophisticated tech and then there's Ray Tracing knocking on the door.

Current state of the art method of computing SSAO is called Ground-Truth Ambient Occlusion, short GTAO. It's a fairly new method from Activision, which is considered an upgrade to HBAO and tries to estimate the occlusion as physically accurate as possible.
Since there is no official source code available, only broken implementations of third parties around, I had to come up with my own take on it, which is now live. It's enabled by a new preprocessor define MXAO_HQ (see file content), it is a tiny bit slower than regular MXAO, radius behaves a bit different, Angle bias is not used and right now there's no IL, I'm currently trying to figure out how to properly integrate that.

Great Job Marty! This new method looks amazing.
I was hoping so much for an update like this.

Here there are some comparison screens I took from the now-free Assassin's Creed Unity game, using default values:




Becouse of forum limitations, I couldn't upload every screen comparing MXAO with in-game solutions (SSAO & HBAO+).
If someone's interested in this, you can found them here: imgur album
[hr]Edit:
Testing the HQ version further, I realized that the setting MXAO_TWO_LAYER doesn't work.
Is it intended or it still has to be implemented?

Wow, looking much better than I expected after the Sponza Atrium examples.

Duran.te Guess I should employ you to take promo pictures, I just take random snapshots. Neither IL nor double layer are currently working, in theory GTAO's method of integration shouldn't need this feature but I'll consider it. IL will be added at some point, I'm currently struggling to find a clean solution. Glad to see it performs well for you, one thing that caught my eye in your pictures is that the blur - even though entirely noise free - is a bit mushy. Maybe I can improve that.

Uncle Crassius Well, I don't cherry pick example pictures The Sponza scene is ideal for me to protoype and I was too lazy to fire up a game just to make comparison pictures.

Marty McFly wrote: Uncle Crassius Well, I don't cherry pick example pictures The Sponza scene is ideal for me to protoype and I was too lazy to fire up a game just to make comparison pictures.

Hehe, I figured as much. Would've downloaded without further pictures anyway. How's the voxel lighting stuff going, if I may ask? Might not be proper to ask after you just gave us something cool but you're a bit of a tease, you know.

Marty McFly wrote: Updated qUINT, see github for more details.

Besides some super minor stuff, a huge update to MXAO just went live!
MXAO (as you maybe know) is based on Alchemy AO and therefore, along with HBAO+ and ASSAO which all work more or less the same, state of the art of 2012-2014.

Nowadays, SSAO in any form is considered a solved problem and not much effort is going into it anymore since current-gen solutions are as good as it gets with screen-space data. GI is done with more sophisticated tech and then there's Ray Tracing knocking on the door.

Current state of the art method of computing SSAO is called Ground-Truth Ambient Occlusion, short GTAO. It's a fairly new method from Activision, which is considered an upgrade to HBAO and tries to estimate the occlusion as physically accurate as possible.
Since there is no official source code available, only broken implementations of third parties around, I had to come up with my own take on it, which is now live. It's enabled by a new preprocessor define MXAO_HQ (see file content), it is a tiny bit slower than regular MXAO, radius behaves a bit different, Angle bias is not used and right now there's no IL, I'm currently trying to figure out how to properly integrate that.

To show you what it can do, here's a comparison to off vs on (open in 2 tabs and switch back and forth). Overall the occlusion looks more plausible and isn't just blanketed everywhere surfaces meet in in angle.

You're really a gift to gamers community, man! Welcome back!

Marty McFly wrote: Glad to see it performs well for you, one thing that caught my eye in your pictures is that the blur - even though entirely noise free - is a bit mushy. Maybe I can improve that.

This is the only thing that was bothering me a little in my testing (while viewing pure debug mode of your MXAO). Even higher amount of samples (32-64) could not fix this "issue" (and give me as clear image as in your normal MXAO). Of course nothing too visible during normal gameplay, so it's not that important right now.
Personally I think that this this update is very nice - In my opinion looking a lot more natural right now. For me it's a great improvement for sure. I'm happy to see you still working on (and constantly expanding) your projects.

Of course it's more natural now, no more SSAO classic "darkening aura" around objects

lowenz wrote: Of course it's more natural now, no more SSAO classic "darkening aura" around objects

You won't experience this issue even in his older MXAO (no dark outline around objects that are not in contact with each other). I'm thinking mostly about better ground shadows (below/ next to some object) and smoother (more blended/ less "edgy") shadows at the walls (created by some smaller objects - like bricks or wooden blocks). There is not longer just a little darkening (where objects are touching the ground) but more visible "shadow" below most objects (npcs, tables, chairs or cars).

@Marty McFly

Marty I'd have a request I've been thinking for a while.

Due to Reshade generic injection there's no way to determine precisely when to load MXAO, so it's very common to see Ambient Occlusion passing through game's vfx (fog, smoke...).
An easy solution would be to play with intensity and fade out values, but that wouldn't solve the problem caused by near-camera vfx, and lowering the intensity too much would make MXAO nearly useless.

What I was thinking was making MXAO auto-correcting based on the image displayed on screen. (Some sort of Eye-Adaptation)
So, if the blackest areas of the image visualized in that moment would start greying out / decontrasting after a detonation of a smoke-bomb, the Ambient Occlusion would adapt to it by greying out itself accordingly.

Would something like this be possible somehow?
I'm a bit tired of applying color grading to hide ambient occlusion as much as possible