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-openscenegraph.org >
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
