Your Blender rig deforms, shrinks, or pulls away from its mesh the moment it lands in Unity, Godot, or Unreal Engine 5, even though everything looked correct in Blender's viewport. The cause is almost always one of three things: unapplied object-level scale on the armature, inconsistent bone roll axes, or non-uniform scale baked onto individual bones. Blender's viewport quietly compensates for all three. The glTF/GLB exporter does not; it writes the raw transform values, and every engine reads them literally. Fix the transform before you export and the rig imports clean, every time.
Why Blender's armature scale breaks
Blender lets you move, rotate, and scale an object without touching its underlying mesh or bone data. The numbers live in the object's transform channels, and the viewport draws the compensated result. glTF doesn't work that way. The glTF-Blender-IO exporter, the kind of scaling bug tracked as issue 828 on the KhronosGroup GitHub, bakes whatever sits in those transform channels straight into the node hierarchy, because glTF nodes store scale as a literal per-node value, not a Blender-style display adjustment.
So if your armature object still shows a scale of `0.01` in the N-panel, common after importing CAD or photogrammetry reference at real-world centimeter scale and then modeling your character over it, that `0.01` travels into the GLB file on the armature node. Unity, Godot, and Unreal Engine 5 all apply it literally on import. The mesh, which usually does have its scale applied already, stays the size you expect. The skeleton doesn't. You end up with a normal-sized character and a skeleton that's either invisible, scaled down to a fraction of a millimeter, or enormous.
Fix the transform before exporting
In Object Mode, select the armature and every mesh parented to it, then run `Object > Apply > All Transforms` (`Ctrl+A` then `All Transforms`). This zeroes out location, rotation, and scale on the objects while keeping their visual position identical. The values that were compensating in the viewport get baked into the mesh and bone data instead, which is exactly where glTF expects them to live.
Two things trip people up here. Rigify control rigs need this applied to the generated rig, the object literally named `rig`, not the `metarig`, and it needs to happen before you pose or animate it. Applying transforms after animating can shift keyframes on bone chains that use inherited scale. If you've already animated, apply the transform, then re-check the first few frames of every animation before you re-export.
The other trap: Blender refuses to apply scale on a mesh that has shape keys, and throws an error instead of applying. Duplicate the mesh without shape keys, apply scale on the duplicate, then copy the resulting transform values onto the original, or bake the shape keys into a single mesh first if you don't need them as separate targets after export.
Bone roll and rest pose, the other two culprits
Scale isn't the only transform that Blender compensates for in the viewport and breaks on export.
Bone roll. Enter Edit Mode on the armature, select every bone (`A`), then run `Armature > Roll > Recalculate Roll` and pick a consistent axis, `Global +Z Axis` covers most humanoid rigs built standing upright. Inconsistent roll between bones is invisible in Blender's viewport, but it shows up immediately as twisted or sheared deformation once an engine's animation system evaluates the same bone against its own local axis convention.
Rest pose. If you posed the rig to check a silhouette or grab a screenshot and forgot to return it to rest, run `Pose Mode > Pose > Apply > Apply Pose as Rest Pose` before export. Otherwise the exported bind pose is whatever pose the rig happened to be sitting in, and every animation you play back in-engine deforms starting from the wrong pose.
Non-uniform scale on individual bones, a stylized limb scaled up on one axis only, is a separate problem with no clean one-click fix. glTF's node transforms can represent it, but combined with rotation on a parent bone it can shear the mesh in ways that read correctly in Blender's pose-space evaluation and wrong in an engine's. Where possible, build that shape into the mesh instead, with sculpting, a shrinkwrap modifier, or shape keys, rather than pushing it through bone scale.
What each engine shows you when it's still wrong
The specific failure tells you which of the three problems you're looking at.
| Engine | What you'll see | Usual cause |
|---|---|---|
| Unity | Model imports at the wrong overall size, or the Scale Factor field in the model inspector shows an odd decimal like 0.01 | Unapplied object-level scale on the armature |
| Godot | `Skeleton3D` imports fine, but the mesh detaches, twists, or wobbles away from the bones once it animates | Inconsistent bone roll axis, or non-uniform bone scale |
| Unreal Engine 5 | Skeletal mesh looks right, but the separate Skeleton asset's bone gizmos are microscopic or huge next to the mesh | Same root-scale mismatch, more visible here because UE5 imports mesh and skeleton as separate assets |
To batch this across a folder of old rigs instead of fixing them one at a time in the UI, Blender's Python console handles it in a few lines:
```python
import bpy
for obj in bpy.context.selected_objects:
bpy.context.view_layer.objects.active = obj
bpy.ops.object.transform_apply(location=True, rotation=True, scale=True)
```
Select every armature and mesh you want fixed first, then run it. It applies transforms across the whole selection in one pass instead of clicking through each rig individually.
Check it against a rig you didn't build
The fastest way to confirm the export settings are the problem and not your specific rig is to export something you know is already clean and compare. A catalog character like Wasteland Mercenary ships with transforms already applied, so if it imports correctly and your own rig doesn't, the problem is confirmed to be sitting in your file rather than your Unity, Godot, or UE5 import settings. BitSoul's Blender, Unity, Godot, and UE5 plugins pull catalog models in with this already handled, so this specific bug only shows up on rigs you've built or modified yourself. A free account's two monthly downloads cover evaluation; commercial use is included with paid memberships (pricing).
For export settings beyond the armature itself, Draco compression, material export, and UV handling, Blender 5's glTF export settings for game-ready GLB covers the rest of the export dialog. If the problem is specifically animation playback rather than the bind pose, why root motion rotates on the wrong axis in Godot 4.5 is the more targeted fix. And if Unity is where the broken scale is showing up, Unity 6's GLB import bugs with pink materials, scale, and normals covers the import-side settings that compound the same problem.
None of this means Blender is broken. Two systems, Blender's compensated viewport transforms and glTF's literal node transforms, disagree about what the stored numbers mean. Apply transforms before export, keep bone roll consistent, and the disagreement goes away.
---
*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.*