Blender to Unity: scale, axes, materials

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, and the exports of the catalogue pieces already leave with these settings.

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. 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. Two moves settle it: reorder the channels to suit your pipeline (URP and HDRP do not want the same order) and invert roughness once, since Unity thinks in smoothness. A channel-separation node in Blender, or any image editor, will do.

The exact order each engine expects, and the colour-space trap that skews roughness across the whole piece, are in the note on ORM: repeating them here would leave two pages arguing over the same question.

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.