Thanks Wojtek,
That's very useful information. I must admit, the non linear relationship
between depth map values and view space z coordinates was something that
escaped me. I had assumed the depth value spread was linear between near and
far planes.
So that leaves me with a question about the wowvx disparity function. How do
I control its parameters so that it reliably generates a 'good' greyscale
rendering of the depthmap? By 'good' I mean one that has enough contrast to
allow the WoWvx display to show autostereoscopic effects.
The fragment shader code for the wowvx disparity function used in OSG look
like:
float disparity(float Z)
{
return
(wow_disparity_M*(1.0-(wow_disparity_vz/(Z-wow_disparity_Zd+wow_disparity_vz)))
+ wow_disparity_C) / 255.0;
}
Where:
return value: The greyscale value to render.
Z: The depth value from depth map texture.
Default uniforms for WoWvx 20inch display
wow_disparity_Zd = 0.459813f;
wow_disparity_vz = 6.180772f;
wow_disparity_M = -1586.34f;
wow_disparity_C = 127.5f;
If the depth map values from OSG are in general always optimal enough to
render the scene properly, then it seems that I need to dynamically adjust
(once per frame) the WowVX disparity constants to prevent the
autostereoscopic effect from fading in and out or disappearing as I move the
camera through a scene.
If that's true, I have no idea how to proceed other than perhaps a rather
kludgy idea of generating a histogram of depth values and somehow adjusting
the disparity constants based on ranges of the histogram that have 'detail'.
That's ugly and unreliable!
Having said that, I have actually looked at the histograms of the depthmap
values, and it did appear as though something might not be quite right about
the depth map because as I move through the scene, the values seem
occasionally get all bunched up at the far end (close to 1.0), and these are
the cases when I get problems.
Help!
Chris.
Date: Tue, 7 Oct 2008 11:11:46 +0200
From: "Wojciech Lewandowski" <[EMAIL PROTECTED]>
Subject: Re: [osg-users] Near and far calculation and depth maps (and
a questionabout WoWvx)
To: "OpenSceneGraph Users" <[email protected]>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; format=flowed; charset="ISO-8859-1";
reply-type=response
Chris,
Please read following page, until final conclusion:
http://www.sjbaker.org/steve/omniv/love_your_z_buffer.html
So if you have gone to the conclusion you should now understand why
computeNearFar is added to OSG. It simply allows to better utilize depth
buffer range. Compute NearFar using primitives is simply more precise than
using bounding volumes so this may explain why you got better results with
COMPUTE_NEAR_FAR_USING_PRIMITIVES.
You should also know that depth buffer spread does not linearly correspond
to view space z coordinate. Thats why when displayed as grayscale some
objects may be hard to discern (especially if 24 bits are clamped to 8
bits). Depth buffer values are spread non linearly so when put into
monochrome image they often end up with so similar colors that image looks
completely flat (either white or black). You may want to add special
shader
to pseudo color depth buffer like in topographical maps to actually notice
variety of depth values.
I hope this helps a little ;-).
Cheers,
Wojtek
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
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
