[SLE / SSE / FO4] Depth of Field

[Marty McFly]

People actually liked this grain? O.o I've never seen someone using it.
@MXAO: With some performance decreases, yes. Most of MXAO's performance comes from the part where it switches to higher miplevels of the depth and color texture. I may be able to port the AO part only (otherwise texColor and texOriginal are just not enough, I'd require a third fullres texture).

But one thing may be possible: on old GTASA I did something I called hybrid ENB: ENB loading a second ENB. effect.txt was single pass in 0.075 so this was necessary for some effects. If I wrote to alpha channel in first enb instance, the second one could read it (instead of being 1.0) so maybe I can write gray scaled color to alpha on ENB, let ReShade read that and compare it with its own version of gray scaled color. The only difference will be the HUD, ENB's one will not have the HUD, ReShade will.
So I can pixel accurately mask the HUD in ReShade shaders and use DoF and AO with ReShade.

But if ENB overrides the alpha thereafter or ReShade fails to read it, there's nothing I can do. But why not wait for Boris to implement his AO?

[Oyama]

Some people, especially screenarchers, might like having grain in blur.
I will think about implementing another method which would not require a texture, as a choice.

@SSAO : Because I don't think Boris can implement it, according to what he told me. He can't extract albedo, neither set it with proper maths. Thanx Beth. We would have the first SSAO/SSIL from old 0.119 versions, with bugs on transparent objects and all that...
Hmmm... MXAO implementation would be great.
Or I can think about implementing a raymarch SSAO in it.
OR we would wait for Beth to implement HBAO+, but if it's the same than in FO4... bleh.

[Marty McFly]

Raymarching is no magical solution, it's still SSAO, hella accurate but a good approximation (SSAO, raymarched or not, is still an approximation as well though) can deliver 95% of the quality at 1/10 the cost. I have worked months and months on MXAO. You won't find a (visually) better AO estimator in screen space, except if it grabs data MXAO on ReShade can't get. I did a full port of HBAO+ on ReShade and MXAO is on par with it. Good thing I rushed the MXAO release before HBAO+ went open source, otherwise ppl would think I'm a stealer because my AO estimator is very similar to HBAO+. I compared Boris' AO on old GTASA (which is just like the AO on old Skyrim mods) and imho I'd say MXAO looks better. His one will run faster of course.
BUT it's no match for his current AO. I think you understood him wrong. If he can't extract albedo properly, he still can take advantage of all the other stuff like normal map textures and so on. So his SSE AO will never look like the old Skyrim AO. With disabled IL, you won't see a difference. It's just the IL part that's causing problems. No IL doesn't necessarily mean he only can use face normals and so on.
There's this comparison video. Only AO is enabled, no IL. Most ofthe visual difference is caused by the normals, the new algorithm takes care of all the small cracks and wrinkles because it reads the normal maps of the game. The old algorithm just uses the normals of the 3D models, like MXAO.
However no albedo means his blending math is a bit incorrect but as his AO can grab a lot of data MXAO (or his old AO) don't, even false math will look better.

[ENBSeries]

I didn't say that will not implement ssao/ssil. I just said it will look awful, because of albedo (and extration of ambient color too, to apply ao to it)

[Oyama]

Thanx for explanations Marty.
Well, Boris, sorry if I misunderstood. I really hope you can sort it off.

[Marty McFly]

Hmm, SSE 1.3 crashed for me the first time I ran it with ENB. Just lucky that it works now.

[Oyama]

C'mon, Beth just read you were going to port MXAO, and they didn't like it, that's all...
1.3 crashes on me each time I make heavy modifications to shaders or preset.
Usual Beth

[Marty McFly]

Updated file to 1.4, link in OP.

Changelog:
fix bug with tilt shift + postblur, add preview window for bokeh shape, add second mask mode, add option to make blur width independt from screen size (FHD -> DSR no longer changes perceived blur width), add autofocus smoothing (correct-ish, recursive function can never be fixed fully), changed functionality of fADOF_InfiniteFocus, various code restructures and improvements to improve performance, modify default file for plug&play gameplay config instead of crazy test values


The preview window for bokeh shape is a cool thing! It directly represents the current bokeh shape and even though it runs the bokeh blur a second time, it should eat little to no fps =)
It has one bug though, Temporal AA heavily affects it (small white dots on black surface make the effect of TAA extremely visible) so it bugs and blurs a bit when moving the camera, nothing to be done about that unfortunately.

[Oyama]

Great fixes.
Autofocus smoothing solves DoF flickering when setting values <0.1 for Focusing time in enbseries.ini.
And thank you for indexing on Pixel Size !
Very nice work !

Edit : found it interesting to inject Otis's desaturation code (emphasize) in your DoF.
For those interested in, quite simple to add.

These for GUI :

Code: Select all

/* Depth Desaturation */
/* 0 == off (normal DoF), 1 == greyscale, 2 == single colorscale */
int		iADOF_DesaturationMode		
<
	string UIName="Desaturation mode";				
	int	  UIMin=0;	  
	int   UIMax=2;	 
> = {0};

/* Blend color for Desaturation mode==2 */								
float3	iADOF_Desaturation_BlendColor	
<
	string UIName="Desaturation Blend Color"; 		
	string UIWidget = "Color";			 
> = {8.0, 0.0, 0.0};	

/* Factor with which DES_BlendColor is blended with grey. 0 is complete grey, 1.0 is complete blend color */
float	iADOF_Desaturation_BlendFactor	
<
	string UIName="Desaturation Blend Factor";		
	float UIMin=0.0;  
	float UIMax=1.0;  
	float UIStep=0.001;	 
> = {1.0};		

/* Desaturation Amount */
float 	iADOF_DesaturationLevel 
<
	string UIName="Desaturation Level";   
	float UIMin=0.0;  
	float UIMax=100;  
	float UIStep=0.001; 
> = {0};

And this code at the end of the PS_DoF_Combine pixel shader, (just before :

Code: Select all

	scenecolor.xyz = lerp(blurredcolor.xyz, unblurredcolor.xyz,smoothstep(4.0,0.25,discRadius));		
	scenecolor.w = 1.0;	
	return scenecolor;

}

)

Add :

Code: Select all

	

....
        /* Blurred areas desaturation */
	if(iADOF_DesaturationMode > 0)
	{
		/* Grey scale blurred pixels based on depth */
		float greyscaleAverage = (blurredcolor.r + blurredcolor.g + blurredcolor.b) / 3.0;
		float4 desColor = float4(greyscaleAverage, greyscaleAverage, greyscaleAverage, blurredcolor.a);
		/* Blended color in desaturation */
		if(iADOF_DesaturationMode==2)
		{
			desColor = lerp(desColor, float4(iADOF_Desaturation_BlendColor, blurredcolor.a), iADOF_Desaturation_BlendFactor);
		}
		blurredcolor = lerp(blurredcolor, desColor, saturate(blurredcolor.a * iADOF_DesaturationLevel));
	}

[MaxG3D]

1.4 seems to be acting weird in Fallout 4. It seems to be related to gauss blur. I exaggerated its value to make it more obvious.