[SLE / SSE / FO4] Depth of Field

[Marty McFly]

Hmm I should really pre configure it a bit, usually it contains exaggerated values from testing etc. Good choice is setting near blur amount to 0, then tweaking the focus things to see where the focus is and how it behaves and tweaking blur radius and so on for your taste. On the fly I would recommend autofocus, focus pos and radius as it is, near blur mult to 0, far blur curve to 2.0, blur radius pixels to 10, infinite focus to 0.1 or lower. That way looking at close objects will blur far stuff with a decent blur width.

[ExtremeElementz]

I should really pre configure it a bit

If you could that would be awesome, would make it a lot easier for someone new to enb to try out the effect. Obviously not something high on the priority list but maybe if you wanted you could put your suggested baseline in the original post so people could tweak it themselves? Either way thank you for creating such a cool looking DoF. Can't wait to retry it again

[Oyama]

Marty

- Would you think about including a Tilt-Shift function ?
- Would it be possible to make the whole shader resolution-dependent ?

[Marty McFly]

Tilt-shift: yes, absolutely.
Resolution dependent: what do you mean? Like blur radius not in pixels but in fixed percentage of screen dimensions ( raising resolution on same screen size currently lowers relative blur width because texels are smaller )?

[Oyama]

Exactly. The effect does not behave the same in 1080p than in 4480x2520, f.e. Without changing any setting, upping the res impacts bokeh shapes.

Edit : I do also think that making the whole thing resolution-dependent will allow for better development of postprocess effects in your DoF shader, grain and all that.

Anyway, Tilt-shift will already be something. I tried to port 2 methods with no success. Being much more skilled than I am, and this being your house, you'll make in a snap I guess.

While we're at it, your MXAO is the only reliable and effective method for this game at the hour we're speaking. Especially, to my taste, because it integers IL as well. Game's AO is a shame, and Boris is being held by the fact he can't extract albedo.
Fact is, when chaining ReShade 3.0.5, MXAO is applied (logically) after ENB effects, hence creating severe artefacting with DoF especially.
Is there any workaround, in your opinion ?

At last, I managed to implement dynamic Bokeh shapes rotation, works neat. But, as you said, timer-related intensity o/ weighting seems pointless and with no real interest.

float2 currentVertex;
float2 nextVertex;
float2 matrixVector;

float fADOF_RotationSpeed =lerp( lerp( fADOF_RotationSpeed_Night, fADOF_RotationSpeed_Day, ENightDayFactor ), fADOF_RotationSpeed_Interior, EInteriorFactor );
float fRotationFactor = abs(frac(Timer.x * ( 100.0 * fADOF_RotationSpeed))* 2.0 ); // Add - 1.0 at the end of formula to have a 'back and forth' effect : 2.0 - 1.0

#if(bADOF_ShapeDynamicRotation != 0)
sincos((90.0 + (fADOF_ShapeRotation * fRotationFactor))*0.0174533,currentVertex.y,currentVertex.x);
#else
sincos(fADOF_ShapeRotation*0.0174533,currentVertex.y,currentVertex.x);
#endif

I also DNI lerped all interesting vars, since lower Farblur and Nearblur curves are really interesting at night and in interiors.
And, (finished, i swear ), what about a desaturation control of blurred background, like the ReShade's 'emphasize' effect ? Would be something, I think, since we could make it subtle of course.

[Marty McFly]

Fact is, when chaining ReShade 3.0.5, MXAO is applied (logically) after ENB effects, hence creating severe artefacting with DoF especially.
Is there any workaround, in your opinion ?

Err, what? AO must be applied before DoF my all means. Like in ENB: All the shaders that reside in the ENB DLL (such as AO) run before all external .fx shaders. So enbeffectprepass.fx DoF is applied after ENB AO. Same has to be done on ReShade, first AO, then blur. To be safe, move AO before any other effect, I personally put AO always first, DoF always second and then how I see fit. If AO wasn't done per shader but baked into Occlusion maps, then it'd be drawn even before ReShade :p

The abs() is unnecessary in your code because frac() never returns a negative value. And since it's a rotation, you could just add up Timer to rotation value because sin/cos is periodic anyways. a sin(Sometimerstuff) does a smooth back and forth effect. Sin/cos/tan etc are slow however but then again, the DoF is fast enough as it is :p

About emphasise, I personally don't like a LOT of all those weird ReShade effects. I mean, why on earth should an out of focus object lose or gain saturation? I know it *can* be useful for some special screenshots but then again, I could invent a hundred things like that and with DNI have 10.000 parameters. The "FastDOF" for ReShade (which isn't fast to begin with) has just been created because my DOF seems to be hard to configure due to the high amount of control values already (I know that for Skyrim/Fallout, this isn't much at all but ReShade users for instance are used to max 10 params per shader).


My roadmap is currently adding Tilt Shift and DSLR (if kingeric would kindly allow me to steal the DSLR focus code because I'm too lazy to research those formulas on myself, haven't asked yet though). Maybe I can modify the Bokeh weight to look more like Matso's.

[kingeric1992]

I don't mind that, but I think it is only useful for those already familiar with their cameras, and less intuitive to those who don't, compares to a well defined foreground/background range system.

btw, to resolve the flickering, which is caused by avg under linear-space, do manual downsampling under non-linear space : x' = avg( x / (x+1) ) , then inverse the result back to linear in prepass with ( x' / (1-x') ).

[Oyama]

Thanx for the input about MXAO, but apologizes if I wasn't clear : aren't Reshade shaders applied after all ENB shaders if using both ? If yes, how MXAO could be applied before ENB's DoF ?
Once again, sorry for any misunderstanding from my part.

Thanx also for your explanation about the abs. Got it.

Nice to hear about your further devs, would be cool if you could consider resolution dependency.

[Marty McFly]

kingeric, thank you well I plan to make it optional for switching between both methods. And what flickering do you mean ? Also, doesn't the color space suffer from linear/back conversion? Or is RGBA16F enough?

Oyama, ah, I didn't know you were using ENB DOF and ReShade AO, my bad. Well in that case there is no way except modifying the AO with a code that uses the exact same focusing as the DOF you use (so MXAO knows where your DOF blurred the screen) and telling MXAO to not apply where the calculated blur is. But that is hacky af.

EDIT: Tilt Shift! Updated first post with beta version of controls, check out if it's intuitive and if there's anything I missed as I don't use such an effect like - ever.
Tilt Shift Position shifts the axis up/downwards (if it's rotated, the "up/down" direction will rotate as well so vertical axis means horizontal shift etc).
Tilt Shift Width is the size of the clear area. Basically max blur ... noblurnoblurnoblurnoblur ... max blur.
Tilt Shift Rotation rotates the axis (duh).

[kingeric1992]

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.