Jump to content

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


Recommended Posts

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

Example here:


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

Steps to reproduce the bug:

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.)

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

press "s" -> the animation is paused

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

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.


Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...