Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow to choose whether or not to calculate root motion when seeking #4418

Closed
TokageItLab opened this issue Apr 19, 2022 · 0 comments · Fixed by godotengine/godot#60774
Closed

Comments

@TokageItLab
Copy link
Member

TokageItLab commented Apr 19, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant