Bug Report: goToFrame has no effect on running animation (with playground example)

[jpdev]

goToFrame has no lasting effect on running animations.
It's effect on paused animations is lost on resume.

Example here:

http://playground.babylonjs.com/#1MLKDF#2

The example sets up a running animation and three keybinds:
g -> goToFrame, s -> pause, r -> resume

Steps to reproduce the bug:

1)
Click on the animation to set the focus to the canvas, so keystrokes go to the action manager. (You can open the console to make sure the keystrokes are actually reaching the engine, there is a console.log for each key.)

2)
press "g" -> goToFrame is called, there is no effect

3)
press "s" -> the animation is paused

4)
press "g" -> goToFrame is called, the correct frame of the animation is displayed

5)
press "r" -> the animation is resumed, but it skips back to the frame where it was before goToFrame was called

My bug analysis (based on babylon.2.4.max.js, from github dist) :

In Animation.prototype.animate (within the engine) a local variable "currentFrame" is calculated without checking the this.currentFrame while the animation is running.

Line 26891 (babylon.2.4.max.js):

var currentFrame = returnValue ? from + ratio % range : to;
"this.currentFrame" goes completely ignored.

And after that in Animation.prototype._interpolate the new calculated value is assigned to this.currentFrame.

This means the "goToFrame"-Function never has any effect on running animations.

It also means, you can't pause or stop the animation and use goToFrame because when the animation starts again, currentFrame is recalculated.

 

[GameMonetize]

Ok understood

Do you mind submitting a PR?

[jpdev]

Hi Deltakosh,

I am actually not sure how to fix this.

My goal was to have multiple rigged characters all playing an idle animation and not be synced up.
This implies, that the animations all at the same time, but at a different point.

Looking further into the code, the only way to achieve this without new variables is to set _localDelayOffset in the Animatable.
Because the same "delay" goes into all animations started at the same time and _localDelayOffset is the only variable belonging to the Animatable influencing the calculation of currentFrame.

So goToFrame would have to calculate the correct localDelayOffset so that the currentFrame calculation yields the desired frame - with the different easing functions available this seems impossible to me.

 

For myself, with the simple linear animations for my rigged models I hacked a "currentFrameOffset" into the Animatable that is added after currentFrame is calculated (and then wraps "currentFrame" around if it is greater than "to").
My Animation's goToFrame still iterates the Animatable but no longer calls goToFrame on the Animatables, instead sets the currentFrameOffset.

This nicely achieves my goal (the shifting of the animations for multiple characters) but it's not a real "goToFrame" solution, because it only sets an offset - if the animation is already running, goToFrame(50) won't actually make the animation continue from frame 50, but offset it by 50 frames where ever it currently is.

So I guess I can't do a PR - because I don't know how to solve it with the way animation is setup, sorry about that.

[adam]

If this looks good I'll submit a PR:

http://playground.babylonjs.com/#1MLKDF#3

edit:  I submitted the PR.

[jpdev]

Hi Adam,

Thank you!

Looks like I wasn't too far off with my idea to set _localDelayOffset