Hi Paul, On 7/6/07, Paul Martz <[EMAIL PROTECTED]> wrote:
Providing better support for this is a good idea. But subclassing from Viewer won't help people using SceneView.
Yes, but it shouldn't be difficult to port across to osgViewer::Viewer, many of the method should easy to map across, often the method naming is identical albeit composed in a slightly different way for instance: sceneview->setProjectionMatrixAsPerspective(...); maps to viewer.getCamera()->setProjectionMatrixAsPerspective(..)
From what I remember of embedding OSG in my non-OSG app using SceneView, you'll need to handle the following issues: * Set your projection and modelview matrices in SceneView. * Disable SceneView clearing. * Disable auto computation of near/far in CullSettings. * Surround the SceneView::draw() call with glPushAttrib/glPopAttrib, glPushClientAttrib/glPopClientAttrib, and glPushMatrix/glPopMatrix for all matrix stacks, including all texture matrix stacks. * Keep in mind that OSG thinks it owns OpenGL state, so if your app changes state behind OSG's back, OSG won't know it changed and therefore won't try to change it back to what you're requested in OSG. Best solution is to wrap your own code in all the necessary push/pop calls. There are other, less elegant, solutions. When all set up correctly, you should be able to do your own glClear, draw some OpenGL, draw OSG using SceneView, draw more of your own OpenGL, then swap buffers. It's a little like duct tape and cotter pins, but it works. :-)
I'm curious about the change to disable the compute near/far, is this so the depth range matches up so 3D objects all appear in the same range? W.r.t state, this is the most awkward of the issues, one has to protect the other OpenGL code's state from inheriting into OSG without it knowing about it, and visa-versa. Robert. _______________________________________________ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
