qUINT

lowenz This compiler errors just tell me there's some problem in resource binding that ReShade should do in the background. Need to refer to crosire here because I have no idea what's wrong.

altokitty wrote: 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.

That why I said I don't want to add yet another toggle (due to aforemeantioned reasons having only mouse driven is bad and adding an option to switch is yet another option for something as simple as that). But if it's really necessary, I can switch, as most users seem to be confident with such a feature anyways in the existing DoF shaders.

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.

Difference is miniscule without IL. With it, it's there. The fuzzyness in the official github MXAO should be way worse since it still has this culling mask that should cut out squares of AO if you only have faint high frequency detail.

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?

Actually SSR uses a modified raytracing system from the cone traced AO. For SSR you just need to follow one ray. Eye vector gets reflected and you follow that reflected vector until it hits something, then you sample that color there, and that's your reflected color. For AO, you need to take a ton of rays in various directions since AO is by definition the amount of diffuse light being blocked.
The ground truth for AO is an integral over every object in the scene and how much light it blocked. So the overhead for AO is multiple times larger than SSR.

The difference between the way MXAO works and raytraced AO is that raytraced AO specifically searches for occluders (ray-scene intersections, that is) by checking locations for an intersection of the ray and the scene. MXAO just samples some random locations around the object (so it directly finds intersections) and then tests if those intersections actually contribute. This method however doesn't ensure that all intersections are uniformly distributed per direction. It's basically like searching lions among tigers and if there is one, shooting it (RT AO) vs shooting random animals and then checking if they're a lion (MXAO and HBAO+ and most other post process AO filters).

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?

I mean something like actual voxel based GI techniques. The filter processed all voxels in a 3D volume and checked the screen location where the voxel should be and tested for correct depth values and if one was found, noted it in the voxel tree. The next step traversed the voxel structure like any other voxel raytracer. This method actually produced AO - it was just very coarse and it had the issue that I had to trick the voxel structure with heuristics because in screen space you can't infer thickness of any object so I just assumed a certain value. So the structure flickered a lot.

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

You have too many shaders installed. Delete a couple of them until the errors go away. The OpenGL backend of ReShade can only handle a smaller number of effects right now.

crosire wrote:

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

You have too many shaders installed. Delete a couple of them until the errors go away. The OpenGL backend of ReShade can only handle a smaller number of effects right now.

Thanks man!

Seems like most of the issues are fixed, now I can properly optimize it. Very ALU heavy right now but most of it should be known at runtime so I might do this with stencil instead.

Currently trying to find a mathematically correct solution for the bokeh shape based on the aperture. UE4 uses approximations, I want to do it right.

Does MXAO not work properly with old low-poly games?

I'm trying to get some AO in KOTOR2 (2004), but no matter how much I tweak the GUI settings, it makes the character's legs look as blocky as the actual low-poly mesh they consist of. I've tried using older McFly SSAO in reShade 1.0, and it worked fine without this issue, making it seem like it is an MXAO problem.

MXAO off:
cdn.discordapp.com/attachments/484730348...8-10-06_15-19-49.png

MXAO on:
cdn.discordapp.com/attachments/484730348...8-10-06_15-19-53.png

MXAO debug:
cdn.discordapp.com/attachments/484730348...8-10-06_15-22-06.png


Is the old McFly SSAO available somewhere for 3.0?

Your depth buffer settings seem to be wrong, that's not how AO is supposed to look like. Maybe switch to reversed depth buffer, add either

RESHADE_DEPTH_INPUT_IS_REVERSED=0

or

RESHADE_DEPTH_INPUT_IS_REVERSED=1

to your preprocessor settings and check if it works then.

Anyway to smooth low poly surfaces on SSR?

Marty McFly wrote: Your depth buffer settings seem to be wrong, that's not how AO is supposed to look like. Maybe switch to reversed depth buffer, add either

RESHADE_DEPTH_INPUT_IS_REVERSED=0

or

RESHADE_DEPTH_INPUT_IS_REVERSED=1

to your preprocessor settings and check if it works then.

Ok, set it to 0. The legs are still blocky though.

MXAO:
cdn.discordapp.com/attachments/484730348...8-10-07_01-55-26.png

I also tried using the old SSAO, which didn't have the blockiness, but instead it had some sort of noise around the edges of the character model

McFly SSAO (ported from 2.0):
cdn.discordapp.com/attachments/484730348...8-10-07_02-17-39.png

That's because that AO was blurred to oblivion. The new AO is supposed to only blur enough to make the noise pattern go away. I made an option to smooth the normals of the 3d models might want to try that.

Marty McFly wrote: That's because that AO was blurred to oblivion. The new AO is supposed to only blur enough to make the noise pattern go away. I made an option to smooth the normals of the 3d models might want to try that.

Ok thanks. I raised the normal bias to 0.600 and maxed the sample radius to 20 to get decent looking results. I guess this is as good as it gets:
cdn.discordapp.com/attachments/484730348...8-10-07_14-18-32.png

Marty McFly wrote: Marty you are you planning to edit your of anti-aliasing system for the qUINT?

bugmenot That's now the option I meant, MXAO has a preprocessor define called MXAO_SMOOTHNORMALS. Add MXAO_SMOOTHNORMALS=1 to the preprocessor defines or open the qUINT_mxao.fx and set #define MXAO_SMOOTHNORMALS 0 to 1.

5Alex I never wrote an AA shader..?

Marty McFly wrote: bugmenot That's now the option I meant, MXAO has a preprocessor define called MXAO_SMOOTHNORMALS. Add MXAO_SMOOTHNORMALS=1 to the preprocessor defines or open the qUINT_mxao.fx and set #define MXAO_SMOOTHNORMALS 0 to 1.

5Alex I never wrote an AA shader..?

How so?
I am asking if you are going to edit a "SMAA" system for qUINT?
the only AA system I looked at that you did was for "MMG3" but I'm talking about "MSAA" for the same qUINT,but do you are you planning to edit?

I don't see a reason for porting SMAA to qUINT. MMGE 3 is a GTA SA ENBSeries config and doesn't contain any AA shader - and SMAA and MSAA are two very different things.

Marty McFly wrote: I don't see a reason for porting SMAA to qUINT. MMGE 3 is a GTA SA ENBSeries config and doesn't contain any AA shader - and SMAA and MSAA are two very different things.

Wow ok I just thought you could do a configuration that would come to "qUINT", with the highest quality possible, for what now you understand well I think a configuration of yours for "qUINT" would be very good, it's shame you do not think so.

What's the best way to move Lightroom shader changes over to a LUT? I'm aware that you can toggle LUT overlay for Lightroom, but wondering what the best tile size value is. I'm running a 2560x1080 display, and want to know what the tile size of the LUT overlay should be to display it at 1024x32, unless it doesn't matter? I know i can resize the LUT overlay to fit a 1024x32 texture, but want to make sure i get good pixel alignment.

This shader is brilliant by the way. Just missing a highlights/midtones/shadows saturation option. But this is way more convenient than importing vanilla screenshots into Adobe Lightroom and taking the long route.

imgur.com/a/FFj1RZN (labelled before and after for comparisons) - only other shader used is SMAA.

GP-Unity wrote: What's the best way to move Lightroom shader changes over to a LUT? I'm aware that you can toggle LUT overlay for Lightroom, but wondering what the best tile size value is. I'm running a 2560x1080 display, and want to know what the tile size of the LUT overlay should be to display it at 1024x32, unless it doesn't matter? I know i can resize the LUT overlay to fit a 1024x32 texture, but want to make sure i get good pixel alignment.

This shader is brilliant by the way. Just missing a highlights/midtones/shadows saturation option. But this is way more convenient than importing vanilla screenshots into Adobe Lightroom and taking the long route.

imgur.com/a/FFj1RZN (labelled before and after for comparisons) - only other shader used is SMAA.

My understanding is that monitor resolution isn't a specific factor in LUT size, but rather the larger the more colour information it can hold and avoid banding etc. But smaller sizes can be perfectly acceptable. I remember a while back a 64 tile lut going around, and it was considered high quality. I don't know how accurate that is, but I doubt you're going to see much difference the higher you go.

I guess that raises another question, whats a good tile amount and how large should i go with the texture? I'm on 32 tiles right now, since that's what the LUT textures default to. Of course, i prefer performance impact being minimal.

1024x32 is fine. Just go with that. The only use for 4096x64 is for extremely complicated color grading, which unless you're a professional colorist, you're highly unlikely to be doing.