Blender to Unity FBX Checklist: Scale, Pivot, Hierarchy and Import Settings

Exporting a model from Blender to Unity is easy. Exporting it so that the asset behaves predictably every time is where teams lose time.

A prop can look perfect in Blender and still arrive in Unity with the wrong size, an unusable pivot, a rotated root, duplicated materials or a hierarchy that makes placement harder than it should be.

This checklist focuses on the boring technical details that make a 3D asset reusable in a real project.

1. Confirm the intended real-world scale first

Do not treat scale as a cleanup step at the end.

Before export, decide what the object is supposed to measure in the game world. A door, chair, sword and barrel should all have a believable relationship to a human-sized reference.

Useful questions:

• How tall or wide should the asset be in meters?
• Does the project already use a modular grid?
• Is the object intended to snap to another piece?
• Will the player hold, climb, enter or collide with it?

In Blender, keep the scene units consistent and avoid compensating for scale mistakes later in Unity with arbitrary Transform values.

A clean asset normally arrives in Unity close to a usable 1,1,1 scale.

2. Apply transforms intentionally

Before export, inspect:

• object scale;
• rotation;
• object origin;
• parent transforms.

Applying transforms blindly can break carefully authored relationships, so do it with the final hierarchy in mind.

For a simple static prop, the goal is usually straightforward: predictable rotation, applied scale and a root object that imports cleanly.

For modular assets, consistency matters even more. If one wall section has a different applied rotation or scale from the rest of the kit, snapping and replacement become unnecessarily fragile.

3. Put the pivot where gameplay expects it

The visually obvious center is not always the useful pivot.

Examples:

• A door often needs its pivot on the hinge side.
• A wall section usually benefits from a predictable corner or center-bottom pivot tied to the grid.
• A weapon needs a pivot that makes hand placement and rotation manageable.
• A floor tile should sit cleanly on the ground plane.
• A hanging prop may need its pivot at the attachment point.

A good pivot reduces work every time the asset is placed.

If a designer has to create an empty GameObject around every mesh just to rotate it correctly, the asset is technically usable but not production-friendly.

4. Keep the hierarchy as simple as the asset allows

Every extra empty, nested parent or duplicate mesh creates another place for problems to hide.

For a static prop, prefer a minimal hierarchy unless there is a functional reason for separate objects.

Separate objects make sense when:

• a part moves independently;
• materials or gameplay interactions need separate control;
• a modular variation must be toggled;
• a collider or socket needs a dedicated transform;
• the object is intentionally assembled from reusable pieces.

They do not make sense just because the modeling process created many temporary objects.

Before export, ask whether every object in the hierarchy is useful to the person importing it.

5. Use readable names

Naming is cheap during production and expensive after hundreds of assets exist.

Avoid names such as:

Cube.001

Cylinder.014

Plane.008

Use names that describe the object or part:

SM_GothicDoor

SM_GothicDoor_Frame

SM_GothicDoor_Leaf

M_GothicWood

You do not need an elaborate enterprise naming convention for a small indie project. You do need names that remain understandable six months later.

6. Remove hidden production debris

Before export, check for:

• duplicate geometry;
• hidden objects that should not ship;
• unused temporary meshes;
• accidental cameras or lights;
• unapplied modifiers that should be baked;
• non-manifold problems that matter for the intended use;
• zero-area or duplicate faces;
• unexpected loose geometry.

Not every technical warning is automatically a real problem, but an export file should contain only what the game needs.

7. Check normals and shading

A model can look acceptable from one angle and still contain flipped normals or inconsistent shading.

Inspect:

• face orientation;
• hard/soft edge behavior;
• smoothing;
• normal consistency;
• bevel readability;
• whether weighted normals or custom normals are actually necessary.

If the model depends on a Blender-only shading setup that does not survive export, solve that before calling the asset game-ready.

8. Keep material slots under control

Every extra material slot is another draw-call or pipeline complication to consider.

For simple props, fewer materials are usually easier to manage.

Before export:

• remove empty material slots;
• merge duplicate materials where appropriate;
• use clear material names;
• verify that the correct faces use the correct slot;
• confirm texture file paths are organized.

If a model needs five materials because its design genuinely requires them, that can be fine. Five materials because the modeling file accumulated them accidentally is not.

9. Decide what should happen to modifiers

Modifiers can be useful while modeling, but the exported result needs to be predictable.

Review modifiers such as:

• Mirror;
• Bevel;
• Array;
• Solidify;
• Boolean;
• Weighted Normal.

Ask whether the modifier should remain editable in the Blender source or be represented as final mesh geometry in the exported FBX.

For marketplace or client delivery, keeping a clean source file and a predictable export is often more valuable than forcing every workflow step into one file.

10. Export only what you intend to ship

If the file contains reference meshes, cameras, lighting rigs or scratch objects, do not rely on luck.

Use a deliberate export selection.

A clean delivery folder might look like:

GothicDoor/
  FBX/
    GothicDoor.fbx
  Textures/
    GothicDoor_BaseColor.png
    GothicDoor_Normal.png
    GothicDoor_MRA.png
  Source/
    GothicDoor.blend
  Preview/
    GothicDoor_Preview.jpg

The exact structure is less important than consistency.

11. Verify axis and orientation in Unity

After import, do not assume the exporter handled everything perfectly.

Drop the asset into a clean Unity scene and confirm:

• forward direction;
• up direction;
• local rotation;
• world scale;
• pivot location;
• whether the object sits correctly on the ground;
• whether mirrored or modular parts line up.

The goal is not simply “Unity can open the FBX.” The goal is “the asset behaves exactly as the next person expects.”

12. Inspect mesh import settings instead of accepting defaults blindly

Unity import settings depend on the project, but common checks include:

• mesh compression;
• read/write access;
• normals and tangents;
• material import behavior;
• animation import when not needed;
• model scale factor;
• mesh optimization;
• generate colliders only when appropriate.

For a static prop with no animation, importing animation data is usually unnecessary.

For a marketplace asset, document any project-specific setup the buyer should know about instead of hiding it in your own local scene.

13. Test the asset in context

A technical import check is not enough.

Place the model beside:

• a human reference;
• a floor plane;
• one or two neighboring props;
• the modular pieces it must connect to.

Then inspect it at the camera distance the game will actually use.

This catches scale mistakes and readability problems that are hard to notice in an isolated modeling viewport.

14. Check collisions separately from the visual mesh

Collision requirements depend on the game.

A decorative shelf might only need a simple box collider. A doorway may need carefully separated collision so the character can pass through it. A weapon pickup may only need a small interaction volume.

Do not use complex mesh collision just because it is available.

Ask what the player actually needs to collide with.

15. Test a fresh import

One of the best final checks is to import the delivered files into a clean test project or a clean folder.

This reveals dependencies you forgot were local to your working project:

• missing textures;
• missing materials;
• wrong relative paths;
• hidden source dependencies;
• scene-only fixes;
• custom scripts that were never included.

If the asset only works inside the original production scene, the delivery is not complete yet.

A compact release checklist

Before shipping a static Blender-to-Unity asset, verify:

• Real-world scale is intentional.
• Scale and rotation behave predictably.
• Pivot/origin matches the asset's function.
• Hierarchy contains only useful objects.
• Object and material names are readable.
• No accidental hidden/debris objects are exported.
• Normals and shading are correct.
• Material slots are intentional.
• Modifiers produce the intended final geometry.
• Export orientation is correct.
• Unity import scale is correct.
• Unneeded animation data is disabled.
• Colliders match gameplay needs.
• Textures and dependencies are included.
• Fresh import works without local scene hacks.

When cleanup is cheaper than rebuilding

Sometimes the model itself is fine and the problem is only delivery quality: wrong pivots, messy hierarchy, inconsistent naming, export settings or material organization.

In that case, rebuilding the asset is unnecessary.

Knit of Shadows offers a small 3D model cleanup and game-ready export service for existing assets that need a cleaner handoff.

If you are commissioning a new model instead, use the free 3D Asset Brief Generator first so scale, engine, format and technical requirements are clear before production starts.

You can also estimate a starting budget with the 3D Game Asset Cost Calculator.