Hi Paul,
This can't possibly be the case. We know how osgviewer works, and it doesn't alter the view matrix after the update traversal. So it seems to me that Jeremy's proposed solution would always obtain correct view information. In fact, Jeremy's proposed solution seems like the right way to do it: Place all the functionality in the osgviewer application and don't alter the core classes at all. Also, no need to derive from Viewer, and no need to use anything other than Viewer::run().
You are right, but doing that in a "generic" way inside osgViewer::Viewer class could help anyone to develop, save and set AnimationPaths, and also get the camera in a safe way if you want to use the viewer embedded. Anyway a simple way could be save the camera view matrix inside the rendering traversal, and then you can always get a safe camera value of the last frame. This It will not affect too much to the viewer functionality and the RecordAnimationPath could be done easily. Rafa.
-----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Robert Osfield > Sent: Wednesday, May 30, 2007 4:17 PM > To: osg users > Subject: Re: [osg-users] Recording an AnimationPath in osgviewer > > Hi Paul, > > On 5/30/07, Paul Martz <[EMAIL PROTECTED]> wrote: > > I'm confused about this. We're discussing the osgviewer > application, right? > > I wasn't aware that osgviewer allowed the user to add their > own update > > traversal, or allowed the user to modify the view after the update > > traversal. As far as I can see from looking at the code, osgviewer > > sets the view in the event traversal with, say, a > TrackballManipulator. > > osgViewer::Viewer is extensible, you can subclass from it to > override the various traversals. > > You can also use it are several levels of granulatity i.e. > > viewer.run(); > > OR > > viewer.realize(); > while(!viewer.done()) > { > viewer.frame(); > } > > OR > > viewer.realize(); > while(!viewer.done()) > { > viewer.advance(); > viewer.eventTraversal(); > viewer.updateTraversal(); > viewer.renderingTraversals(); > } > > With the last one you can do: > > viewer.realize(); > while(!viewer.done()) > { > viewer.advance(); > viewer.eventTraversal(); > viewer.updateTraversal(); > > viewer.getCamera()->setViewMatrix(computeMyViewMatrix()); > > viewer.renderingTraversals(); > } > > W.r.t the proposal of having a renderingTraversals() > callback, this would provide an alternative to subclassing > from Viewer, but still allow one to override the > renderingTraversals() implememtation and catch what the > getCamera()->getViewMatrix() is. > > Robert. > _______________________________________________ > osg-users mailing list > osg-users@openscenegraph.net > http://openscenegraph.net/mailman/listinfo/osg-users > http://www.openscenegraph.org/ _______________________________________________ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
-- Rafael Gaitán Linares Instituto de Automática e Informática Industrial http://www.ai2.upv.es Ciudad Politécnica de la Innovación Universidad Politécnica de Valencia
_______________________________________________ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/