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
Describe the problem or limitation you are having in your project
Root motion predicts the previous animation position based on delta and calculates the root transform. Currently it is always calculated correctly, even during seek. This has side effects.
For example, if the root bone has a different transform at the beginning and at the end in animation, NodeOneShot will set the animation back to 0 with seeking when it fires (you may not notice unless the FadeIn value is 0), meaning that there will be a rapid rollback animation at the time of the firing. This also gets in the way of looping by seek.
2022-04-19.10.09.49-1.mov
You can see that the grid is moving rapidly when the timing of OneShot fired.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
It has already caused serious bugs/limitations with NodeOneShot and others. This fix would allow users to control animation without having to provide a special case for root motion, such as when synchronizing animation at an arbitrary speed from a script using Seek. It will also help it when implementing godotengine/godot#57959.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
After fixed:
2022-04-19.10.13.34-1.mov
We need to add an implementation that allows passing parameters such as bool::seek_root or enum SEEK_MODE as arguments to the blend process.
Or it could be implemented in such a way that only rollbacks are avoided. It is simple, but perhaps the root motion is not calculated correctly when an animation that is playing in a playback-forward is seeked in a playback-backward.
If this enhancement will not be used often, can it be worked around with a few lines of script?
No, animation process is core.
Is there a reason why this should be core and not an add-on in the asset library?
Most people who use root motion need this.
The text was updated successfully, but these errors were encountered:
Describe the project you are working on
3D Character Game
Describe the problem or limitation you are having in your project
Root motion predicts the previous animation position based on delta and calculates the root transform. Currently it is always calculated correctly, even during seek. This has side effects.
For example, if the root bone has a different transform at the beginning and at the end in animation, NodeOneShot will set the animation back to 0 with seeking when it fires (you may not notice unless the FadeIn value is 0), meaning that there will be a rapid rollback animation at the time of the firing. This also gets in the way of looping by seek.
2022-04-19.10.09.49-1.mov
You can see that the grid is moving rapidly when the timing of OneShot fired.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
It has already caused serious bugs/limitations with NodeOneShot and others. This fix would allow users to control animation without having to provide a special case for root motion, such as when synchronizing animation at an arbitrary speed from a script using Seek. It will also help it when implementing godotengine/godot#57959.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
After fixed:
2022-04-19.10.13.34-1.mov
We need to add an implementation that allows passing parameters such as
bool::seek_root
orenum SEEK_MODE
as arguments to the blend process.Or it could be implemented in such a way that only rollbacks are avoided. It is simple, but perhaps the root motion is not calculated correctly when an animation that is playing in a playback-forward is seeked in a playback-backward.
If this enhancement will not be used often, can it be worked around with a few lines of script?
No, animation process is core.
Is there a reason why this should be core and not an add-on in the asset library?
Most people who use root motion need this.
The text was updated successfully, but these errors were encountered: