Blender For Game Artists

Units & Scale: The 100x Classic

Blender thinks in metres. Unreal thinks in centimetres. Unity thinks in metres but imports FBX at a 0.01 file scale it then compensates for. This is why the internet is full of assets arriving 100x too small, and why physics goes floaty when someone "fixes" it by scaling the mesh in-engine (the physics setup may still use the original scale).

Agree a real-world scale before building the export workflow. Model a reference object with known dimensions, export it, and measure it in the engine. Keep the Blender scene units, FBX options and engine import settings together in a documented preset; compensating for one setting elsewhere can hide a mismatch. Use the Units & Axes guide for the cross-app conventions, then test the route your team actually uses.

The Axis Problem, Explained Once

Blender is Z-up, -Y-forward. Unreal is Z-up, X-forward. Unity is Y-up, Z-forward. Every FBX carries axis metadata, and every importer interprets it slightly differently - which is how you get the fence that lies down in Unity or faces backwards in Unreal.

Two rules cover it: author facing -Y in Blender (character looks towards -Y; front of a prop towards -Y), and let the exporter do the conversion - tick Bake Space Transform (test this carefully with your asset type, particularly armatures and animation) so the rotation is baked into vertex data instead of arriving as a -90 deg rotation on the object. If your assets come in with X-rot -90 that "fixes itself" when you press zero - check this setting and test a re-export.

Pivots & Transforms: Where The Engine Grabs The Asset

The object's origin in Blender becomes the pivot in-engine - the point it rotates around, snaps by, and places at. Modular kit rules: props get the origin at the base-centre (sits on floors when dropped); modular wall/floor pieces get it at a corner, on the grid, so pieces snap like Lego; doors get it on the hinge. And before every export: Apply All Transforms (Ctrl+A) - an object carrying scale 0.37 exports as an object carrying scale 0.37, and someone downstream inherits the mystery.

Collections Are Your Export Pipeline

The habit that scales: one collection = one exported asset. Name the collection what the file should be called (SM_Crate_01), keep its parts inside, and batch-export collections to files (the cookbook has the script). Now "what's in the game" is answerable by reading the outliner, high-poly sources live in an excluded _source collection, and nobody exports the lighting rig by accident. This mirrors exactly how UE/Unity think about assets, so the mental model transfers.

Save And Share An Export Preset

FBX exporter setting	Value	Why
Limit to	Selected Objects / Active Collection	Never ship the whole scene
Object Types	Mesh (+ Armature for characters)	No cameras/lights in asset files
Apply Scale	FBX All	The units fix - bakes m->cm properly
Bake Space Transform	On	The axis fix - no -90 deg rotation stowaway
Apply Modifiers	On	Mirrors/bevels arrive as geometry
Smoothing	Face (UE) / Normals Only (Unity)	Kills the "no smoothing group" warning
Add Leaf Bones	Off	Avoids additional _end bones where the target rig doesn't need them
Custom Properties	On	Carries your metadata to the engine

Click the + at the top of the export dialog and save this as UE_Asset (and a Unity variant). That preset file lives in your Blender config - copy it to teammates, or better, ship it inside a studio add-on so everyone's exporter agrees by default.

The 30-Second Pre-Flight

1. Real-world size? (Compare against the 2m default cube.)
2. Front faces -Y?
3. Ctrl+A -> All Transforms applied; origin where the engine should grab it?
4. In its own correctly-named collection, _source junk excluded?
5. UVs exist, materials named properly (they become material slots in-engine)?
6. Export with the preset. If anything arrives wrong, fix the preset, not the instance.

Automate this checklist and you've built a portfolio piece - the cookbook's audit recipe is the skeleton.