Hi Gordon,
Yes, that's was what I was beginning to suspect. However, the extent to
which I think this is a new is the way the problem is amplified by the
requirements of WoWvx. An increase in z-depth resolution would probably not
help at all in this context because in order to transfer z-depth data to the
WoWvx you have to render a greyscale image to the screen, so, whatever depth
you start with, by the time the data gets to the display hardware I'm fairly
sure you only get 8-bits to play with, therefore if you have most of your
scene detail in the 'far' depth, nearly all the information is 'lost in
transit'. :-(
Chris.
----- Original Message -----
From: "Tomlinson, Gordon" <[EMAIL PROTECTED]>
To: "Chris Denham" <[EMAIL PROTECTED]>; "OpenSceneGraph Users"
<[email protected]>
Sent: Wednesday, October 08, 2008 1:14 PM
Subject: RE: [osg-users] Near and far calculation and depth maps (and
aquestion about WoWvx)
This has been the problem and trade off since the inception of the
z-buffer :)
It will get a little better with when get OpenGL 3.0 out in the wild as
that has provision for a 32 bit Zbuffer which will extend the range 32
bit is still not great
Gordon
__________________________________________________________
Gordon Tomlinson
Product Manager 3D
Email : gtomlinson @ overwatch.textron.com
__________________________________________________________
"Self defence is not a function of learning tricks
but is a function of how quickly and intensely one
can arouse one's instinct for survival"
- Master Tambo Tetsura
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chris
Denham
Sent: Wednesday, October 08, 2008 8:00 AM
To: [email protected]
Subject: Re: [osg-users] Near and far calculation and depth maps (and
aquestion about WoWvx)
Hmm, thinking about the implications of Wojtek's message in more detail
leads me to think that the only way to get this right is to make sure
the near plane doesn't get too close to the camera.
In my simple test, a scene with small cubes inside a large cube, once my
camera moves inside the large cube, the calculated near plane has a
negative z value, which is then adjusted (by clampProjectionMatrix) to
(nearFarRatio*zfar) because this is greater than calculated znear.
Effectively, I think this means that once inside the large cube, the
near plane is locked incredibly close to the camera, thus depth values
for other things within the scene get pushed way back. My suggested
change in my first message on this thread helps with this problem, but I
seem to get the same effect whenever any object gets very close to the
camera.
I can workaround the problem by setting CullSettings::_nearFarRatio
(default=0.0005) to a much higher value e.g. (0.1), but this of course
has the unpleasant effect of clipping objects close to the camera.
Oh damn it, I sense that I am treading on a very old computer graphics
problem that human vision solves so well by being able to ignore near
things that are not of interest or insignificant.
Chris.
----- Original Message -----
From: "Chris Denham" <[EMAIL PROTECTED]>
To: <[email protected]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, October 08, 2008 10:48 AM
Subject: Re: [osg-users] Near and far calculation and depth maps (and a
questionabout WoWvx)
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_disparit
y_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:
camera->: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.or
g
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
