[Spine-js] Animation state skips frame.

Moberg · 2014年5月14日

During the transition between two animations(TrackEntry) in animation state a frame i skipped or rather the overshot time is disregarded.

E.g. if i first call setAnimation with an animation that has 30 frames and then add an animation that has 30 the total run time should be 2 seconds at the 30 fps that spine use.

The problem is in the update function of AnimationState where setCurrent is called in the frame when the first animation is done but the remainder of the delta time is not passed on to the next animation. So the total animation time required to complete the animation state is 2 sec + the remainder from the frame where the animations switch.

This is a problem for us since we drive the animations with a series of updates according to the number of frames in an animation state, resulting in the animation not completing.

var animationState = new spine.AnimationState(spineAnimationStateData);

animationState.setAnimationByName(0, 'animation1', false); // animation with 30 frames = 1 sec
animationState.addAnimationByName(0, 'animation2', false, 0);  // animation with 30 frames = 1 sec

// very bad frame rate to more clearly show my point
for every 450 ms do
this.animationState.update(0.45);
this.animationState.apply(skeleton);

this will give the followin pattern:

ms
0 animation started
450 frame 1 of animation 1
900 frame 2 of animation 1
1350 frame 3 of animatoin 1 + current animation set to animation 2
1800 frame 1 of animation 2
2250 frame 2 of animation 2

The total needed update time for this track is 2250 no 2000

Nate · 2014年5月15日

I've committed a potential fix (for all runtimes), can you try that?

Moberg · 2014年5月19日

Thanks for your reply.

You change is part of the solution.

I will try to explain the issue from a different angle.

As the runtime is now there is always only one animation being animated in any one frame if no mixing is used.
This is needed to animate any bones to their last keyframe in case they aren't part of the next animation. But the runtime could start applying the next animation at the time "setCurrent" is called like the mixing is done.

take the scenario from above with two animations queued each with 30 frames.

0 animation started
450 frame 1 of animation 1
900 frame 2 of animation 1
1350:
frame 3 of animation 1 (end event since current.time >= 1 sec)
- current animation set to animation 2
- frame 1 of animation 2 (0.35 sec into animation 2)
1800 frame 2 of animation 2
2000 frame 3 of animation 2

I now this is a very basic behaviour change but the fact that you can't predict the delta of the "lost" frame leads to problems synchronising with other animations.

Please for reply for further info if needed