Hi Lukasz and Robert, if it would happen that FrameTimeDelta/SimulationTimeDelta will get to OSG, I would vote for having a possibility to:
- set FrameTimeDelta to zero for the next frame (generally useful, at the start of the application, when loading a big model, when starting continuous redraws after an idle time,...) - override default FrameTimeDelta/SimulationTimeDelta computation by the custom one John On Wednesday 23 of October 2013 09:18:03 Robert Osfield wrote: > Hi John, > > If we do introduce a FrameTimeDelta/SimulationTimeDelta then it wouldn't be > replacing any of the existing time values, and current animation callbacks > that rely upon then wouldn't be changed to use the new Delta versions. > Given this I wouldn't expect any problems with using ON_DEMAND, or when > frame times are longer than usual due to loading etc. > > In general I feel that writing animation code based on absolute rather than > relative time values is generally more robust - which is why I haven't ever > encouraged it by implementing a Delta time value myself. > > Robert, > > On 23 October 2013 07:48, PCJohn <[email protected]> wrote: > > Hi Lukasz and Robert, > > > > sorry, I did not look on the source code, but I have a comment to the > > Delta[Simulation|Frame]Time. I am using OSG in ON_DEMAND run scheme, e.g. > > not > > using 100% CPU and redraw only when needed or when there is animation in > > the > > scene (CAD oriented usage model). Usually, I get continual animation only > > when > > I rotate model or move the camera (using camera manipulators). What would > > be > > the meaning of DeltaFrameTime in such user scenario? Patricularly, the > > user > > stops camera movement, watches the static scene for 10 seconds and then > > starts > > another camera manipulation. Does it mean that for the start of the second > > camera manipulation, the first frame will get DeltaFrameTime of 10 > > seconds? The > > same issue might be for DeltaSimulationTime (not sure). Getting such big > > peaks > > is definitely not something I would like. Similar issue might appear in > > CONTINUOUS_UPDATE scheme as well when loading big models, and you do not > > get > > frame update for, say, 1 second. > > > > John > > > > On Tuesday 22 of October 2013 15:59:38 Robert Osfield wrote: > > > Hi Lukasz, > > > > > > I have now done a code review and as things stand don't feel they are > > > appropriate to merge. > > > > > > The problems are that it introduces a DeltaTime property to > > > > osg::FrameStamp > > > > > but there are two distinct concenpts of time stored by FrameStamp - > > > SimulationTime and FrameTime and it's not clear what this new property > > > referrs to. From your implementation I can see it a DeltaFrameTime, > > > however, normally for simulation work you'd want to use > > > > DeltaSimulationTime > > > > > so perhaps you haven't spotted this subtle difference. For consistency > > > > it > > > > > would be required to add a DeltaSimulationTime and DeltaFrameTime, or > > > perhaps SimulationTimeDelta, FrameTimeDelta would flow better. > > > > > > Another missing element is that the FrameStamp values are passed into > > > shaders via the osg_SimulationTime and osg_FrameTime unifiorms, the code > > > for this is in osgUtil::SceneView. If we do add the delta's in then it > > > would make sense to expose them in shaders like we do from > > > SimulationTIme > > > and FrameTime. > > > > > > Robert. > > > > _______________________________________________ > > osg-submissions mailing list > > [email protected] > > > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegrap > > h.org _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
