Automation guide
Blender batch export: the prep that stops assets breaking on import
Blender batch export to FBX and glTF: the scale, axis, naming and material rules that stop assets breaking in Unreal, Unity and Godot.
Blender batch export is where a week of good work goes wrong quietly. The mesh is clean, the UVs are right, the textures are baked, and then forty objects land in the engine at a hundredth of their intended size, rotated ninety degrees, with material slots called Material.003 and a hierarchy that nobody can navigate. None of that is an export bug. It is prep that did not happen, repeated forty times.
In Mixar the prep is a brief, and the export presets for Unity, Unreal and Godot ship with the editor. Mixar is a 3D editor built on Blender, so the exporters and their settings are the familiar ones; what is added is an agent that can audit a scene against a convention and fix what breaks it.
Below is the prep list itself, and why each item exists.
Doing it by hand
Check each object's scale. Apply transforms. Set the origin. Rename to the convention. Check the material slots. Pick the right export preset. Repeat, per asset, forty times, and find the one you missed after the import.
Briefing it
State the convention once. The agent walks the scene, reports which objects violate it, and runs the fixes as one pass with Plan Mode holding the plan until you accept it.
Scale and units, the one that bites hardest#
Blender's default unit is the metre and its default scale is 1.0. Unreal works in centimetres. Unity works in metres. FBX has its own unit metadata that different applications interpret differently.
The rules that hold:
- Apply scale before exporting.
Ctrl+A > Scale. An object with a scale of 0.01 that looks correct in Blender exports as a small object with a scale factor attached, and how that factor is honoured depends on the importer. - Set the scene unit scale deliberately in
Scene Properties > Unitsrather than compensating with object scale. - For Unreal via FBX, the usual setting is
Apply Scalings: FBX Allwith a scene unit scale of 0.01, or export at metre scale and let Unreal's import scale handle it. Pick one convention for the project and never mix them. - For glTF, the format is metres by definition, which removes most of the ambiguity. This is one of several reasons glTF is the easier target where the pipeline allows it.
The symptom of getting this wrong is an asset that is 100 times too large or too small. The symptom of getting it half wrong is an asset that is the right size but whose child objects are not.
Axes#
Blender is Z-up, Y-forward. Unreal is Z-up, X-forward. Unity is Y-up, Z-forward. glTF is Y-up.
The FBX exporter has Forward and Up dropdowns for exactly this. For Unity the common setting is Forward: -Z, Up: Y. For Unreal, Forward: -Y, Up: Z with "Apply Transform" enabled, though Unreal's own FBX importer also has opinions about this and the correct combination depends on which side you let do the conversion.
The reliable approach is not memorising the matrix, it is picking a convention, writing it down, and applying it identically to every export in the project. Assets that were exported under two different conventions in the same project are the single most common cause of "why is this one prop rotated".
Naming#
Names are the interface between Blender and everything downstream. Four separate name fields matter and they are not the same field:
- Object name. What the importer usually uses for the asset name.
- Mesh datablock name. Often ignored, sometimes not.
- Material name. Becomes the material slot name in the engine, and is what texture assignment scripts match against.
- UV map name. Matters when a shader expects a specific UV set, especially for lightmaps as a second channel.
A convention worth having: a prefix for type, a project or set identifier, the object identity, and a variant suffix. SM_Warehouse_Crate_01. The specifics matter far less than the consistency.
Blender's Batch Rename (Ctrl+F2) does the mechanical work across a selection, including material and datablock names via the type dropdown.
Hierarchy and transforms#
- Parent structure survives export, so use it deliberately. An empty at the origin as a parent gives a clean pivot.
- Object origins should mean something. For a prop that sits on the floor, the origin belongs at the base, not at the centre of the bounding box.
Object > Set Origin > Origin to 3D Cursorafter snapping the cursor where you want it. - Delete or exclude helper objects. Cages, blockout references, lattices, empties used for modelling. They export unless you stop them.
- Modifiers. The FBX exporter applies them by default. That is usually what you want, and it is not what you want for a mirror modifier feeding overlapping UVs, or for subdivision you intended the engine to handle.
Materials and textures#
Export formats carry material references, not the textures themselves in most configurations. What matters:
- One material per intended engine material. Merge duplicates first.
Material,Material.001andMaterial.002that are identical produce three engine materials. - Remove unused slots.
File > Clean Up > Unused Material Slots, or the minus button in the material properties. - Texture naming that matches the material.
SM_Crate_01_BC,_N,_ORM. Engine-side automation depends on this. - Normal map convention. Blender bakes and displays +Y green channel; Unreal expects -Y. Decide at export, not after import. Covered further in automating baking in Blender.
- glTF packs differently. It expects occlusion, roughness and metallic packed into one texture's R, G and B channels, which is defined in the glTF 2.0 specification rather than being a Blender convention. Producing that packed map is its own step.
Batch exporting itself#
Blender's built-in options for exporting many objects to many files:
Export Selected, once per object. Manual, and it works. Forty objects means forty exports.
The Batch Export operator. Recent Blender versions include a collection-based batch export in the file menu that exports each object or collection to its own file. Worth checking whether the version you are on has it before reaching for anything else.
Python. A loop over objects, setting the export path per object and calling the exporter. Twenty lines. This is what most studios actually use, and the maintenance cost is that the script encodes one set of assumptions.
An add-on. Several exist and they mostly wrap the same loop with a UI.
Where the agent fits#
The export step itself is trivial. The prep is not, and the prep is a checklist run per object: transform applied, origin correct, naming to convention, materials merged, unused slots removed, helper objects excluded, modifiers resolved, UV sets named right.
That is a conditional inspection followed by a mechanical fix, forty times over. It is the same shape as the scene cleanup pass and it is automatable for the same reason: nothing on the list is a creative decision, and every item on it is something a person forgets on object thirty-one. The AI agent for Blender pillar covers the rest of that family of passes, of which export prep is the last one.
A pre-export checklist#
Before exporting anything:
- Transforms applied on every object being exported.
- Origins where they should be for the asset's use.
- Scene units and export scale settings match the project convention.
- Forward and Up axes match the project convention.
- Object, mesh, material and UV map names follow the convention.
- Duplicate materials merged, unused slots removed.
- Helper and reference objects excluded from the selection or the collection.
- Modifiers resolved deliberately, not by default.
- Normal map green channel decided for the destination engine.
- A single test asset imported into the engine and checked before batching the other thirty-nine.
Step 10 is the one that saves the most time and is skipped the most often.
If the assets going through this are generated rather than modelled, the list is longer and starts earlier: image to 3D for game assets covers what an engine actually requires and what a generated mesh arrives without.
Frequently asked questions
How do I batch export multiple objects in Blender?
Recent Blender versions include a batch export operator that writes each object or collection to its own file. Failing that, a short Python loop that sets the filepath per object and calls the FBX or glTF exporter does the job, and is what most studios use. The export call is the easy part; the per-object prep before it is where the time goes.
Why is my FBX the wrong size in Unreal or Unity?
Almost always unapplied object scale, mismatched scene unit scale, or an FBX export scaling setting that does not match what the importer expects. Apply scale in Blender, pick one unit convention for the whole project, and check a single asset in the engine before exporting the rest.
Should I export FBX or glTF from Blender?
glTF is simpler where the pipeline supports it: it is metres by definition, Y-up by definition, and it carries PBR materials in a standard way. FBX remains necessary for pipelines built around it, particularly ones involving skeletal animation with existing rigs. Both are fine when the prep is right; glTF has fewer ways to get the prep wrong.
Why is my exported model rotated the wrong way?
Blender is Z-up and Y-forward, and the target engine almost certainly is not. Set the Forward and Up dropdowns in the exporter to match the destination, apply object rotation before exporting, and use the same combination for every asset in the project. Mixed conventions within one project are the usual cause of a single prop being rotated when the rest are fine.
Can Blender batch export be automated?
The export itself is trivially scriptable; the prep is what needs automating, because it is a conditional inspection followed by a mechanical fix, repeated per object. Mixar, a 3D editor built on Blender, can walk a scene, report which objects break a stated convention and run the fixes as one pass, with an approval step before it renames anything, which matters because bulk renaming is hard to undo selectively.