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.

[TokisanGames]

Retargeting across different rigs has been super unreliable in every software tool I've tried, except for UE4. It's nice to have in Godot, but only if it works reliably and universally. I wouldn't hold up 4.0 for it.

If you are going to spend any time on it, I would study the UE4 workflow (eg cc3->ue4) and only do it if it will support any skeleton to any skeleton, plus universal and individual bone transformation options for troubleshooting and a debugging tool.

I get animations from Mixamo, UE market place, Unity market place, Character Creator 3 Actor Core, sketchfab, or custom made in Blender or Maya by me or my team. They all come on different rigs. It is acceptable to me to dump it all in UE4 and retarget there as they have the most robust, battle tested tool.

Retargeting aside, this proposal is definitely needed. I'm hoping to add real world context. In summary that is the ability to import, (re)connect, modify, and export animations on the same rig easily:

I should be able to remove Blender entirely from my workflow above. Meaning I can import either:

• a single FBX or GLB with a mesh and multiple animations
• multiple separate files with only mesh/skeleton or only armature animations
• multiple files with both mesh and animations (eg redundant meshes, which is an option in mixamo)

and then combine into one model, and move the animations all around in Godot like I can with meshes once they're imported. No matter how I get the animations and meshes into Godot, I can mix and match and move around, edit, duplicate, reconnect to other rigs and other meshes, import additional animations or meshes later, and gltf export, as long as it all has an identical rig.

[justinbarrett]

This is something that has bugged me a lot..and slows down my workflow considerably... When you end up with a complex node setup for your player and realize you've forgotten an animation, or one is corrupted...you need to re-import and do the setup all over...even worse if you set variables in the individual animations.

[JoanPotatoes2021]

This is interesting, I already worked a hackish solution to have separate mesh from animation data, it works, by exporting the rig with all animations as one gltf, and the assets without any animation as another gltf, but with the same rig and later save then as a separate mesh file .res

My problem was how to work with separate character parts to a single rig in godot, while allowing each part to be changed at runtime.

From blender I exported the rig with a basemesh as gltf with all the animation data, later I skimped the import of the mesh, keeping only the skeleton with all animation data,

The character assets I exported as another gltf with no animation data, only the skeleton, skinning and the assets mesh, then on godot I splitted the mesh from the assets to .res files,

Later it was a matter of simplying assign the skeleton to the mesh in Godot inspector, I had now assets without animation data following a common rig,

[dpalais]

This sounds like a welcome improvement. I've been using a EditorScenePostImport script to convert an imported GLTF file into a single node AnimationPlayer scene to use as a reusable animation pool. The script is also key and important to be able to rename the tracks paths to remove the old scene paths and point directly to the Skeleton node or parent.

[akien-mga]

Implemented by godotengine/godot#59980.

[reduz]

Not fully implemented yet!

[shuvit-game]

A very small thing that just might not be implemented yet: it is pretty important imo to be able to select multiple animations to import into a library. Currently only 1 can be selected at a time.

---

edit: sorry missed discussion elsewhere.

[GeorgeS2019]

@tinmanjuggernaut what are the challenges of exporting CC3 or CC4 and then importing into godot?

[TokisanGames]

@GeorgeS2019 Going from cc3->blender->Godot is fine with pushdownall and gltf, and other notes from my process above.

[GeorgeS2019]

@tinmanjuggernaut Just joined your discord. Do you have plan for blendshape facial animation in your game. I just PM u in your discord

[jgillich]

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

Was this part implemented? I can't find it. The ergonomics of using AnimationLibrary with AnimationTree are not great without this, I basically have to create a fake AnimationPlayer as a workaround

[GeorgeS2019]

https://www.youtube.com/watch?v=NBukd3NmK88