Hello Andy,
First of all, thank you for responding, I wasn't even sure the mail got
through ;-)
Hey Sebastian,
I've been looking at this off-and-on for a while now, though I have no clean
solution. From my investigation it looks like the osg::CullVisitor tweaks the
_computed_znear and _computed_zfar values to their needed settings during the
handlle_cull_callbacks_and_traversal() call in the apply(osg::Camera&) method.
Once the traversal call is complete, the znear and zfar values are correct for all
the geometry under that camera. The problem is that between that point and the code
a few lines down where the z-values are reset for the next camera there is no
mechanism to install a callback to retrieve the computed values.
The two solutions I was going to try were:
1) Attach a custom node to the scenegraph in a way that assures it is the last
node traversed, is always visited, yet doesn't influence the scene bounds, and
then cache off the znear and zfar values from the CullVisitor using a cull
callback on that node (seems tricky to manage)
Okay, seems like this a valid approach, yet it sounds like a kludge. I'm
just wondering how to achieve the "yet doesn't influence the scene
bounds"-part.
Or:
2) Subclass the osg::CullVisitor (which we've already done anyway in our project),
copy/paste the virtual apply(osg::Camera&) method body, and insert the code
that I needed to cache / broadcast the z-values after the traversal.
Okay, sounds a litte bit cleaner. If I understood this correctly, the
Cullvisitor, depending on if it is the first or the second camera will
either store or set the near-far value?
I'll think about it and try.
In either case the callback or broadcast mechanism could update the projections
for any other cameras down the pipeline before they're hit by the CullVisitor.
What I really want is the ability to give one camera references to other cameras as sort
of "projection slaves" and have the osg::CullVisitor set the slave projections
after the traversal. I haven't dug through the osg code enough to see if that paradigm is
valid or if there's a more obvious solution I'm overlooking.
I really hoped, that may be Robert could drop in some words here. He
might point us to the obvious solution.
Note that this is all in theory. I haven't been tasked to fix this issue yet in
our code, we've just been using hard-coded fixed near/far values in the interim.
That's exactly my approach right now. Unfortunately this won't work for
geocentric databases in any case ;-)
I'm still waiting for two features in OpenGL: 256bit depth buffer and
separate stencil buffer targets that work with FBOs ;-)
cheers
Sebastian
- Andy
------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=50742#50742
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
