Godot's glTF import silently renames bones and breaks animations

Import a single-animation glTF into Godot, enable Save to File on the animation, and the resulting .tres points at bones that don't exist. A track that should read Skeleton3D:Door comes out as Skeleton3D:Door_2, Godot invented a bone that was never in the file, and your AnimationPlayer silently fails to find it. This is a confirmed Godot bug, not a Blender export mistake — it reproduces on both 4.5.1 and 4.6 stable, nobody has a patch scheduled, and the fix is something you apply yourself today.

Why Godot's glTF import renames your bones

Godot's scene tree auto-renames any node that collides with an existing sibling, appending _2, _3, and so on to keep names unique. The glTF importer's "save this animation as its own resource" path builds an internal scene graph to resolve each track's node path, and that process collides with itself — even with one armature, one animation, and zero naming conflicts anywhere in the source file. Whatever collision it thinks it found gets baked into the .tres permanently: every bone in every track carries the phantom suffix, while the real Skeleton3D sitting in your actual scene keeps its clean, correct names.

It's filed as issue #115792 on the godotengine/godot repository, labeled bug, topic:animation, and topic:import, sitting in the Asset Pipeline Issue Triage project with no milestone attached. It reproduces on commit f62fdbd (4.5.1 stable) and 89cea14 (4.6 stable) — the bug crossed a full minor version bump without anyone touching it.

Reproduce it in under a minute

Export a rig from Blender with exactly one action baked into its own glTF file — no other animations in the file, no naming collisions to speak of. In Godot's FileSystem dock, double-click the .glb to open the Import tab, then click Advanced Import Settings. Select the animation under the Animation category, enable Save to File, point it at a .tres path, and hit Reimport. Open the saved .tres in any text editor and compare the tracks/0/path line — something like NodePath("Skeleton3D:Door_2") — against the bone names actually present in your Skeleton3D. If that suffix doesn't exist on the real skeleton, every track built the same way in that file has the identical problem.

The one-line fix for files you've already exported

.tres is plain text, so patching a handful of already-broken files doesn't need the Godot editor open at all.

# strips the bogus _2 suffix from every bone track in one .tres
sed -i 's/_2"/"/g; s/_2:/:/g' animations/door_open.tres

This fixes that one file. It does not survive the next reimport — Godot regenerates the .tres from the glTF source and reintroduces the same suffix, which is the part that catches teams re-exporting from Blender every time an animator tweaks a pose.

The fix that survives reimports

For a pipeline where animations get re-exported repeatedly, hand-editing .tres files after every reimport isn't a workflow, it's a chore that eventually gets skipped. Attach a post-import script instead: in Advanced Import Settings, set the Script field to a script extending EditorScenePostImport, and correct the paths before Godot ever writes the file.

extends EditorScenePostImport
func _post_import(scene: Node) -> Object:
    for player in scene.find_children("", "AnimationPlayer", true, false):
        for lib_name in player.get_animation_library_list():
            var lib := player.get_animation_library(lib_name)
            for anim_name in lib.get_animation_list():
                var anim := lib.get_animation(anim_name)
                for i in anim.get_track_count():
                    var np := anim.track_get_path(i)
                    var bone := np.get_concatenated_subnames()
                    if bone.ends_with("_2"):
                        anim.track_set_path(i, NodePath(str(np.get_concatenated_names()) + ":" + bone.trim_suffix("_2")))
    return scene

Assign it once per import preset and every future reimport comes out clean, whether it's an animator re-exporting by hand or a CI job pulling fresh .blend files on every commit.

Test it on a rig with more than one bone

A single "Door" bone is easy to eyeball; a character skeleton with thirty-plus bones is where the phantom suffix actually costs time, since some tracks land on real names by coincidence while others quietly no-op. Elven Ranger ships with a full humanoid skeleton and works as a stand-in for this test — export one action for it, reimport with Save to File on, and diff the track paths before deciding whether the post-import script is worth setting up. A free account's two monthly downloads cover evaluation; commercial use is included with paid memberships (pricing).

Which fix fits your pipeline

Gotchas

Godot doesn't throw an error when a track path fails to resolve — it logs a quiet warning to the output panel and keeps running, so a broken bone track ships to players as "that door just doesn't open," with nothing in the crash logs pointing at why. The bug only triggers on the Save to File path specifically; animations left embedded in the imported scene, which is the default when you skip that toggle, don't show the phantom suffix at all, so if you don't need the animation as a standalone resource, not saving it to file sidesteps the entire issue. And because the suffix gets rebaked on every reimport, a file you fixed by hand looks correct right up until someone touches the source .blend again and the pipeline runs — which is why the sed fix is fine once and the post-import script is the only real answer past two or three reimports.

Two related Godot import bugs worth knowing if you're building rigged characters: Godot's GLTF importer flattening normal maps and the red X on GLB imports after a clean checkout both hit the same import pipeline from different angles, and glTF's 4-bone weight limit is the other common way a rig comes in looking wrong.

This post is part of the Ultimate Guide to Free 3D Game Assets — BitSoul's complete reference for formats, texturing, rigging, optimization, and engine integration.