Units & Axes - The Cross-App Conversion Matrix

Units And Axes By Application

Application	Native unit	Up	Forward (convention)	Handedness
Blender	metres	Z+	-Y (front faces -Y)	Right
Maya	centimetres	Y+	Z+	Right
Houdini	metres	Y+	Z-	Right
3ds Max	inches (configurable)	Z+	Y-	Right
Unreal Engine	centimetres	Z+	X+	Left
Unity	metres	Y+	Z+	Left
Godot	metres	Y+	-Z	Right
glTF (format)	metres	Y+	Z+	Right

Read it and the whole genre of import bug explains itself: Blender->Unreal must convert metres->centimetres and re-aim forward and flip handedness; Maya->Unity only has to survive the cm->m scale. FBX carries metadata for all of this, which each importer honours slightly differently - hence the rule: fix conventions in saved export presets, never in the scene, never per-asset by hand.

Common Pairings, Fixed Once

Route	The failure you'll see	The fix that sticks
Blender -> Unreal	100x too small, or an unexpected -90 deg X rotation	Exporter: Apply Scale = FBX All, Bake Space Transform = on. Full walkthrough in Blender for Game Artists
Blender -> Unity	Scale 100 on the import, or rotated -90 deg X	Same preset as UE; Unity side: model importer "Use File Scale" on, or export glTF - Unity's glTF path skips most of the dance
Maya -> Unreal	Mostly painless (both cm, both Z-up-adjacent)	The easy route - main check: working units actually set to cm, world-forward agreed with the team
Maya -> Unity	Everything 100x too big	cm->m: let Unity's "Convert Units" do it (default on) - don't also scale in Maya, the classic double-conversion
Houdini -> engine	Fine to Unity, Y-up->Z-up confusion to UE	Houdini's UE tooling/HDA path handles it; for raw FBX, set the export's up-axis to match target
Anything -> anything, characters	Root bone rotated, animation twists	Axis mismatches can also affect bones and animation - agree on ONE authoring orientation for rigs, validate at export (a pipeline script job)

Handedness In One Minute

Point your right hand's fingers along +X and curl towards +Y: thumb points +Z - that's right-handed, most DCCs. Unreal and Unity's +Z (or +Y) comes out the other way: left-handed. Practical consequences, beyond "the importer deals with it": cross products flip (why hand-computed normals sometimes invert crossing apps - see the maths sheet), rotation signs flip (a +30 deg yaw in Blender may be -30 deg in-engine), and winding order flips - which is why a mesh mirrored with scale -1 shows inside-out in engine: its triangles now wind backwards and get culled. If you remember one thing: negative scale isn't a mirror tool for game assets. Mirror the geometry, apply it, recalculate normals.

Diagnosing A Broken Import In 60 Seconds

Wrong size? Units. 100x = m<->cm (Blender/UE), 2.54x = inches somewhere (hello Max). Fix the export preset's scale handling.
Lying down / standing wrong? Up-axis. A -90 deg or +90 deg X rotation on import = Z-up <-> Y-up disagreement. Fix in exporter axis settings, not by rotating the mesh.
Standing but facing sideways/backwards? Forward convention. Rotate the authoring orientation to your team's agreed front (Blender: front = -Y), re-export.
Inside-out? Winding/negative scale. Find the -1 scale, apply it properly, recalc normals.
Once you’ve fixed a representative asset, update the shared preset and test another. Record any exceptions so nobody has to guess why an import rotation is there.

A practical example

A batch of props can look correct with an import rotation of X=-90, then rotate incorrectly when someone resets a transform. A shared export preset and a validator make that assumption visible. Check the intended orientation with the team before rejecting or re-exporting a batch.