The short answer: a Blender model usually arrives in Unity at the wrong scale, rotation, or shading because the two applications interpret units, axes, object transforms, pivots, and surface data differently. A reliable Blender to Unity export starts before you press Export: build at an intentional real-world size, place the origin correctly, apply the right transforms, verify face normals, and then use consistent FBX and Unity import settings.
Fixing the asset later by scaling or rotating its GameObject can hide the symptom, but it leaves technical debt. Colliders, children, animation roots, snapping, physics, and reusable prefabs may all behave differently. For mobile and standalone VR, a clean asset pipeline also prevents needless hierarchy work and makes performance testing more predictable.
Why does scale go wrong between Blender and Unity?
Unity treats one world unit as one meter for physics by default. Its current documentation says model size is influenced by three things: the size created in the modelling tool, the model import Scale Factor, and the GameObject’s Transform scale. That is why an asset can look correct while still carrying an awkward value such as 0.01 or 100.
A good target for most static game assets is simple: create the object at its intended size and make it enter Unity with a Transform scale of 1, 1, 1. In Blender, add a known reference—such as a two-metre guide for a doorway or a one-metre cube—before detailing the model. In Unity, compare the imported mesh with a one-unit primitive. This catches unit mistakes before they spread through prefabs and scenes.
What does “Apply Transform” actually fix?
Blender separates an object’s mesh data from its object-level Location, Rotation, and Scale. You can stretch a cube into a door while its underlying mesh and object transform still describe two different states. Blender’s official Apply documentation explains that applying transforms resets those values while preserving the object’s visible appearance.
For a typical static prop, select the object and use Object > Apply > Rotation & Scale. Aim for zero rotation and unit scale before export. Apply location only when you deliberately want the current position baked into the mesh, because location and origin decisions affect where the object pivots.
There is one important exception: do not casually apply transforms to an animated rig after skinning and animation are established. Armatures, constraints, inverse kinematics, and animation clips depend on a consistent rest setup. For animated assets, validate scale and orientation before rigging, or test changes on a copy.
Set the pivot before exporting
A mesh can have perfect dimensions and still feel broken if its origin is wrong. The origin becomes the practical pivot used for rotating, positioning, and snapping the imported object.
- Put a door’s origin on its hinge.
- Put a wheel’s origin at the axle centre.
- Put a floor tile’s origin on a predictable corner or its centre.
- Put a handheld VR object’s origin where the grab pose expects it.
After setting the origin, check the object from several views. Rotate it in Blender as a quick pivot test, undo the rotation, then apply Rotation and Scale if appropriate. A few seconds here can save repeated prefab offsets in Unity.
Use one consistent FBX export preset
For a static-mesh baseline, export only the selected objects to FBX, exclude cameras and lights, and export the evaluated mesh when modifiers must appear in the game asset. Blender and Unity use different axis conventions, so axis conversion is expected. Blender’s official FBX manual documents the exporter, while Unity exposes Bake Axis Conversion for bringing differing axis systems into asset data.
A commonly dependable Blender preset for Unity static meshes uses -Z Forward and Y Up. Keep the preset consistent across the project and test it with one unmistakably directional object before bulk export. Avoid compensating sometimes in Blender, sometimes in the FBX exporter, and sometimes on the Unity prefab; three overlapping fixes are how mysterious 90-degree rotations appear.
Check normals before blaming the material
If parts of a model are invisible, too dark, or lit inside-out, the problem may be face direction rather than the shader. In Blender, enable Viewport Overlays > Face Orientation. The Blender normals guide recommends this overlay for finding incorrectly oriented faces. In Edit Mode, select the affected geometry and use Mesh > Normals > Recalculate Outside where appropriate.
Then decide who owns shading. For a hard-surface asset whose edges were deliberately smoothed in Blender, import its normals. Unity’s current Model Import Settings reference notes that manually authored smoothing is best imported rather than replaced by a single automatic angle. If the model uses normal maps, tangents must also exist; calculating MikkTSpace tangents in Unity is a sensible default in many pipelines.
A practical Unity import checklist
- Select the FBX in the Project window and open the Model tab.
- Confirm Scale Factor is
1when the source asset was authored correctly; use Convert Units only as part of a consistent project rule. - Test Bake Axis Conversion if the root arrives rotated because of the source axis system.
- Set Normals to Import for intentional Blender shading, or Calculate when Unity should own smoothing.
- Leave Read/Write disabled unless runtime code genuinely needs CPU access to mesh data. Unity documents that disabling it lets the CPU copy be removed after upload, saving runtime memory.
- Avoid automatically generated mesh colliders on moving objects. Build simple collision from boxes, capsules, or a dedicated low-complexity collider mesh.
- Drag the asset into an empty test scene. Verify scale, forward direction, pivot, lighting, collider alignment, and a
1, 1, 1Transform before making the final prefab.
Fast diagnosis by symptom
| Symptom in Unity | Likely cause | First check |
|---|---|---|
| Exactly 100× too large or small | Unit conversion or import scale | Blender dimensions and Unity Scale Factor |
| Rotated 90 degrees | Axis conversion applied twice or not at all | FBX Forward/Up and Bake Axis Conversion |
| Rotates around empty space | Wrong object origin | Blender origin placement |
| Dark or missing faces | Reversed normals | Face Orientation overlay |
| Collider looks stretched | Non-uniform parent scale | Applied scale and hierarchy |
Why this matters in a real indie project
At Blekol Games, consistent scale is not just an art preference. In Periodic Table VR, readable objects and comfortable spatial relationships depend on a believable sense of size. In the mobile puzzle game Cubus, clean pivots and predictable dimensions help pieces align with a strict grid. The same discipline supports the stylised VR interactions in Cubus 2: Colors VR.
The best export workflow is the one you can repeat without improvising. Save a Blender FBX preset, keep a small Unity validation scene, and reject an asset that needs unexplained prefab corrections. Five minutes of checking at import time is cheaper than repairing dozens of scenes later.


Leave a Reply
You must be logged in to post a comment.