Hi Robert, First thank you for answering me so quick,
I think that all manipulators should use simulation time, take the case of the DriveManipulator, it would be nice to use it when simulation time is altered (speed should be slower at a 25FPS rate on 3D rendering but when making my video with video editing software at 25FPS, the speed will be normal). User could be able to drive at an altered frame rate in the same way he use it with a normal frame rate (same can be applied to flightmanipulator). That's why I agree with you that modifying reference time isn't the ideal solution, and it's very valuable for osg community to modify manipulators in a way that they use simulation time instead of FRAME event like you said. I'm not sure on how to do that, but i'll try in my own manipulator... 2009/6/17 Robert Osfield <[email protected]> > HI Alexandre, > > I think your specific problem is related to how the > AnimationPathManipulator is not using the SimulationTime, rather than > the requirement that events all supply a time relating to > SimulationTime. In the case of actual device events they come in at > other times than then frame start and it's important to know how and > when device events happen in actual time. > > For AnimatioPathManipulator I can see value in making it possible to > use the SimulationTime. This manipulator could be modified to get the > current viewer FrameStamp by doing a dynamic cast to osg::View and get > the osg::FrameStamp from it rather than than FRAME event. > > Robert. > > On Wed, Jun 17, 2009 at 2:10 PM, Alexandre Amalric<[email protected]> > wrote: > > Hi, > > > > Isn't it possible to make a function in eventqueue class to set a > specific > > time ( setTime(double time) ) instead of using delta between _startTick > and > > current tick ?? We could add a variable to this class to keep in memory > an > > altered time. > > > > This way I could keep synchronisation between my custom reference time > and > > the event time. > > > > I really have to set a specific frame rate for my viewer to shoot images > at > > this frame rate, and to keep functionnality from the viewer like playing > > path. > > > > Has anyone already experienced the same problem ?? > > > > > > 2009/6/17 Alexandre Amalric <[email protected]> > >> > >> Hi Robert, > >> > >> Some explanation on what I want to do in my application. > >> > >> First I need to shoot video from rendering at a specified frame rate > >> (25FPS for example). > >> So to do that I have a callback writting images on disk every frame, and > I > >> have to slow down my rendering rate, and to increment my time from 1/25 > of > >> sec. > >> After that I call advance with this new time (+1/25s). > >> > >> But the main problem occurs when I want to play a path at this low rate, > >> the path manipulator is using real time reference to compute position > and > >> orientation so when I shoot my video at 25FPS the path is accelerated. > >> > >> I hope you understand what I need to do (my english vocabulary is > limited > >> when it comes to technical explanation, sorry for that). > >> > >> Unfortunately the only solution I had to solve my problem is to change > >> reference time with function "setReferenceTime" and give it my own time > >> computed on desired frame rate. > >> > >> 2009/6/17 Robert Osfield <[email protected]> > >>> > >>> Hi Alaxandre, > >>> > >>> You should leave the ReferenceTime alone, it's only SimulationTime > >>> that you should alter and calling frame or advance with this time is > >>> suffiicient - there is no need for the extra calls setting the time. > >>> The ReferenceTime is meant to be real-time value of the frames - > >>> something you'd use for doing stats collection etc., while > >>> SimulationTime is meant to be the time used when compute animations > >>> and physical simulations in the scene. > >>> > >>> The _startTick that the event queue uses should be the same one as the > >>> ReferenceTime uses and makes sure the ReferenceTime and event times > >>> are in sync. It's not typically appropriate to use the SimulationTime > >>> when doing event handling, but if you want to then you'll need to use > >>> the frames FrameStamp to get the current SimulationTime. > >>> > >>> Robert. > >>> > >>> On Wed, Jun 17, 2009 at 10:23 AM, Alexandre > >>> Amalric<[email protected]> wrote: > >>> > Hi osg-users, > >>> > > >>> > I'm experiencing some problem with time management and osgViewer. > >>> > > >>> > I'm under Windows Vista, OSG SVN. > >>> > > >>> > I'm using a composite viewer and my rendering code is : > >>> > > >>> > pCompoViewer->advance(MyTime); > >>> > pCompoViewer->getFrameStamp()->setReferenceTime(MyTime); > >>> > pCompoViewer->getFrameStamp()->setSimulationTime(MyTime); > >>> > pCompoViewer->eventTraversal(); > >>> > pCompoViewer->updateTraversal(); > >>> > pCompoViewer->renderingTraversals(); > >>> > > >>> > instead of : > >>> > > >>> > pCompoViewer->frame() > >>> > > >>> > because I wand to trigger my rendering with a computed time 'MyTime" > >>> > based > >>> > on a FPS I need. > >>> > > >>> > But my problem is that when I use my manipulator and ea.getTime() I > do > >>> > not > >>> > have the same time as "MyTime" when event received is for example > >>> > osgGA::GUIEventAdapter::PUSH. > >>> > ea.getTime() is equal to MyTime only when receiving > >>> > osgGA::GUIEventAdapter::FRAME. > >>> > > >>> > I tracked down this behaviour, in function > >>> > GraphicsWindowWin32::handleNativeWindowingEvent because event time is > : > >>> > > >>> > double eventTime = getEventQueue()->getTime(); > >>> > > >>> > and getTime is returning : > >>> > > >>> > osg::Timer::instance()->delta_s(_startTick, > >>> > osg::Timer::instance()->tick()); > >>> > > >>> > That's why It doesnt match my rendering time... > >>> > > >>> > Is there any way I can resolve this problem ? (Except making my own > >>> > eventqueue class) > >>> > > >>> > > >>> > -- > >>> > Alexandre AMALRIC Ingénieur R&D > >>> > =================================== > >>> > PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille > >>> > http://www.pixxim.fr > >>> > > >>> > _______________________________________________ > >>> > osg-users mailing list > >>> > [email protected] > >>> > > >>> > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >>> > > >>> > > >>> _______________________________________________ > >>> osg-users mailing list > >>> [email protected] > >>> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >> > >> > >> > >> -- > >> Alexandre AMALRIC Ingénieur R&D > >> =================================== > >> PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille > >> http://www.pixxim.fr > > > > > > > > -- > > Alexandre AMALRIC Ingénieur R&D > > =================================== > > PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille > > http://www.pixxim.fr > > > > _______________________________________________ > > osg-users mailing list > > [email protected] > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- Alexandre AMALRIC Ingénieur R&D =================================== PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
