Allow AnimationTree to transition from any other animation in the state machine

[Kalcen]

Describe the project you are working on

I've noticed that if I want an animation to be transitioned into from any other animation in the state machine, it requires that I make a transition from every single other animation in the state machine (unless I'm mistaken and there's an easier way to do that with an AnimationTree).

It would be nice to have an option to allow an animation node to be connected to every other animation node in the same state machine. I personally prefer to keep all transitions open ended, and control them as needed via a script. I don't like having to mess with transitions in the state machine editor, so I would rather code those connections myself. the AnimationNodeStateMachinePlayback travel() function has a "teleport" from any node feature but it doesn't use Xfade Time, and it's delayed, which seems pretty impractical to me.

Since I'm using AnimationTree's ability to play, mask, and blend multiple animations at once, I've been wondering if it would be possible to use two AnimationPlayers instead, but I don't think I could achieve simultaneous animations that way, especially since I don't think those have the ability to filter out certain bones.

Describe the problem or limitation you are having in your project

AnimationTree's transition management is cumbersome to use when trying to allow for ambiguous and open-ended transition options within state machines.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Adding an option to allow for an animation node to allow for any other animation in the state machine to transition to it.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

The option could simply be a bool toggle in the AnimationNodeAnimation inspector.

If this enhancement will not be used often, can it be worked around with a few lines of script?

I haven't been able to find any simple work arounds to this cumbersome workflow.

Is there a reason why this should be core and not an add-on in the asset library?

It's a simple addition to an existing feature.

[fire]

@TokageItLab told me that this breaks nested statemachines mathematically, but I'll poke him to explain better.

See also godotengine/godot#75759

[Kalcen]

I just set up a single animation node in a blend tree, so I could just swap out the name of that animation. So another option would be to allow for Xfade when changing an animation node's current animation, instead of making this sort of thing work within a state machine. Besides the loss of Xfade I like this approach, since I can still blend multiple animations for upper body left/right arm ect. like I normally would.

[TokageItLab]

As @fire mentions, this is already accomplished by godotengine/godot#75759.

NestedStateMachine
It is useful to list several animations, such as StateMnachine with NodeTransition. You can use this like AnyState. Seeking to the beginning is treated as seeking to the beginning of the animation in the current state.

[Kalcen]

As @fire mentions, this is already accomplished by godotengine/godot#75759.

NestedStateMachine
It is useful to list several animations, such as StateMnachine with NodeTransition. You can use this like AnyState. Seeking to the beginning is treated as seeking to the beginning of the animation in the current state.

How? I just tested it in 4.1 beta 3 and xfade still doesn't work. I tried using travel("animation_name") and travel("animation_name", true), along with setting the state machine to Root and Nested, as well as toggling Allow Transition to Self and Reset Ends on both type settings and still there's no cross fade time when using travel().

I don't see how this is any different from using travel("animation_name", true) in 4.0, it looks exactly the same to me. And honestly I don't understand whether the state machine type, or the Allow Transition to Self or Reset Ends settings matter here even after reading their descriptions several times. Their descriptions are very confusing to me for some reason, they certainly didn't seem to have any effect in my testing, so I still cant confidently say what they do since I didn't notice any differences.

[Kalcen]

I wish I had the option to just use the transition xfade time settings from the AnimationPlayer node, it has a great interface for managing transition times in "Animation > edit transitions..." and at this rate I'd much prefer to just use that since it's not solely reliant on transition links in the AnimationTree's StateMachine nodes.

[Kalcen]

Why archive this, my feature request was that it would work with xfade time, which it still doesn't seem to?

[TokageItLab]

Be sure to read the sentence properly all the way to the end.

Also, there was a feature to connect another StateMachine as the End of a StateMachine, which is also removed to avoid reference confusion
[Fixing way]: This requires actually repositioning the StateMachine as a child of the StateMachine, not the StateMachine as its reference. That means placing a loaded StateMachine, such as saving the StateMachine to .tres, and then re-connecting to it
At this point, if you need to loop several StateMachines, you must have two same StateMachines that you want to loop and create a transition that will loop them at their parent (e.g. [A->B->C->A] to [A->B->C]<=>[A->B->C])

It is not yet possible to have xfade to travel to self, since AnimationTree can only have one playback time per AnimationNode, so it need to copy self AnimationNode internally. Insteads, if you want to have a transition with desired xfade for any animation, you can do the following:

1. Create and save one NestedStateMachine containing all animations. (There is no need to interconnect these animations. This is because xfade is performed by the parent StateMachine by process 3 which will be explained later)
2. Create a RootStateMachine and place two NestedStateMachines stored in process 1, then interconnect them with transitions of arbitrary xfade, so that they loop.
3. When you want to transition the animation, change the state of the NestedStateMachine that you are not currently in, and then transition from the NestedStateMachine that you are currently in to the other NestedStateMachine by handling the RootStateMachine. This actually places two same animations, allowing transitions with xfade between the same animation.

[Kalcen]

Be sure to read the sentence properly all the way to the end.

Also, there was a feature to connect another StateMachine as the End of a StateMachine, which is also removed to avoid reference confusion
[Fixing way]: This requires actually repositioning the StateMachine as a child of the StateMachine, not the StateMachine as its reference. That means placing a loaded StateMachine, such as saving the StateMachine to .tres, and then re-connecting to it
At this point, if you need to loop several StateMachines, you must have two same StateMachines that you want to loop and create a transition that will loop them at their parent (e.g. [A->B->C->A] to [A->B->C]<=>[A->B->C])

It is not yet possible to have xfade to travel to self, since AnimationTree can only have one playback time per AnimationNode, so it need to copy self AnimationNode internally. Alternatively, if you want to have a transition with desired xfade for any animation, you can do the following:

1. Create and save one NestedStateMachine containing all animations. (There is no need to interconnect these animations. This is because xfade is performed by the parent StateMachine by process 3 which will be explained later)
2. Create a RootStateMachine and place two of those NestedStateMachines, then interconnect them with transitions of arbitrary xfade, so that they loop.
3. When you want to transition the animation, change the state of the NestedStateMachine that you are not currently in, and then transition from the NestedStateMachine that you are currently in to the other NestedStateMachine by handling the RootStateMachine.

I see, so then it is possible. Thanks for the step by step description, that helped a lot. I'll just have to add a way to juggle between the two nested states into my scripts, which seems a bit hackey, but hey this is how its done I guess.