AnimationTree - Allow reusing existing nodes / multiple connections

[Flavelius]

Describe the project you are working on

RPG like game

Describe the problem or limitation you are having in your project

When trying to model upper body/lower body behaviour in BlendTrees it soon becomes obvious that there needs to be a lot of duplication. It's quite normal to have a full-body animation tree that blends in difference upper body animations while also affecting the lower body in certain states, for example spell casting; in contrast to FPS/shooters, spell casting animations typically involve the whole body. This requires the animation system to play the spellcasting anmation on the whole body when the character is standing still, but only on the upper body when it is moving while allowing to blend between both at any time.
Currently this means needing duplicate blendtree content and 'duplicate input parameters', which is mainenance heavy and feels unnecessary, just to have synced upper/lower body animations when needed while also allowing overrides.

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

If animation nodes could have multiple output targets, it would be a simple blend2 node that improved the situation, as the blend2 could then be used to just filter out body parts from the output allowing it to mimic layering like in other engines. Whole blendtree graphs could be reused and just blended with filters where needed, keeping all attached animations in sync and just using a single parameter set.

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

Just allow output connections to be attached to multiple other nodes

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

It is probably not a few lines of script as it likely involves the way the GraphEdit itself works.

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

It's part of the regular animation editing workflow and potentially adds up a lot of possibilities

[Flavelius]

Maybe this could be achieved in the form of a 'Reference' like node for simplicity. This Reference node references another one's output. Internally this would probably only require checking for closed loops, but would not further touch other nodes.
I'm not sure how these are processed internally, but i would assume that blending an animation into itself is not prohibited, which means the basic prerequisites for handling this virtual multi-output are already there.
I really hope someone can tackle this as it's way too much additional work and very error prone currently having to duplicate (manually mind you) whole parts of animation trees and handling all their duplicate inputs via code.

[AThousandShips]

@CristianCape Please don't bump without contributing significant new information. Use the 👍 reaction button on the first post instead.

[leandrodreamer]

I find this feature quite important for advance animation systems, things like blending different sets of filters become almost impossible in complex trees.
something like a node with an input and two outputs would also be a nice option but seems like animation nodes can only have a single output.
i tried to implement something like @Flavelius idea using the newly added AnimationNodeExtension godotengine/godot#99181 but was unable to do it myself, may still be possible for someone that understand better the inner workings of the animation tree system (i may keep trying).
Still a build it node like that or just allowing outputs to connect to multiple inputs would be a very nice feature that Ive found missing in multiple cases now.

[TokageItLab]

I guess it is theoretically possible with some restrictions although it may not be practical.

However, there is some knowledge they should be aware of ahead of time. As I have explained several times elsewhere, BlendTree does not have the blend result of the chain in the middle, but iterates over all valid chains to process the time. In it, weights are irreversibly accumulated and the blend is computed only once, returning the result at the end of the process. This is due to the high computational cost of blending.

So it is not possible to duplicate only the blend result.

The idea that comes to mind to make this feasible is to internally duplicate all children connected to the left of it: imagine that a BlendTreeA stored as tres can be placed in multiple in another BlendTreeB, so you just do that internally if you want to implement this proposal's behavior. But, if you use it too much, you may experience performance problems due to the amount of memory it takes up.

The restriction and why it is not practical are that internally duplicated AnimationNodes cannot synchronize their times with each other.

For example, AnimationNodeTimeSeek would affect all valid AnimationNodes chained to the left, but if it is to the right of the duplicated AnimationNodes, it would not be able to affect the duplicate source. It is weird that the branch A is also affected by the seek, even though the seek is occurring at the branch B.

Anim1　　　　　　Output A
　　　> Blend2 <
Anim2　　　　　　TimeSeek - OutPut B

So the synchronization will be broken at that point.

It is bad for a branch to look as if it is synchronized when it is not. Also, this problem still occurs even if the blend iterating process is changed so that intermediate results can be obtained. I think this is the reason why branching output of the animation node is not possible with Godot as well as other game engines.

Given that such implicit corruption is taking place, I think the maximum compromise that could be implemented in the core would be to provide an editor helper option, such as making the selection into a single AnimationBlendTree, to make it easier to duplicate the BlendTree.