Welcome, Guest.
Username: Password: Remember me

TOPIC: qUINT

qUINT 1 month 3 days ago #341

Ah, the life of PC people who spend almost as much time configuring as they do playing their games.....

I spent more time today and double checked things and made written notes of what I feel.

So in general, and I don't know if other games behave the same way, be it isometric or not, in Divinity: Original Sin 2, the larger Radii Sample Radius used, the more general the shading gets. This gives us the issue of what I'd call, a soft wisp-like haloing around people and objects of larger size; say a wooden beam from a ship hanging in a tree. This soft wisp-like halo is very difficult to perceive when not in debug mode, but in Debug it's painfully obvious. The issue kind of comes from smaller Radii used, anything over 2.5 tends to give us that very generic SSAO-like halo around objects and plants. It simply doesn't look good, it's not physically accurate and blegh, ya know?

The game I feel is a bit tricky to configure around, because of this. In MXAO Ground Truth mode, the results are really not pretty; genuinely feel that isometric is difficult for MXAO. I personally feel MXAO_HQ doesn't work well, but you may think differently.

Moving on, if a large radii is to be used to get that general shading effect, it's going to cost. Both in Debug and in general tests, anything under Medium (16) was more poor than not. If we take Maximum (255) to be a type of 'ground truth' or 'maximum sample correctness' kind of thing, High (24) is somewhat necessary and anything above looks better, or different. In Debug, the larger the sample, the tighter everything gets to the point of almost entirely removing the soft wisp-like halo around characters and large objects, but still keeping this nice shading effect where it makes sense. It's just so expensive, it's soooo expensive. I will admit though that it's hard to tell in real tests without debug. Medium (16) and High (26) and anything higher up to Maximum (255) has small changes to the AO, it's really hard to tell just 'what' is changing, but there are changes. Going under Medium (16) to Low (8) or the last one (4) gives larger differences and I don't think should be used.

Anyhow, in small Radii, you can get away with Low (8) samples fairly easily, the quality doesn't change much and there's no reason to really pump it, unless you want. That's a benefit for sure.

I personally, after going back and forth too many times, prefer Double Levels in both large and small radii for the Sample Radius.

With Indirect Lighting, which no matter what settings you use, is a very negligible impact on the overall shader, you can get some beautiful results. A good example, especially for a large Radii, is being in on the shores of the ocean and having your character walk into the water and then seeing their skin and clothes take on the ocean's teal/blue color,. It's gooorgeous. Accurate, probably not, but so pretty, and in a fantasy game such as this, totally works well.

So, after handwriting this and typing it up and having anyone who reads this to get to this part, there's basically two ways to handle AO in this game specifically, and Divinity is the first game that I have played where I get access to the Depth Buffer and configure MXAO, so I don't know at all how other games can behave. Total noobie here.

Large Radii and Small Radii together, this gives a kind of GI solution, but it's not even close to being physically accurate, but it looks nice, but because you use a Large Radii, it's more performance intensive.
Or
Small Radii only, which gives us the normal SSAO type of shading, but with indirect lighting, you can get some bounce light occuring. Benefit is the performance, it's easier to run lower settings and not notice a difference.

If you want to use a Large Radii Sample Radius only, you lose out on a lot of the small details, which I feel isn't worth it. From all the vegetation to small cracks and small adjacent angles, that's all handled in small Radii.

Anyhow, these are my settings that are worth knowing. Things like the render size scale and quality are up to you, juggle performance and quality up to your own personal limits.

MXAO_SAMPLE_NORMAL_BIAS=0.250000
MXAO_SSAO_AMOUNT=1.000000
MXAO_BLEND_TYPE=0
MXAO_SAMPLE_RADIUS_SECONDARY=0.100000
MXAO_AMOUNT_FINE=1.000000
MXAO_AMOUNT_COARSE=1.000000
MXAO_SSIL_AMOUNT=1.750000
MXAO_SSIL_SATURATION=5.000000

The only thing I didn't test, mostly because I forgot, are the values for Fade Depth Start and End. I tried noticing differences earlier in the week and had difficulty noticing anything, but you may have better eyes than me, so who knows.

Sorry for the gruelingly long post. I'm bad at condensing information in a useful manner =(.
The administrator has disabled public write access.

qUINT 1 month 2 days ago #342

McFly or someone can help me.
It's fixed in menu i can change when i play start only i'ts not dynamique i Don't understand why work only in menu with map not in game

mxao fixed at scene with psy
rt fixed at same scene
ssr fixed at scene with psy in the sky
The administrator has disabled public write access.

qUINT 1 month 2 days ago #343

anontsuki wrote:
Ah, the life of PC people who spend almost as much time configuring as they do playing their games.....
Yes :) We spend half our time tweaking instead of playing!
MXAO_SAMPLE_NORMAL_BIAS=0.250000
MXAO_SSAO_AMOUNT=1.000000
MXAO_BLEND_TYPE=0
MXAO_SAMPLE_RADIUS_SECONDARY=0.100000
MXAO_AMOUNT_FINE=1.000000
MXAO_AMOUNT_COARSE=1.000000
MXAO_SSIL_AMOUNT=1.750000
MXAO_SSIL_SATURATION=5.000000
Thank you for the long post and for sharing these :) The thing with MXAO is that it can make such a difference, but every game is different and sometimes you just don't have time to experiment. I'll give these a try :)
The administrator has disabled public write access.

qUINT 4 weeks 12 hours ago #344

give us new about your RT shader, please
The administrator has disabled public write access.

qUINT 2 weeks 1 day ago #345

Hi everyone, first post here, big fan of quint and reshade.
I love SSR, but would it be possible to mask away its influence somehow? The way I imagine it is by taking a black and white of raw picture and putting it on multiply on top of the SSR treatment:


+


=>




I have a vague understanding that in order to put a version of raw image on top of treated image, some back and forth would be involved? Is it something that's even possible with Reshade? Thanks.
The administrator has disabled public write access.

qUINT 2 weeks 1 day ago #346

This works only here because the black areas between the metal bars are supposed to be empty space, in a newer game they'd be actual 3D models. What happens if you have a black car, is that not supposed to reflect? A lot of people have brought me a lot of suggestions that all sound more or less the same, they work for one singular situation, but screw up completely elsewhere.
Last Edit: 2 weeks 1 day ago by Marty McFly.
The administrator has disabled public write access.

qUINT 2 weeks 1 day ago #347

Marty McFly wrote:
This works only here because the black areas between the metal bars are supposed to be empty space, in a newer game they'd be actual 3D models. What happens if you have a black car, is that not supposed to reflect? A lot of people have brought me a lot of suggestions that all sound more or less the same, they work for one singular situation, but screw up completely elsewhere.
Toggle box?
The administrator has disabled public write access.

qUINT 2 weeks 1 day ago #348

I don't see a point in adding a feature that you have to basically toggle on and off depending on every scene, total gimmicky and wasted effort. There's a million ways to mask away screen areas, can't support them all and I don't want to. SSR on ReShade has its limitations and no gimmick code will solve that. Same with all these ideas people have to don't apply SSAO on fog, they just never really work and it's very ugly from both a programmer and user perspective to do that. If one of these heuristics worked at least 30% of times, I'd happily add it but it's one of these things that needs this exact game and this exact scene to look right and will look absolutely borked on any other scene.
Last Edit: 2 weeks 1 day ago by Marty McFly.
The administrator has disabled public write access.
The following user(s) said Thank You: jas01

qUINT 2 weeks 4 hours ago #349

Marty..You have all my respect.. but the idea its not too bad, could be useful a realtime mask like shows in the sharpening and clarity effects..and import to your SSR, even to your RT an MXAO shaders.. this could be a possible solution to the volume fogs and lightihing,, and your mask could made with black and white gradients that let see certain zones..I know beacuse made some experiments with the UIMask texture, even With the RT noise that you made for the Ray Passes, please.. You ┬┤re the best, think only that you gave us Raytracing.. why?? Beacuse YOU CAN!
In a couple of hours I will upload a video..


Here is..
Last Edit: 1 week 6 days ago by Scorpio82CO.
The administrator has disabled public write access.

qUINT 1 week 6 days ago #350

  • du
  • du's Avatar
  • Offline
My English is poor
I wrote a shader
It uses a 3dlut to generate a mask
Put ssr between lutmask1 and lutmask2
.......
//Pre {{{1
#include "ReShade.fxh"
#include "ReShadeUI.fxh"

#ifndef fLUT_TextureName
	#define fLUT_TextureName "Masklut.png"
#endif
#ifndef fLUT_TileSizeXY
	#define fLUT_TileSizeXY 16
#endif
#ifndef fLUT_TileAmount
	#define fLUT_TileAmount 16
#endif

//Setting {{{1
uniform float fLUT_AmountChroma < __UNIFORM_SLIDER_FLOAT1
	ui_min = 0.00; ui_max = 1.00;
	ui_label = "LUT chroma amount";
	ui_tooltip = "Intensity of color/chroma change of the LUT.";
> = 1.00;

uniform float fLUT_AmountLuma < __UNIFORM_SLIDER_FLOAT1
	ui_min = 0.00; ui_max = 1.00;
	ui_label = "LUT luma amount";
	ui_tooltip = "Intensity of luma change of the LUT.";
> = 1.00;

uniform float fMask_Intensity <
    ui_label = "Mask Intensity";
    ui_tooltip = "How much to mask effects to the original image.";
    ui_type = "drag";
    ui_min = 0.0;
    ui_max = 1.0;
    ui_step = 0.001;
> = 1.0;

// Texture {{{1
texture texLUT < source = fLUT_TextureName; > { Width = fLUT_TileSizeXY*fLUT_TileAmount; Height = fLUT_TileSizeXY; Format = RGBA8; };
sampler	SamplerLUT 	{ Texture = texLUT; };

texture2D tLutMask	{ Width = BUFFER_WIDTH;   Height = BUFFER_HEIGHT;   Format = RGBA8; MipLevels = 3;};
sampler2D sLutMask	{ Texture = tLutMask;	};

texture2D tBackUp	{ Width = BUFFER_WIDTH;   Height = BUFFER_HEIGHT;   Format = RGBA8; MipLevels = 3;};
sampler2D sBackUp	{ Texture = tBackUp;	};

//PS_Backup {{{1
float3 PS_BackUp(float4 pos : SV_Position, float2 texcoord : TEXCOORD) : SV_Target
{
    float3 color = tex2D(ReShade::BackBuffer, texcoord).rgb;

    return color;
}


//PS_LutMask {{{1
float3 PS_LutMask(float4 vpos : SV_Position, float2 uv : TEXCOORD, float huefactors[7] : TEXCOORD1) : SV_Target
{

    float3 color = tex2D(ReShade::BackBuffer, uv).rgb;

    // Lut {{{2
	float2 texelsize = 1.0 / fLUT_TileSizeXY;
	texelsize.x /= fLUT_TileAmount;

	float3 lutcoord = float3((color.xy*fLUT_TileSizeXY-color.xy+0.5)*texelsize.xy,color.z*fLUT_TileSizeXY-color.z);
	float lerpfact = frac(lutcoord.z);
	lutcoord.x += (lutcoord.z-lerpfact)*texelsize.y;

	float3 lutcolor = lerp(tex2D(SamplerLUT, lutcoord.xy).xyz, tex2D(SamplerLUT, float2(lutcoord.x+texelsize.y,lutcoord.y)).xyz,lerpfact);

	color.xyz = lerp(normalize(color.xyz), normalize(lutcolor.xyz), fLUT_AmountChroma) * 
	            lerp(length(color.xyz),    length(lutcolor.xyz),    fLUT_AmountLuma);

    // }}}2

    return color;
}


// ApplyMask {{{1
float3 PS_ApplyLutMask(float4 pos : SV_Position, float2 uv : TEXCOORD) : SV_Target
{
    float3 col = tex2D(ReShade::BackBuffer, uv).rgb;
    float3 bak = tex2D(sBackUp, uv).rgb;

    float mask = tex2D(sLutMask, uv).r;

    mask = lerp(1.0, mask, fMask_Intensity);
    col = lerp(bak, col, mask);

    return col;
}

// DebugLutMask {{{1
float3 PS_DebugLutMask(float4 pos : SV_Position, float2 uv : TEXCOORD) : SV_Target
{
    float3 mask = tex2D(sLutMask, uv).rgb;
    return mask;
}

//Technique {{{1
technique LutMask1
{
	pass
	{
		VertexShader = PostProcessVS;
		PixelShader = PS_BackUp;
        RenderTarget = tBackUp;
	}
	pass
	{
		VertexShader = PostProcessVS;
		PixelShader = PS_LutMask;
        RenderTarget = tLutMask;
	}
}


technique LutMask2
{
	pass
	{
		VertexShader = PostProcessVS;
		PixelShader = PS_ApplyLutMask;
	}
}

technique LutMaskDebug
{
	pass
	{
		VertexShader = PostProcessVS;
		PixelShader = PS_DebugLutMask;
	}
}
The administrator has disabled public write access.
The following user(s) said Thank You: Scorpio82CO, clayb

qUINT 1 week 3 days ago #351

I am having some issues with how the MXAO version in the shader framework applies to character models in FF14. I really like the MXAO_HQ mode so I'd love to be able to use that, but it makes ugly lines on my characters. In particular half on half-clothed characters the vertices are ugly.

Is there anything I can do to change this?

The normal reshade mxao smooths things out properly:


While the quint version applies sharper shades, as shown on the shoulder and arms here
Last Edit: 1 week 3 days ago by aqa.
The administrator has disabled public write access.

qUINT 1 week 2 days ago #352



You're using 2 completely different radius settings there, can't really compare those. And no version of MXAO has smooth normals enabled by default, so it will always emphasise the polygons of the models. Reworking the smooth normals is on my TODO but right now, my focus lies on the RT shader - which will need this feature as well at some point.
Last Edit: 1 week 2 days ago by Marty McFly.
The administrator has disabled public write access.

qUINT 1 week 2 days ago #353

I didn't mean to be rude, sorry if it looks that way.
But glad to hear you're reworking the normals smoothing.

I do have a followup question though.
Both radius are set to 5 (as shown in the screenshots), does that setting scale different in the quint version of your mxao shader?
The administrator has disabled public write access.

qUINT 1 week 2 days ago #354

No worries, I didn't take it as rudeness or anything I just found it peculiar that you would compare 2 completely different visual results and then point out differences :P

But yes, I modified the radius setting so it allows for more fine tuning as the ranges for useful values differ a lot in various games, GTA V needs super high radii, GTASA much lower ones, so I decided to square the radius setting for more granularity in the low value range but also allowing huge ranges without offering a
0 - 500 range which would be bad for UI.

So if you'd set the new shader to the same (visual) radius and then there would be quality problems, I'd need to investigate but the new shader is bound to look completely different with same UI values. I usually don't make such vast UI behavior edits but it was overdue and the old shader is still in the original repo, so I didn't break any configs.
Last Edit: 1 week 2 days ago by Marty McFly.
The administrator has disabled public write access.

qUINT 1 week 1 day ago #355

Hi Marty, how are you doing?
quick question - any solution to reduce the noise produced by GI part of PTGI?
reducing radius kinda solves the problem, but no more wide color bounces

ibb.co/jTRzd2c - radius 15 (deafult)
ibb.co/q9LDd29 - radius 8

it feels like filtering cant contain the amount of noise.


and can you plz make RT_SAMPLE_RADIUS gauge in screen pixels? will make it much easier to configure stuff.
thx
Last Edit: 1 week 1 day ago by justniggatryingtohelp.
The administrator has disabled public write access.

qUINT 1 week 1 day ago #356

Filtering is difficult, if you make the filter too aggressive, it kills off detail, if you tone it down, it lets noise slip through. Which version are you using and which other settings?

Radius in pixels is impossible to set, it can't be depending on pixel size, otherwise it looks different with different resolutions. Furthermore, since the view frustrum gets wider, the radius in pixels gets smaller with distance to stay same relative to object size so its not even the same everywhere on screen.
The administrator has disabled public write access.

qUINT 1 week 8 hours ago #357

In terms of order, should MXAO come after or before RT?
The administrator has disabled public write access.

qUINT 6 days 22 hours ago #358

Hi, I noticed that in dx12 games RT works by half, AO works, but GI does not, I tested SOTR and Elevator Demo, the access depth works correctly, I used the user dll thalixte.
Do not know what could be the reason that GI does not work?
Last Edit: 6 days 22 hours ago by Siridon.
The administrator has disabled public write access.

qUINT 6 days 19 hours ago #359

Acey05 wrote:
In terms of order, should MXAO come after or before RT?

Not together with RT at all. MXAO = crude GI approximation. RT = better GI approximation. Using them together is like wearing a cheap and an expensive t-shirt together.
The administrator has disabled public write access.

qUINT 6 days 12 hours ago #360

Marty McFly wrote:
Acey05 wrote:
In terms of order, should MXAO come after or before RT?

Not together with RT at all. MXAO = crude GI approximation. RT = better GI approximation. Using them together is like wearing a cheap and an expensive t-shirt together.

Oh, I know that, the problem is many games have very (even a couple of months old) jaggy shadows (Dragons Dogma, Dark Souls series, etc) or they lack any kind of contact shadows. RT AO is tied to the radius as well thickness, so I can't get that nice light bounce without having the AO itself be scattered as well, and inverse is true.

I tried increasing the amount/intensity of the RT AO, but as you can imagine, huge big chunky blocky halos everywhere.

MXAO HQ does exactly what I need (giving that fake contact shadows look) or making those jaggy shadows softer (example of this would be thin models in games on a character models, the amount of jaggies and the lack of feet casting shadows on the ground, that isn't a fake black circle is incredible).

I tried to fake it with SSR at one point, but honestly, my hardware is barely good enough to run RT on average at a 10-20/2-5 pending on game, and SSR simply destroys it. MXAO is the only solution I have.
The administrator has disabled public write access.