Blender to Unity: scale, axes, materials

3 min read

A character imported from Blender lands in Unity a hundred times too big, flat on its back, and grey. These are not three bugs. They are three conventions that do not line up, and each is settled at export rather than afterwards.

None of this is a fault in Blender or in Unity. Both made coherent choices, they differ, and FBX carries both without deciding between them. Export is where you decide.

1. The object arrives at 100× or 0.01×

Blender works in metres: one unit is one metre. So does Unity. The mismatch is not in the units but in FBX, which is conventionally expressed in centimetres — and the exporter applies a factor depending on how it reads that.

The setting: in the FBX export panel, Scale at 1.00 and Apply Scalings set to FBX All. On the Unity side, leave Scale Factor at 1 in the import inspector. If the object still arrives at 100×, the conversion is being applied twice — only one of the two should carry it.

The real trap sits upstream: an unapplied scale on the object. If your bust was resized in object mode, it carries a scale factor that FBX embeds as-is. Ctrl+A, then Rotation & Scale, before any export. That one step resolves more cases than any setting.

2. The object is lying on its back

Blender is Z-up: the vertical axis is Z. Unity is Y-up. A character standing in Blender therefore arrives rotated −90° on X — or, worse, standing upright with a −90° rotation baked into its Transform, which resurfaces the first time it is animated.

The setting: on export, Forward to -Z Forward, Up to Y Up, and Apply Transform ticked. The conversion is written into the mesh data, and the Transform arrives clean, at zero.

3. The character is grey

This is the least understood of the three, because there is nothing to repair: FBX does not carry Blender materials. It carries material names and, at best, texture paths. A Cycles or EEVEE node tree does not cross the boundary — there is nothing on the other side for it to become.

So the work is rewiring, not troubleshooting: make a URP Lit material, drop in base colour, normal, and the metallic/smoothness pair.

The ORM case, precisely

Flash textures are packed as ORM — occlusion in red, roughness in green, metallic in blue. That is the glTF convention, and it has its own note.

Unity does not read it as-is, and this is where most imports stop:

  • URP Lit expects metallic in red and SMOOTHNESS in alpha — smoothness being the inverse of roughness;
  • HDRP expects a mask map, in a different order again: metallic in red, occlusion in green, smoothness in alpha;
  • either way, the channels must be reordered and roughness inverted once.

A channel-separation node in Blender, or any image editor, is enough to produce the variant. The delivered .blend holds the original set, unflattened: that is what the source file is for, and it is what makes conversion possible instead of repainting.

GLB avoids all three

GLB embeds materials and textures, in the ORM convention, with glTF orientation. Loaded into Three.js or React Three Fiber, a character arrives at scale, upright and textured, with nothing to set.

Every piece in the catalogue ships with both, plus the source: FBX for Unity and Unreal, GLB for the web, .blend for whatever was not anticipated.

What leaves the studio

Exports are made with these settings, transforms applied, and opened in the engine named on the sheet before the piece goes on sale. Veilleur is checked in Unity 6 and Three.js; Suaire in Unity 6.

None of which removes the material rewiring: no FBX does that, and saying otherwise would cost half an hour to somebody who took us at our word.

Pieces mentioned

Read next

All notes