Hi Robert, Actually I think the FrameStamp is only correct in the event/update phase. I have found that in multi-threading models, using it from draw callbacks leads to some incoherences. I think it is caused because osg::State stores a reference to a FrameStamp that may be the same in the Viewer and all the other objects.
This is not a serious problem, as long as the FrameStamp is used mainly for animation timing in the event/update phase, but maybe it should be better to make a copy of the FrameStamps instead of passing a reference to a unique FrameStamp. This would solve all these problems, and I suppose it should not be a significant overhead. About the second issue, I think that it is also solved by the copy-instead-of-share approach. The FrameStamp should be set when beginning the processing of a frame and inherited in subsequent stages: event-update-cull-draw. This will give a coherence that doesn't exist right now, e.g. in a draw callback the framestamp will change if a new event/update phase is started in other thread. Regards, On Mon, Feb 14, 2011 at 4:41 PM, Robert Osfield <[email protected]>wrote: > 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 > -- Javier Taibo
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
