Hi,
That's good, thanks. Svn is not cooperating right now, so I can't see the
exact change, but I think the fix from Andy is functionally about the same
as my proposed fix, and it covers the main bug that my demo was intended to
show. If you were to build against the current release of OSG, and wait a
few seconds before clicking the load button, you would see the animation
play too fast for a while before slowing down to normal speed.
There are still some odd looking things that can happen with sequences
though. For instance, you can still see this effect by loading the
animation, pausing it, and resuming it after a few seconds. It will actually
play all of the frames that would have played during the pause at one frame
per update until it catches up.The root of the problem is the line
_start += _frameTime[_value]*osg::absolute(_speed);
which says in English "The current frame started at the time the previous
frame started plus the frametime of the previous frame", which is often not
true. Bad things happen if at any time the framerate drops below the
animation's framerate. Two instances where I have seen this happen
frequently are where the animation is set up for say 30fps playback and the
actual framerate is oscillating between say 15 and 30fps, and when I do
something expensive like load a huge file into my scene that makes my
framerate drop to near zero for a few seconds. In both cases the animation
will have a wrong-looking playback speed.
I'm curious what the desired behavior is for these cases, where the
animation framerate is for whatever reason faster than the actual framerate.
Thanks,
Max
On Wed, Nov 26, 2008 at 1:32 PM, Robert Osfield <[EMAIL PROTECTED]>wrote:
> Hi Max,
>
> I have pulled down you example again and got it built against the
> latest svn version of the OSG. Running the app I'm able to find a
> solid that is walking. Placing with widget controls I can stop/start
> the animation.
>
> What should I be look for in terms of artifacts?
>
> I've merged a separate fix to Sequence today so perhaps the problem
> has already been fixed satisfactorily. Could you try the svn/trunk
> version of the OSG?
>
> 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
