[SLE / SSE / FO4] Depth of Field

[TreyM]

Marty, would it be possible to implement MXAO in the actual enbdepthoffield.fx file and have it apply before the actual DOF code? I know that multiple effects can be chained into the postpass.fx file so I was wondering if something similar could be done in the DOF .fx file.

Also, here is a video of the focusing behavior that was spoken of before. If this is how you intend for it to behave, I am not complaining, I just figured I'd make a video to explain what I'm seeing.

[MaxG3D]

I thought I saw ppl reporting flickering bokeh when moving or with TAA on with the file. I haven't test your shader yet, but the described problem also apears in my own Oldrim dof test build, and was resolved by the proposed technique later on.

What I meant is to do basically what pow( bokeh, Highlight) does, but in reverse, to exclude single pix highlights instead of enhance them.

something like:

Code: Select all

//prepass
    for(int i=0; i < 4; i++)
    {
        float4 tap      = tex2D( SamplerColor, coord[i]);
               tap.rgb /= 1.0 + dot( tap.rgb, LUM_COEFF); 
               color   += tap;               
    }
    color.rgb /= 4.0;
    color.rgb /= 1 - dot(color.rgb, LUM_COEFF); //inverse tone mapping 

so that you can prevent a single HDR pixel affecting your downsampled source too much that makes the bokeh flashing around everywhere.

Where do I copy that code in?

EDIT:

Hmmm... That's my current code and it kinda works but it darkens the bokeh area and leaves some black artefacts on screen:

Code: Select all

			[fastopt]
			for (float k = 0; k < i && k < 25; k++)
			{
				float2 sampleOffset = lerp(currentVertex,nextVertex,k/i);
				sampleOffset = lerp(sampleOffset,normalize(sampleOffset),fADOF_ShapeCurvatureAmount);

				#if(bADOF_ShapeChromaEnable != 0)
				float4 tap = colortexSampleChroma(colortex, coords.xy, sampleOffset.xy * discRadiusInPixels * radiusCoeff, chromaoffsets);
				#else
				float4 tap = colortex.SampleLevel(Sampler1, coords.xy + sampleOffset.xy * discRadiusInPixels * radiusCoeff,0);
				#endif
				
tap.rgb /= 1.0 + dot( tap.rgb, LUM_COEFF);

				float tapcoc = tap.w * 2.0 - 1.0;
				tap.w = (tap.w >= centerDepth * 0.99) ? 1.0 : tapcoc*tapcoc*tapcoc*tapcoc;

				#if(bADOF_ShapeWeightEnable != 0)
				tap.w *= lerp(1.0,pow(radiusCoeff,fADOF_ShapeWeightCurve),fADOF_ShapeWeightAmount);
				#endif

				res.xyz += pow(tap.xyz,fADOF_BokehCurve)*tap.w;
				res.w += tap.w;
			}

			currentVertex = nextVertex;
		}
	}
	
	res.xyz = max(res.xyz/res.w,0.0); //compiler...
	
res.xyz /= 4.0;
res.xyz /= 1 - dot(res.xyz, LUM_COEFF); //inverse tone mapping 
	
	return pow(res.xyz,1.0/fADOF_BokehCurve);
}

The "LUM_COEFF" is set as a GUI Float.

[Marty McFly]

I don't down sample the source of the bokeh pass, the bokeh pass itself runs in a lower resolution but it still grabs the fullres source texture. Later on I upscale the bokeh blurred image but then there runs a post Gaussian on it so any flickering is gone anyways.
Trust me people, it's not needed. And if it is (will run some tests), it's easier to wait for an update than trying to copy it into the code on yourself

And now everyone posted about this but ignored the Tilt Shift update. Any feedback would be appreciated

@TreyM: it's how it's supposed to behave, but maybe I can add a dampening factor based on what direction the focus is changing. I just figure it's more playable like this because DoF can be annoying in gameplay and when you don't look at a close object anymore you want your scene to be clear, not wait for the blur to go away.

[Guzio]

Marty, I have tested the new "Tilt Shift" version, for me works perfectly.

I have only two suggestions.
When the tilt shift axis is set to 90 degrees, can't change the axis position ( I mean that I can't move it to the left or right, think that it would be useful ).
In this version, also can't change the intensity of the blur and when the blur curve is set to the lower value, sharp edge between blurred and unblurred areas becomes visible ( but maybe it can be useful for screen archery

[kingeric1992]

@MaxG3D Nope.

@Marty
With linear avg, aka sampling on hdr fullres, a single pixel flashing from 0.0 to 2.0, either by TAA or moving, could potentially lit up entire bokeh shape with emphasized highlight, it has nothing to do with post process Gaussians. (which is also visible in FO4 enb default dof and bloom)

But again, how much it will affect a bokeh depend on tap count and highlight amount, the effect could be minimum that you don't have to do anything about that anyways.

[Marty McFly]

Blur curve should be way > 1, otherwise you basically jump from 0 blur to full blur. I tested Tilt Shift blur in Snapseed app for Android, it works with a curve of 2.5. And the intensity of the blur is still controlled by the bokeh blur radius. Or should I do it like in my focusing where the user has one curve and one intensity control per side of the blur so you can control the blur on each side of the axis separately. I will investigate the issue with the axis, I intended it to work like you said though so this is definitely a bug.

kingeric Ah, I got you wrong. Well, the bokeh weighting I use is different to yours (from what I remember, you basically amplify all pixels above a certain threshold, right?) so mine only acts up if one uses a high bokeh curve, then however even small changes make the bokeh flicker. I will test your suggestion though, maybe it can be useful, thanks for your input.

[kingeric1992]

My old highlight was pow(x, highlight) and pow(x', 1/highlight). Now I just straight up do lerp(avg, max, highlight), which is super sensitive to the said issue even in Oldrim.

[Marty McFly]

Well, the pow(x, highlight) and pow(x', 1/highlight) is the one that I have been using for several years now (originally got it from the iCEnhancer DoF) and from my tests, the linear/backwards conversion just kills off a lot of the bokeh highlights, if something flickers, it'll flicker afterwards as well. But that's just how bokeh works, it makes bright spots within dark surroundings stand out, otherwise we could just use gaussian like Bethesda :p

EVERYONE I added a dampening function for near focus -> far focus. It needs to be tweaked for your current autofocus settings as you don't actually see the focus change but you see the blur width change. The speed of the perceived blur width change is depending on the blur curve you use.

https://youtu.be/VTTyiVTP2jg

[TreyM]

Marty, I assume that's in an upcoming release? I don't see it in the 1.3b code.

[Marty McFly]

Yes.