goToFrame has no lasting effect on running animations.
It's effect on paused animations is lost on resume.
Example here:
http://babylonjs-playground.azurewebsites.net/#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.