Importing as Animation Library still uses deprecated NodePaths in animations

[josefkaragoli]

Godot version

5636903

System information

Windows 10

Issue description

In animation tracks, as of #59980 NodePaths are now not hierarchical - for example, NodePath("RootNode/root/pelvis") is now just NodePath(".:pelvis") or NodePath("RootNode/Skeleton3D:pelvis").

When importing an external file as Animation Library, such as DAE, FBX, or GLTF, the animation data contained within them still uses the old NodePath NodePath("bone1/bone2"), so importing and loading animation libraries does not work.

How imported animations look:

How they SHOULD look:

This affects mostly skeletal animations - regular animated nodes can still be animated with the node path, however individual bones can't be animated.

The solution should be to always use the .: syntax when dealing with animations, as its more modular and significantly easier to work with.

Steps to reproduce

Import an FBX as an Animation Library. Re-save the animation library as a .tres. Open the tres in notepad or any ASCII viewer. You will see node paths that follow the old convention of specifying exactly where in the node tree is being animated. On the other hand, animations made within godot by using the key icon use a different syntax.

Minimal reproduction project

I don't have any rigged characters that aren't copyrighted. Sorry.

[and-rad]

I looked into this and there are a couple of things at play here.

First some clarifications: The FBX import pipeline was changed (#59653) in March and now looks like this: The FBX file is converted by the FBX2glTF tool and the resulting GLTF file is what actually gets imported. From Godot's perspective this is a GLTF issue, not an FBX one. I didn't check for Collada files. Also, the FBX2glTF tool is not bundled with Godot, so users need to provide their own. This means different users might use different versions of the tool.

The issue with the path names does not actually seem to be related to #59980. When Godot's GLTF importer detects a skeleton in the GLTF file, a nodepath is created for every animation track. It stores the path to the skeleton as its main path and the name of the bone as its subpath. This leads to the correct "path/to/skeleton:bone" path name. If no skeleton is found in the file, it doesn't store anything in the subpath. It has been like that for 18 months at least, as far as I checked.

Here is where it gets tricky: How does Godot determine if a skeleton exists in the GLTF file? There is no such thing as a "skeleton" node in the GLTF schema. Without going into too much detail (read this for a discussion: KhronosGroup/glTF-Blender-IO#822), it does so by checking whether the file contains information about skinned joints. If the "skins" array exists, Godot can build a skeleton hierarchy. If not, then it simply has no information about how to do that.

How does the information about skinned joints end up in the GLTF file? The exporters / converters put it there. Which brings us to the next complication. Different exporters may create files with different content that may or may not be missing crucial information. Using Blender and the bundled GLTF exporter, this is what will happen:

1. Blender 3.1: I export an armature, a skinned mesh and some animations. The GLTF file contains all the information about how to build a skeleton, so there is no issue in Godot and I can import the file as a scene or an animation library and everything works.
2. Blender 3.1: I export an armature, and some animations, but no mesh. The GLTF file contains the skeleton nodes and the animations, but no skinning information. You can import the file as an animation library, but the paths will be all wrong because Godot was not able to create a skeleton.
3. Blender 3.2: I export an armature, and some animations, but no mesh. The GLTF file contains the skeleton nodes, the animations and the skinning information. Because the exporter was updated to do exactly that even when there is no mesh. Godot happily imports this file as an animation library and all animations can be used on other characters as long as the bone hierarchy is the same.

So you see, whether or not files can be imported as animation libraries depends on the specific exporter / converter used to create the file, sometimes down to the release version. The FBX2glTF tool simply doesn't create a suitable GLTF file if there is no skinned mesh in the FBX file. This is an issue that should be filed there.

My suggestions on how to make all this easier:

• Content creators should use the latest versions of Blender and export to GLTF binary. This seems to be the most reliable workflow currently.
• If something breaks, see if it's a problem with the exporter / converter first
• If you have to use FBX, for now, attach a small skinned mesh to the skeleton before exporting. It adds bloat to the file, but at least you'll keep it to a minimum.
• Godot developers should probably think about shipping the FXB2glTF tool with the engine or at the very least provide an "official" version on the website. I can only imagine the confusion when users use all kinds of outdated versions of that tool in their pipelines.

All in all, to me it seems that the specific problem reported in this issue is not something that can be fixed on Godot's end.

[Calinou]

Godot developers should probably think about shipping the FXB2glTF tool with the engine or at the very least provide an "official" version on the website.

This is not possible for legal reasons. fbx2gltf depends on a proprietary library (the Autodesk SDK). Since Godot is under the umbrella of the Software Freedom Conservancy, we can't bundle Godot with proprietary software. We can add a page on the website that points to the correct version of fbx2gltf to use, but that's all we can do.

(That said, nothing prevents someone from creating a script or add-on that installs fbx2gltf for you, or even create a Scoop manifest that installs fbx2gltf.)

I can only imagine the confusion when users use all kinds of outdated versions of that tool in their pipelines.

We can modify the V-Sekai fbx2gltf fork (the only one that works with the Godot integration) to report a different version number, and add version detection to the Godot editor by running a --version command line argument with OS.execute() when the path to the fbx2gltf binary is changed in the Editor Settings.

Vanilla fbx2gltf isn't maintained anymore, and it's not supported by Godot's integration since it lacks critical features and fixes.

[and-rad]

This is not possible for legal reasons. fbx2gltf depends on a proprietary library (the Autodesk SDK)

My bad, I didn't know they used the official Autodesk SDK. The GitHub page says that FBX2glTF was released under BSD. That's out of the question then, of course.

We can modify the V-Sekai fbx2gltf fork (the only one that works with the Godot integration) to report a different version number, and add version detection to the Godot editor

The version reporting would probably do the trick. I don't even know how many devs depend on FBX for their Godot pipeline.

[Calinou]

The GitHub page says that FBX2glTF was released under BSD.

fbx2gltf itself is open source, but it depends on the proprietary Autodesk SDK. Therefore, fbx2gltf is "tainted" open source software so to speak.

[lyuma]

Filed an issue on V-Sekai/FBX2glTF here: https://github.com/V-Sekai/FBX2glTF/issues/19

[TokisanGames]

I don't see this occurring in Alpha14. Deleted animation player, added again, loaded Dorian_V7_A9.glb as an AnimationLibrary and the animation tracks look as they should:

Here's the path on a text converted animation library:

[gd_resource type="AnimationLibrary" load_steps=257 format=3 uid="uid://u61cga8ojeyd"]

[sub_resource type="Animation" id="Animation_5etlj"]
resource_name = "0_T-Pose001"
length = 0.001
tracks/0/type = "blend_shape"
tracks/0/imported = false
tracks/0/enabled = true
tracks/0/path = NodePath("Armature/Skeleton3D/cc_base_body:Open")

I also did a search and replace and stripped out Armature/Skeleton3D/ and that library also loaded fine and looks the same as the picture above.

[lyghtkruz]

This appears to still be happening for me on Beta 17. Steps to reproduce:

1. Drag FBX with animations into Empty scene
2. Right click FBX scene and Make Local
3. Click Animation Player (Animation tracks are labeled as "GeneralSkeleton")
4. Click Animation -> Manage Animations
5. Click Save Icon -> Make Unique (required because these are foreign and not built-in)
6. Click Save Icon -> Save As
7. Name Library
8. Go to another character, Click Animation -> Manage Animations
9. Load Library (Select the saved library and the name changed from "GeneralSkeleton" to "Something/GeneralSkeleton")

The path in the animation player is changed to "Armature/GeneralSkeleton."

Once I discovered that the track name was being changed with the parent node name included, I tried various things to fix it. Like in the following picture, I have changed the name of the node from Armature to Character

It worked the first time and this is the result using the exact same steps from above.

The first and third images above are from the same imported FBX. The one that doesn't have Armature in the track name works properly on my other models for animation retargetting. The one with Armature doesn't work on my other models. I tried renaming other FBX models and I get Character/GeneralSkeleton. I also tried this again on the model that worked and I had the exact same problem where the animation track was renamed, so I don't know why it worked properly the first time.

[lyghtkruz]

This appears to work properly in rc1. I ended up clearing the bonemap and recreating it and it's currently saving the library properly and I can load it onto new models.

[TokageItLab]

Can we close this? @fire @lyuma

[lyuma]

@lyghtkruz GeneralSkeleton now uses "Access as Unique Name" (% icon in the Scene panel) to permit access from animation libraries as "%GeneralSkeleton". It should not be necessary to rename tracks with GeneralSkeleton. Happy to see this issue was resolved.

• The old FBX importer has been replaced with FBX2glTF, which should resolve the issue from @josefkaragoli
• Blender as of version 3.2 has patched the export process to permit Animation export from armatures with unused glTF skin objects: See Export Armature and Animations Only - Exclude Mesh KhronosGroup/glTF-Blender-IO#822
• That leaves the last issue of mesh-less FBX files. These still import as node-trees. This is tracked at FbxSkeleton should create empty skins with all of the bones. FBX2glTF#19 - these files can be frequently found on Mixamo, so it is worth solving. For now, going via Blender should import them correctly.

Given this, I will close this issue. If you have another issue related to animation library import (that isn't related to the above open FBX2glTF issue), please start a new issue so it doesn't get mixed up with previous resolved issues.

(Side note: It's good to always use the latest Blender when working with .gltf or .blend import in Godot. Blender 3.4 also contains critical glTF bugfixes, and there are more major improvements to glTF scheduled for far as Blender 3.6, so keep Blender up-to-date.)

[lyuma]

See also: #70538 for the godot side of that FBX2glTF issue with armature-only fbx animations.