Implement AnimationLibrary resource and respective importer

[reduz]

Describe the project you are working on

Godot

Describe the problem or limitation you are having in your project

Importing and reusing animations has always been hit or miss in Godot. Currently, animations are only imported when they come bundled in a 3D scene. It is not possible to import animations as a stand-alone mode to reuse between models.

Some improvements happened in 4.0 to improve animation compatibility, and more remain (such as re-targeting implementation), but if animations can't be imported as stand-alone, none of this really matters.

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

3D scene container formats such as FBX, GLTF2 and DAE not only contain animations, but they can contain multiple animations. They are the most common and standard way to share animations nowadays and export them from 3D DCCs such as Blender, Maya, etc.

As such, I believe if we are aiming for animation reuse, we are making a mistake assuming that a 3D scene should import single animations to AnimationPlayer (and AnimationTree). Instead, animations should first be imported to an AnimationLibrary, and then this library set into the respective players.

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

This proposal mainly covers some changes to how animation importing and playback happens in Godot:

• A new resource AnimationLibrary will be added. It contains Animation resources.
• AnimationPlayer should still allow for registering separate animations for simplicity (specially 2D usage), but it should also allow for adding multiple AnimationLibrary resources to source them.
• AnimationTree should still allow for pointing to an AnimationPlayer, since it needs it as root node from where animations are played, but it should also allow loading animations from an AnimationLibrary directly. The mode of operation should be something users can choose.
• The Scene importer (what imports DAE,GLTF,FBX) should be modified to also allow importing scenes as an AnimationLibrary. This final bit will allow full animaiton reuse, because AnimationLibrary resources can be added to either AnimationPlayer or AnimationTree.

On a side note, we should also consider implementing this proposal. This would allow better animation reuse, by allowing nodepaths to animations to refer skeletons directly by having a @skeleton path.

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

N/A

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

N/A

[PLyczkowski]

For me the most important aspect of the design would be the ability to transfer (import or update existing) single animations between a 3d app and Godot, without the need to transfer all of the model's animations each time.

Use case: a player character model could have hundreds of animations, and the transfer process can include the baking of animations from a control rig to a game rig in the 3d app, or just exporting DAE,GLTF,FBX with hundreds of animations can be slow, making the process of updating the animation in the 3d app to seeing it in-game slow as well.

[reduz]

@PLyczkowski It sounds like this is something that would need to be figured out on the 3D app side. Still, with this at least you could divide them into groups (like walk, run, attack), work them out in separate files and export them separately.

[SilencedPerson]

Oh, wouldn't this allow for doing composite animations? ie dishonored style executions?

[TokageItLab]

@reduz I agree that the animation files make it possible to handle it as a stand-alone file. However, I do not quite understand what the AnimationLibrary is all about. At least with the current Godot, it is possible to handle animations separately as .tres.

In a previous discussion with you, you said that an animation must always have a set of skeletons from which the animation is created, does the AnimationLibrary always have skeletons? I disagree with that since Humanoid animations in Unity and VMD in MMD (3D motion software) are supposed to handle pure animation and mapping only, almost independent of the original Skeleton.

I expect/need the following things from an AnimationLibrary:

• Not necessarily have the original Skeleton
• Possible to play it immediately in AnimationPlayer and possible to blend in AnimationTree
• TrackPath can use proxy bone name for retargeting
• Pre-multiply according to the retargeting (playback) mode and have the markings for each track (Context: Implement SkeletonRetarget and overhaul some animation features godot#56902 (comment))

[nonfatmatt]

As someone who has recently worked with animation in Godot 4, this is needed. There is currently an arcane process of pushing all available animation tracks from Blender into the NLA editor in proper order, hoping your tracks are stowed correctly, then exporting to glTF file in the hope that it will all work correctly on the other side. Blender's animation data system (data blocks and fake users, etc) adds a level of complexity and obfuscation to this as well, meaning sometimes you will get animations that are overlapping and on the wrong tracks. It's a mess, and adds time to an already arduous process. Then, you have other DCC tools like Maya that have a variety of proprietary solutions (bone weighting, etc) that never import correctly in .FBX format.

Having spent 20-30 hours importing various animations from other places and trying to make them Godot compatible, I can suggest some things:

1. Make .glb / .gltf the only standard for importing animations, at least in the beginning. No .dae, no .fbx, no .blend. This forces compliance to a standard and by default strips out a number of proprietary solutions that cause inconsistencies when animation data is exported to Godot.

2. Decouple animation data from mesh data (I am not sure if this is already implemented with the retargetting / animation systems that are planned for Godot 4, I haven't looked recently). By default, animation should look something like this:

Character <----- Skeleton <---- AnimationLibrary<--- Multiple or Individual animation tracks from different files. So, I can have multiple animation libraries for different characters built on the same skeleton.

An example of a workflow would be something like this: https://nilooy.github.io/character-animation-combiner/ - Importing a .glb or .fbx works regardless of how many animations are in the file, as long as bones / skinning are the same. Also, granular control for importing / tweaking one animation would be helpful. I know it's planned for Godot to be able to animate within the editor, but most of us still use DCC tools.

[TokageItLab]

@nonfatmatt

Decouple animation data from mesh data

I agree vehemently. And that is one of the things we have been experimenting with lately, and we already know that it is possible by recording as animation the pre-calculated values using the bone rests of the model.

[reduz]

@TokageItLab

I agree that the animation files make it possible to handle it as a stand-alone file. However, I do not quite understand what the AnimationLibrary is all about. At least with the current Godot, it is possible to handle animations separately as .tres.

The problem is two fold:

• Trying to avoid workflows when the engine imports a single file as multiple ones. This is always a mess. Currently you can make Godot import the model and also separate animation files (although this is quite hacky).
• Importing animations without importing the model. This is required for more sane game development workflows, specially when you have somebody working on models and somebody working on animations (and they are saved to different files).

In practice, there is not much of a point in managing imported animations as single files, and there are not really popular file formats that one can import standalone animations.

[reduz]

@nonfatmatt

There are two levels in which we are trying to make this happen:

• Reuse animations across multiple models that share the same skeleton: This is not possible right now because animations are always imported with the model. This is what this proposal aims to change and should solve what you want to do.
• Reuse animations across multiple models with different skeletons: That is what retargeting is about, we are discussing a lot with @TokageItLab how to implement this properly in Godot and I will do a follow up proposal to this one covering that.

[TokisanGames]

When I get animations from mixamo, or extracted from another engine's asset store, I usually get the mesh and multiple LODs in one FBX file, and all of the animations in many separate FBX files. These are quite common.

What I currently do is:

• In blender, import the mesh FBX, adjust the lod tree structure, import all the animated armature FBX files, delete the extra armatures (animations remain), rename the animations, make NLA tracks with PushDownAll, export as glb
• In Godot, import glb w/ animations as separate files, then setup my lod manager, materials, scripts, collision, and other nodes for the character scene.

We have to go through much of this process every time we make a new iteration of models, and take careful steps to avoid broken animations in Godot due to its inflexibility. It's time consuming. Our player model has over 200 animations right now.

Anything to make this process smoother would be great. I'd like to be able to directly import a single or many animated armature FBX files without mesh data and apply them to a model that has already been imported and set up, without requiring importing the whole package again.

E.g. I have an animated character already set up, then I download 10 more animations from mixamo with the same rig, and just add them in Godot without a hassle.

Or I bring in an FBX dump from an asset kit I bought, which contains a model and 30 animations as separate FBX files. And they are easily combined together. In blender its done automatically on load for the same rig. One the animation data is loaded, you can click your rig, then any animation and play it.

[nonfatmatt]

@reduz Personally I think you should work on reusing animations on similar/same skeleton models before you work on a complete retargeting solution. There are many available (and sometimes free) tools that can do retargeting . It would be nice to be able to automatically retarget like UE4, but from a workflow perspective (and code complexity / corner case management perspective, I would think) the former is much more valuable at the moment.

@tinmanjuggernaut This is exactly what I was doing in my use case scenario, PushDownAll was a godsend (This is a Blender problem, not a Godot problem). The ability to import multiple one-take files is probably the most valuable workflow related development.