Import an animated GLB into Godot 4.5, hook it into an AnimationTree with root motion enabled, and the character's root motion rotates on the wrong axis — Z instead of Y — or the whole rig spins to face backward the instant it starts moving. That's not a regression in 4.5. Root motion reads rotation directly off the root bone in the imported skeleton's own bone space, and if that skeleton was never retargeted to a SkeletonProfile, its bone space doesn't line up with Godot's forward convention. The fix is a Bone Map, not a script patch, and it takes about five minutes once you know where to look.
Search Godot's GitHub issues for root motion and at least five separate reports come up spanning three engine cycles — issue 77087 filed against 4.1.dev2 back in 2023, then 58061, 95380, 95688, and 93821 across 4.3 through 4.5. A Godot Forum thread from January 2026 describes the exact 4.5.1 symptom: rotation lands on Z instead of Y. The oldest issue was closed as "not planned," because from the engine's side nothing is broken — the skeleton was just never told which axis is which.
Why root motion lands on the wrong axis
AnimationMixer, the base class behind both AnimationPlayer and AnimationTree, pulls root motion straight from whichever bone is set as the root bone on import, in that bone's local space. A freshly imported .glb has never been mapped to a common skeleton layout, so Godot has no way to know that bone's "forward" should map to its own Y-up, -Z-forward convention. Blender exports forward as -Y by default, and without retargeting that mismatch rides straight through into the root motion vectors your AnimationTree hands back. It's the same axis confusion behind Blender to Godot 4: The Complete GLB Export and Import Pipeline — here it just shows up in animation instead of static mesh orientation.
Retarget the skeleton before you touch code
Retargeting maps a rig's actual bone names onto a common profile, so Godot can reason about which bone is the hip, which is the spine, and which one drives root motion. It's the same underlying fix that clears up the node renames covered in Godot 4.5 GLB reimport renames nodes and breaks materials — do it once per skeleton, not once per animation.
| Step | Where (exact UI) | What to set |
|---|---|---|
| 1 | FileSystem dock → right-click the `.glb` → reopen with Advanced Import Settings | Select the Skeleton3D node in the left-hand scene tree |
| 2 | Inspector → Retarget category | Assign a new BoneMap resource to the Bone Map property |
| 3 | BoneMap resource → Profile property | Load SkeletonProfileHumanoid, or a matching custom SkeletonProfile |
| 4 | Bottom BoneMap panel, the colored skeleton diagram | Manually confirm every auto-mapped bone, especially Hips |
| 5 | AnimationTree inspector → Root Motion Track | Point it at the retargeted Hips path, not the old scene-root path |
| 6 | Add a RootMotionView node → Animation Path | Point it at the AnimationTree and confirm the arrow points along +Y forward, not sideways |
Step 4 is where most retargets still fail silently: the auto-mapper frequently skips Hips on imported rigs because of prefixed bone names, and a skipped Hips mapping is exactly what produces the Z-instead-of-Y symptom on its own.
Character Dwarven Berserker is a good stress test for this setup — a heavy, momentum-driven rig where a wrong-axis spin is obvious within one animation cycle instead of buried in subtle drift. A free account's two monthly downloads cover evaluation; commercial use is included with paid memberships, see pricing.
Apply root motion correctly in code
Retargeting fixes the axis. It won't fix a physics function that applies rotation and position in the wrong order. Rotate first, then use the updated orientation to project the position delta — reversing that order reintroduces the same sideways drift retargeting just solved:
```gdscript
func _physics_process(delta: float) -> void:
var rot: Quaternion = anim_tree.get_root_motion_rotation()
var pos: Vector3 = anim_tree.get_root_motion_position()
quaternion = quaternion * rot # local rotation applied first
velocity = quaternion * pos / delta
move_and_slide()
```
`get_root_motion_rotation()` and `get_root_motion_position()` live on AnimationMixer, so this works whether `anim_tree` is a full AnimationTree or a plain AnimationPlayer with a root motion track assigned directly.
Gotchas that still bite after retargeting
A Root Motion Track still pointing at the pre-retarget path is the most common leftover bug. It doesn't throw an error — it just silently stops driving motion, so the character idles in place while the animation keeps playing. Reopen the AnimationTree inspector after saving the BoneMap and confirm the path updated.
Mixamo-sourced rigs need a manual look at Hips specifically. The profile's auto-mapper frequently misses it because of the `mixamorig_` naming prefix, and that single skipped mapping is enough to reproduce the whole wrong-axis symptom on its own.
If the character still faces backward after retargeting and the Root Motion Track path checks out, the mismatch has moved from the bone to the mesh: Blender's default forward is -Y, Godot's is -Z, and that 90-degree gap has to be resolved in the armature's rest orientation before export, not patched per-animation after the fact. If the same GLB is also headed into a browser pipeline, animation import behaves differently again — see Load GLB files in Three.js: Draco, KTX2, and animations in 2026 for what changes.
---
*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.*