hi all,
Stride documentation: DOF Areas Areas of the depth of field. There are three main zones defined by their distance from the camera: near out-of-focus area (from X to Y), in-focus area (from Y to Z), and far out-of-focus area (from Z to W)
my camera sits on -5, the cube on 0. autofocus is deactivated.
the DOF values are measured from the camera lens, I presume
so my sharp area should be (in my world coordinates) from -4 to 42 on Z
this is visible in all techniques:
dof.vl (28.2 KB)
so I do net get a fully sharp, clear picture but the best is this; introducing a glow around the edges
on 6.7
ok this problem seems to be depthmap related. this “targeting” rectangle lies super close on top of the images. the moment I put any 3D element in the background everything gets drawn as intended.
I dont understand why the dof is trying to blur this texture at all, since its sitting in the middle of a (super large) sharp area.
could some of the devs share their insights on why this is happening?
You need to tweak a graphics compositor (first link in a post) Exclude UI from PostFx by default · Issue #1154 · stride3d/stride · GitHub
Not sure how to do it properly in gamma tho…
This is quite famous problem with stride, not sure there is a cure for VL…
There is this custom postfx region you likely can also avoid that using it…
I noticed that too. When there is no 3d object, the far area doesn’t blend correctly. Not sure where this error comes from. I think this is a bug in Stride. Or they never have the case that the background is “empty”, and there is always something to blend.
Does it work with a Background entity?
This seems to be a common issue.
Eideren on the Stride discord said:
DOF leaking out of the focus area is quite common, I haven’t looked at how stride’s implementation is done, but this was very noticeable in 3rd gen games with DOF. I think Baldur’s Gate has an implementation that does not exhibit this issue, not sure how theirs work though. The picture with the square is another limitation, I would bet that DOF blurs the whole screen based on the depth buffer, the square does not draw to depth as it is transparent. When sampling for depth, DOF would retrieve the depth for the background behind the square and so would blur it as strong as the background would be
More context and info here Chapter 28. Practical Post-Process Depth of Field | NVIDIA Developer
If the rectangle uses transparency enabled, it doesn’t take part in the depth buffer calculations and therefore doesn’t influence its own blur. For that, you have to model it as a mesh and render without transparency.
hey, thanks a lot for the additional info @tonfilm
yes of course, transparent stage does not write to depthbuffer. I suspected the dof bluring kernel not having any depth info and assuming infinite distance.. this explains everything.
workaround atm is a large piece of geometry in the background.
Thanks!
