Why materials rarely survive an engine import

Every engine has its own shading model. What transfers, what does not, and why rebuilding is normal rather than a failure.

A model imports and its materials look wrong. This is expected, and understanding why saves a lot of time trying to fix it at export.

Formats carry a description, not a shader

glTF defines a PBR material model — base colour, metallic, roughness, normal, occlusion, emissive — and that transfers reasonably well because it is a standard. FBX carries a much older material description that predates PBR, so it approximates.

Neither carries a shader. What an engine renders is its own shader interpreting those values, and interpretations differ.

What usually transfers

  • Base colour texture assignment
  • Normal map assignment
  • Rough approximations of metallic and roughness, when the source used glTF's model

What usually does not

  • Anything procedural. Node graphs, layered materials, generated noise — all of it evaluates in the authoring tool and has no representation in a file format.
  • Custom shaders of any kind.
  • Subsurface scattering, clearcoat, anisotropy, and other extended lobes, unless both ends support the same extension.
  • Texture tiling and offset, sometimes.

The practical workflow

Author textures, not materials. Export the maps; rebuild the material in-engine from a project master material. This is what production teams do, and it is why engines emphasise material instances.

For generated assets

Generated models arrive with a simple PBR material — usually base colour and not much else. That imports about as well as anything does, and the rebuilding step is short because there is little to rebuild. The work is in authoring the missing channels, not in translating existing ones.