Hey there,
is it the expected behavior that the jme 2.0 integrated DepthOfField does not do near blurring like shown (in extreme):
dofPass.setFocalPlaneDepth(50);
dofPass.setNearBlurDepth(30);
dofPass.setFarBlurDepth(100);
timong said:
Writing a near blur would require a more detailed depth texture painting probably using two different colors for near blur transient parts and for the further part - or even more shaders?
if (depth < dofParams.y)
{
// scale depth value between near blur distance and focal distance to
// [-1, 0] range
f = (depth - dofParams.y) / (dofParams.y - dofParams.x);
}
else
{
// scale depth value between focal distance and far blur distance to
// [0, 1] range
f = (depth - dofParams.y) / (dofParams.z - dofParams.y);
// clamp the far blur to a maximum blurriness
f = clamp(f, 0.0, dofParams.w);
}
This kind of blur requires different blur radius or # of samples at each pixel. It is possible to implement but will probably be slower or require more powerful hardware than the current DoF. I am planning to implement the advanced DoF method in jME3 once the post-processing system is finished.
hey there momoko, another commercial is it? :wink:
i do not mean the blur quality itself, which is quite nice in the pic above btw, i just mean that the blur also has to occur between the focal plane and the camera. This can only be a matter of quick rewrite of the shader isn’t it? And it shouldn’t be any slower, since the pixels are processed anyway. Am I wrong? :|
Mr. Coders example seemed to have it: http://www.jmonkeyengine.com/forum/index.php?topic=2663.msg20203#msg20203 if you look at the very tip of the edge its already getting blurred again.
dhdd said:
hey there momoko, another commercial is it? :wink:
i do not mean the blur quality itself, which is quite nice in the pic above btw, i just mean that the blur also has to occur between the focal plane and the camera. This can only be a matter of quick rewrite of the shader isn't it? And it shouldn't be any slower, since the pixels are processed anyway. Am I wrong? :|
Mr. Coders example seemed to have it: http://www.jmonkeyengine.com/forum/index.php?topic=2663.msg20203#msg20203 if you look at the very tip of the edge its already getting blurred again.
Momoko_Fan said:
Are you saying the DoF shader only works on objects farther from the focal plane?
hvgopal said:
In optics, particularly as relates to film and photography, the depth of field (DOF) is the portion of a scene that appears sharp in the image. Although a lens can precisely focus at only one distance, the decrease in sharpness is gradual on either side of the focused distance, so that within the DOF, the unsharpness is imperceptible under normal viewing conditions.
There's no near blur in the current implementation of it, that's true (I wrote the shaders based on MrCoder's advice). Writing a near blur would require a more detailed depth texture painting probably using two different colors for near blur transient parts and for the further part - or even more shaders? It's a bit more complicated I guess than the current version to implement near blur withouth 'bleeding' and such problems.
I was trying to say that if you dont color it differently the further blurred parts will bleed into nearer blurred parts. When you have clear parts between those (the focused part) it will look strange when you see blurred together patches of near and far objects and between them clear parts of other objects in the focused part. I hope you can get what im saying. 
Probably it isnt a problem, I'm just wondering how its done in the full reference implementations.
PS:Also you need to blur parts that are closer in Z to avoid the basic bleeding of non blurred parts to blurred. (that's already in the shaders)
nothing special in that old dof. draw a fullscreen quad with the backbuffer texture. using the poisson disk blur (used in the bloom), vary the sample size for each pixel using the difference in z depth and a focal distance (add optional near/far range calcs). each sample also needs to be checked in z diff to prevent bleeding.
looks ok. performance wise, it can be optimized…
MrCoder said:
nothing special in that old dof. draw a fullscreen quad with the backbuffer texture. using the poisson disk blur (used in the bloom), vary the sample size for each pixel using the difference in z depth and a focal distance (add optional near/far range calcs). each sample also needs to be checked in z diff to prevent bleeding.
looks ok. performance wise, it can be optimized...
dhdd said:
MrCoder said:
nothing special in that old dof. draw a fullscreen quad with the backbuffer texture. using the poisson disk blur (used in the bloom), vary the sample size for each pixel using the difference in z depth and a focal distance (add optional near/far range calcs). each sample also needs to be checked in z diff to prevent bleeding.
looks ok. performance wise, it can be optimized...
thanks mr. coder. i thought it must be easier, at least as far as i understand shaders. unfortunately, i am really bad witht he shader details. is someone up for implementing it?
