Apparently my confusion stemmed from the fact that I thought we were discussing a solution in the osgviewer application. This seemed like the logical place to me, given that the analogous playback support is located in the osgviewer app.
However, given that osgProducer had record support embedded, then perhaps osgViewer is the better choice for location. -Paul > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Robert Osfield > Sent: Thursday, May 31, 2007 2:13 AM > To: osg users > Subject: Re: [osg-users] Recording an AnimationPath in osgviewer > > Hi Paul, > > You need to re-red my post from yesterday evening explaining > how users can work at different levels of granulatity. The > crux is that user can if he wishes set the view matrix after > the update traversal, its not normal for this to happen, but > its perfectly doable and reasonable thing to do - but if they > do using the update callback to get the camera position on > each frame will result in a value that is one frame out of date. > > Robert. > > On 5/31/07, Paul Martz <[EMAIL PROTECTED]> wrote: > > Sorry, Robert. I'm still not following you. > > > > Jeremy proposed getting the view information via an update callback > > attached to the top level Camera node. And you replied with > the following: > > > > > Ideally you'd be able to write a event handler that > doesn't require > > > an mods to the core Viewer classes, the actual event handling and > > > writing out to .path will be fine, but.. the missing bit will be > > > getting the final view matrix on each new frame. One > could possible > > > do this via an update callback... > > > but what if one uses this already, or a user modifies the view > > > matrix after update traversal, the only time you can be > sure of the > > > value of the view matrix is inside the > > > renderingTraversals() method... right now I'm not sure of > > > > To me, this reply of yours implies that we should not > impliement this > > as an update callback attached to the Camera node because, > apparently, > > osgviewer might already have an update callback attacheed to the > > Camera node, or might otherwise be altering the view matrix > after the update traversal. > > > > 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(). > > > > I think we are miscommunicating somehow, or I'm just thick... > > -Paul > > > > > > > -----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/ > > > _______________________________________________ > 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/
