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:
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 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.
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
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.
