Hi Javier, Thanks for the changes. I think it does make sense to have the FrameStamp in EventQueu and GUIEventAdapter. It does raise a few wider issues though.
First up is the Viewer reuses the same FrameStamp for each frame, something which will mean the all events with have exactly the same FrameStamp regardless of when they were created. Changing Viewer/CompositeViewer so that it creates a new FrameStamp for each new Frame is probably the most appropriate fix this, and this may address other issues with this elsewhere when users rely on recording the FrameStamp over frame boundaries. Second issue is what would the appropriate FrameStamp be for each new Frame. Should the events during the current frame being rendered have the same FrameStamp as the current frame being rendered or have the same FrameStamp as the event that they will be processed in? I don't have an answer to this second issue yet... I will need to think further about this issue. Robert. On Sun, Feb 13, 2011 at 10:15 PM, Javier Taibo <[email protected]> wrote: > Hi Robert, > Sorry for the long delay in the answer, I didn't really have time to take > a look at it until now. > This is my new proposal, following your suggestions: > I have added a ref_ptr<FrameStamp> protected attribute to classes > osgGA::GUIEventAdapter and osgGA::EventQueue, with their corresponding > getter and setter public methods. > In EventQueue.cpp the FrameStamp is set for every new event created. > In Viewer.cpp, the FrameStamp is passed to the _eventQueue in > constructorInit method. > In Viewer.cpp and CompositeViewer.cpp the FrameStamp is set for the > EventQueue in the eventTraversal() method. It is also set for > GraphicsWindow's in the setStartTick method. > In CompositeViewer.cpp, the FrameStamp is set for the views' event queues > in the addView method and for the GraphicsContext's in the setStartTick > method. > This way, the events will have a reference to the FrameStamp when they > were created. This information can be used by every handler/callback however > it wants. And it shouldn't break any current working. > This leads us to the point where all began. Now the GUIEventAdapters have > the FrameStamp, and the AnimationPathCallback should use the simulation > time, not the reference time, unless I did misunderstand these concepts. > All these changes are attached. Please, take a careful look at them, and > let me know if you think this approach is adequate. > > Regards, > On Tue, Jan 11, 2011 at 5:33 PM, Robert Osfield <[email protected]> > wrote: >> >> Hi Javier, >> >> I'm afraid this change will fix your app only to break others >> (including existing OSG manipulators/callbacks) that assume that the >> event time is based on the ReferenceTime. >> >> Perhaps what is required is to add the current FrameStamp to the >> EventQueue and have events record the last assigned FrameNumber, >> ReferenceTime and SimulationTime, then allow callbacks/event handlers >> to pick which quantity is relevant to them, without making assumptions >> about what the time value is. >> >> Robert. >> >> On Sat, Jan 1, 2011 at 11:05 PM, Javier Taibo <[email protected]> >> wrote: >> > Hi everybody, and happy new year! >> > I needed to capture the frames of an OSG animation at a fixed >> > frame-rate, >> > to edit a video with them. After seeking in the list and the web, I >> > found >> > that this should be done by calling osgViewer::Viewer::frame() method >> > with >> > the correct timing for each frame, the so called "simulation time". >> > It didn't work, and after some debugging, I have found that the Viewer >> > is >> > passing the reference time instead of the simulation time. Replacing >> > this >> > single line in Viewer.cpp solved the problem for me. Instead of >> > _eventQueue->frame( getFrameStamp()->getReferenceTime() ); >> > I put >> > _eventQueue->frame( getFrameStamp()->getSimulationTime() ); >> > and the frames' timing is perfect. >> > >> > Cheers! >> > -- >> > Javier Taibo >> > >> > >> > >> > _______________________________________________ >> > osg-submissions mailing list >> > [email protected] >> > >> > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org >> > >> > >> _______________________________________________ >> osg-submissions mailing list >> [email protected] >> >> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > > > -- > Javier Taibo > > > > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > > _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
