You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 3, 2024. It is now read-only.
For some of the "out" style animations (outElastic) there is very often a visual pop, where the last time step snaps everything into place. This piece of code is probably to blame:
lett=this._elapsedTime+deltaMS;letended=(t>=time);this._elapsedTime=ended ? time : t;this._apply(time);
Together with the visual pop I'm seeing, I'm guessing the code is somewhat incorrect. I'm not sure what the deltaMS value is (is it the next natural timestep, or is it time elapsed), but I'll speculate that it is the next natural timestep. If so, we shouldn't immediately set time completed at THIS time, but instead apply just normal (non-ended time) and modify the next timestep so it roughly matches the actual time left.
Instead of digging into the details, I did find a simple workaround that removes the visual pop however, that others also might want to do if the experience the pop. Simply replace this line:
this._elapsedTime=t;
Basically we disregard the actual end time and just run with whatever time will elapse. I'm not sure why this seems to remove the pop and I haven't dug further into fixing the underlying cause, but at least everything is smooth, worst case with less precision on time elapsed.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
For some of the "out" style animations (outElastic) there is very often a visual pop, where the last time step snaps everything into place. This piece of code is probably to blame:
Together with the visual pop I'm seeing, I'm guessing the code is somewhat incorrect. I'm not sure what the deltaMS value is (is it the next natural timestep, or is it time elapsed), but I'll speculate that it is the next natural timestep. If so, we shouldn't immediately set time completed at THIS time, but instead apply just normal (non-ended time) and modify the next timestep so it roughly matches the actual time left.
Instead of digging into the details, I did find a simple workaround that removes the visual pop however, that others also might want to do if the experience the pop. Simply replace this line:
Basically we disregard the actual end time and just run with whatever time will elapse. I'm not sure why this seems to remove the pop and I haven't dug further into fixing the underlying cause, but at least everything is smooth, worst case with less precision on time elapsed.
The text was updated successfully, but these errors were encountered: