Why Unreal recomputes your Blender normals, and how to prove it
Your model looks right in Blender. In Unreal it looks softer, or the bevels read like smudges. Nothing is broken, nothing errors out: the engine simply decided to compute its own normals instead of using yours.
The problem
You export a mesh with hard edges from Blender. In Unreal, the silhouette is the same, the triangle count looks plausible, and the material is attached. But the shading is wrong: what should read as a crisp mechanical edge reads as a soft crease.
There is no error message, because from the engine point of view nothing failed. The import did exactly what it was configured to do.
Why it happens
An FBX file can carry normals per vertex, per polygon corner, or not at all. On import, Unreal decides between two behaviours:
- Import Normals and Tangents: the normals in the file are used as they are.
- Compute Normals: the file normals are discarded and the engine generates its own from the geometry and a smoothing rule.
The second option is not a bug. It is a reasonable default for meshes that arrive without usable normals. It just happens to destroy the work you did in Blender when your normals were the point.
What the difference actually measures
We ran the same FBX file through two imports in a single Unreal Engine 5.8 session. The source is a 2 m cube with sharp edges and two materials, exported from Blender 5.2. Blender predicts 24 render vertices for it: eight corners, each split three ways because the three faces meeting there do not share a normal.
| Import setting | Render vertices | First normal |
|---|---|---|
| Import Normals and Tangents | 24 | (-1, 0, 0) |
| Compute Normals | 14 | (-0.577, -0.577, 0.577) |
Read the second row again. The normal (-0.577, -0.577, 0.577) is the corner direction: the three faces have been averaged into one smooth normal. And the vertex buffer shrank from 24 to 14, because vertices that no longer need separate normals get merged.
That is the whole story in two numbers. The geometry is intact, the shading is not.
How to check it by hand
Without any tool, the honest check is this:
- Import the asset in Unreal.
- Open the Static Mesh editor and turn on the normals display.
- Look at a hard edge: if the arrows fan out smoothly across it, your normals were recomputed.
- Check the asset import settings and compare with what you exported.
This works. It is also slow, it is subjective on curved surfaces, and nobody does it for the forty assets of a delivery.
How FixMyMesh detects it
FixMyMesh does not look at your Blender scene and guess. It exports the asset, launches the Unreal Engine installed on your machine, imports the file for real, reads back the render vertices and their normals, and compares them with the source.
When the normals drift, the report says by how much, over what share of the surface, and names the likely cause. It is a measurement, not an opinion: the same asset, the same engine version, the same numbers every time.
The fix
In the Unreal FBX import options, set Normal Import Method to Import Normals and Tangents. If you own the import pipeline, make that the project default instead of a per asset click.
This setting lives in the Unreal project, not in your .blend, so FixMyMesh never changes it for you: its report names the setting and the value to choose.
Then retest. A fix you have not re-measured is a hope, not a fix: that is why, in FixMyMesh, a repair is judged by testing again against the same target.
Test it on your own asset
FixMyMesh runs the same measurement on your files, in the engine installed on your machine. 3 full tests, free.