-
-
Notifications
You must be signed in to change notification settings - Fork 21.1k
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
Add parameter animation_override
to AnimationNodeAnimation
#87111
Conversation
Add a parameter to override the animation of `AnimationNodeAnimation`. We can now change different animation for each `AnimationTree` node while reuse animation tree resources.
I can't understand the necessity of this at all. Since NodeAnimation is used as the base for the AnimationTree time progression, it is not very safe to change its animation frequently. This would be like adding unnecessary danger. If you really need this, a proposal is needed explaining why NodeTransition or NestedStateMachine (which can be used like AnyState) is not sufficient. |
|
These are not exact. A StateMachine works as a simple AnyState as long as it is in Nested mode, so if you have 10 animations, you just add 10 nodes. Also, since StateMachine can be saved as a resource, you can save it like Then, the only inconvenience is placing the 10 animations, so the addition an editor function that adds all the animations to the StateMachine would be sufficient like "Export AnyState as tres". NodeAnimation returns remaining time and loop information, which affects all upstream AnimationNodes. It affects the logic, such as which branches are selected and which fades are handled. NodeAnimation records the time of the previous frame for time calculation purposes, but a particular problem here is that time consistency can be severely corrupted when swapping animations of different lengths. This could be made better by implementing something like a Reset option like NodeTransition, but that would go beyond the role of NodeAnimation in the current state. To begin with, NodeAnimation is designed to specify Animation as a role, so implementing a duplicate is not a good idea, not only for AnimationTree, but for architecture in general. There shouldn't have duplicate places to select Animation. This implementation would have duplicate locations for selecting animations in NodeAnimation and AnimationTree. It means that animations selected in NodeAnimation could be overridden at any moment, which would complicate the project and confuse the tutorial. Especially it is the worst that the StateMachineEditor and BlendSpaceEditor do not show overridden values. It might be bit more acceptable if the original animation selection were eliminated and replaced rather than overridden, like #76788, but at the very least, project compatibility must be ensured and the Editor's GUI must be changed. However, that is too much to be exaggerated. It should be enough to have a function/extention that adds all the animations to StateMachineEditor as mentioned above. |
|
As I added to my comment above, this implementation is a terrible UI and will never be merged as is. TokageItLab:
ODtian:
This may not be confusing if you are developing a project alone, but can be a huge problem if someone are sharing a project with multiple people. ODtian:
MeshInstance's Material Override is implemented in consideration of possible reloading resource (to avoid to localize resource) and caching issues. Also it is relatively explicit in the GUI, but this Animation Override is not one of those cases. Also, as long as StateMachine is used correctly, the complications you describe will not occur. TokageItLab:
So this PR should be superseded with the implementation of such an editor option. |
Yes, traveling through teleport does fix this, closing the PR. |
Add a parameter to override the animation of
AnimationNodeAnimation
. We can now change different animation for eachAnimationNodeAnimation
in eachAnimationTree
node while reuse animation tree resources.A simple demo is attached: animation-test.zip
Demo gif preview:
Related issue: godotengine/godot-proposals#8818