I have a few questions about the way OSG handles depth maps, and how the
range of depth values relates to the near and far calculation done by OSG.
Firstly, just to confirm my understanding. I have assumed that the purpose
of OSG calculating near&far values is so that depth map values will range
between 0.0 and 1.0 for pixels rendered between the near and far range. Oh..
and for clipping too!? Please shoot me now if that's not correct. ;-)
As a test case, I constructed a very simple scene comprised of a large
cuboid with a number of smaller cuboids within it.
When I move the camera inside the large cuboid, I had expected the depth map
rendered by an RTT camera to show depth values of all the smaller cuboids in
the scene, but it doesn't, it just seems to contain a solid black texture.
(you can easily display an inverted representation of the depth map of a
scene using the osgViewer option '--wowvx-20')
Now, the odd thing is that if I change the nearfar calculation mode of the
RTT camera to:
camera->setComputeNearFarMode(osg::CullSettings::ComputeNearFarMode::COMPUTE_NEAR_FAR_USING_PRIMITIVES)
instead of the default, which is COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES
,the smaller cubes now appear as I would have expected in the depthmap.
I have been looking for an explantion for this difference in the OSG code
in:
bool CullVisitor::updateCalculatedNearFar(const osg::Matrix& matrix,const
osg::Drawable& drawable, bool isBillboard)
It seemed to me that there may be an issue with the code:
---snip---
//if (d_near<0.0) osg::notify(osg::WARN)<<" 3) set near with
d_near="<<d_near<< std::endl;
_computed_znear = d_near;
---snip---
which allows negative values of 'd_near' to be assigned to '_computed_znear'
and hence the near clipping plane to be behind the camera. In fact, the code
a few lines above this snippet does ignore values of d_near < 0.0, so I
wondered if this snippet should have the same logic. In fact, if I change
the snippet above (by removing the comment and putting in an else),
---new snip---
if (d_near<0.0) osg::notify(osg::WARN)<<" 3) set near with
d_near="<<d_near<< std::endl;
else _computed_znear = d_near;
---new snip---
the depth map seems correct for my test example, yippie! Let me know if I
need to put this change on the submissions list.
Ah ha.... nope.. I haven't finished with your attention yet ;-)
What follows is a different issue, only loosely related to the above:
I can see that I should expect to get a kind of 'popping' effect in a depth
map range due to culling of objects as I move through as scene. It seemed to
me that getting 'smooth' transitions in near/far calculations would be 'at
least in concept' a difficult/impossible problem to solve. You are probably
wondering why I care about this, when a even large jitters in depth map
range does not seem to affect the rendered scene much. The answer is,
because the depth map is used as part of the input to a WoWvx
autostereoscopic display. The problem is that to transfer the depthmap data
to the stereoscopic display, the depthmap gets rendered as a greyscale
image, presumably losing a lot of precision in converting to int 0-255 range
greyscale color value. The effect I get as I move through a scene is that
the contrast in the depthmap image seems to fade in and out as I move the
camera past objects in the scene, and this affects the 3D effect you get
from the WoWvx.
I can see that the WoWvx implementation in OSG does include some disparity
calculation shader code that allows adjustment of the conversion from
depthmap value to greyscale, but it is difficult to see how to calculate the
parameters 'on the fly' as you move through a scene. Does anyone have any
suggestions or advice on how dynamically keep more contrast in greyscale
rendering of a depthmap?
Chris.
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
