Course 2 · Game Asset · Master

Passing the asset cleanly into an engine

The export is where everything you got right quietly breaks: the agent exports a glTF that loads into the engine at 1/100th scale, with flipped normals and the normal map unhooked — each a one-line setting it never thought to check.

Choose your track

Read this module through your lens

Designers: the asset is only real once it lives in the engine. Judge it there, under game lighting.

Export is a border crossing

Saving a .blend keeps everything; exporting to glTF or FBX hands the asset to a different program that does not share Blender’s assumptions. Engines disagree about units (metres vs. centimetres), about which axis is “up” (Z vs. Y), and about how materials and normal maps are wired. So export is not a save — it is a translation across a border where things get lost.

The agent treats export as a one-liner and reports success the moment a file is written. But “a file exists” says nothing about whether it loads correctly on the other side. The classic failures all live at this border: the model arrives at 1/100th scale because the scale was never applied; it lies on its side because the up-axis differed; faces are invisible because normals flipped; the beautiful baked map is dark because it was imported as colour data instead of linear.

The master skill is to stop trusting Blender’s view and judge the asset where it will live.

The case study: a crate into the engine

prompt 1

”Export this crate as glTF for the game engine.”

output

”Exported successfully to crate.glb.”

failure

In the engine the crate is the size of a grain of rice (scale never applied), rotated onto its back (Z-up vs Y-up), and several faces are invisible from outside because their normals point inward. The normal map imported as sRGB, so the surface detail is subtly wrong. None of this was visible in Blender, where it looked perfect.

fix · prompt 2

”Apply all transforms (scale = 1). Export glTF with metres and Y-up. Recalculate normals outside. Link the baked normal map as non-colour and the AO as linear. Report the settings used.” Then import again and check in-engine.

Validate where it ships

The only verdict that matters at this stage is the one the target engine renders. A model can pass every check inside Blender and still arrive broken, because the defects are born in the translation, not in the model. So the final inspection happens after import, under the engine’s lighting, at the scale and orientation a player will see.

Run the Course-1 handoff checklist again first — applied scale, manifold, sane names — because export amplifies anything left unfixed. Then add the export-specific items: units and up-axis matching the engine, normals recalculated and correctly wound, baked maps linked with the right colour space (normal maps are data, not colour, so they must be linear/non- colour or the lighting goes subtly wrong). Export, import, and look.

If the asset stands at the right size, right-side up, fully opaque, with its baked detail reading correctly under game light — only then is Course 2 actually finished. The render in Blender never promised any of that.

Hands-on exercise

Take a baked, textured asset. Export it with the agent’s default settings and import it into a real engine or a glTF viewer — record every defect (scale, orientation, invisible faces, map appearance). Then re-export with applied transforms, correct units and up-axis, and maps linked in the right colour space. Screenshot the asset in-engine, correct, under lighting, and list the settings that made the difference.

Second case · an office chair into a glTF viewer

The same lesson, a different object

prompt 1

Export the office chair as glTF for the engine.

failure

In the viewer the chair arrives at 100x scale (centimetres read as metres), tipped onto its back (Z-up vs Y-up), and the baked normal map glows because it imported as sRGB instead of linear. In Blender it looked perfect.

fix · prompt 2

Apply all transforms. Export glTF in metres, Y-up. Link the normal map as non-colour and AO as linear. Report the settings, then re-import and inspect under engine lighting.

output

Right size, right-side up, detail reading correctly. The verdict came from the viewer, not Blender — the only place the border-crossing defects are visible.

Common failures · spot them fast

The failure gallery

Wrong scale in engine (cm/m mismatch, unapplied scale)

Up-axis mismatch (model on its side / back)

Flipped or inverted normals (faces invisible / lit wrong)

Baked maps not linked, or wrong colour space (normal as sRGB)

Agent says exported successfully — file never opened in the engine

Each of these is caught by a quality gate — keep the cheatsheet open while you work.

Worked example

See the journey

🖼 The chair inside a real engine or glTF viewer under game lighting — broken import vs corrected export side by side. screenshot slot · supplementary to the written core

The pattern

Export is a lossy boundary between two programs that disagree about units, axes, and material conventions. Own a pre-export checklist and validate inside the target engine, not in Blender — the only verdict that counts is the one the engine renders.

Cheatsheet

Prompt skeleton

Export [object] to [glTF/FBX] for [engine].
Apply transforms first (scale = 1). Units: [m]. Up axis: [engine convention].
Include: mesh, UVs, normals, baked normal + AO hooked into the material.
Report the export settings used and the final file's reported scale + axis.

Failure modes

Wrong scale in engine (cm/m mismatch, unapplied scale)
Up-axis mismatch (model on its side / back)
Flipped or inverted normals (faces invisible / lit wrong)
Baked maps not linked, or wrong colour space (normal as sRGB)
Agent says exported successfully — file never opened in the engine

Key operations

Apply transforms (scale = 1) before export
Set units + up-axis to the engine's convention
Recalculate normals outside; check winding
Hook baked maps with correct colour space (normal = non-colour)
Import into the engine and inspect under game lighting

Quality gates

Correct real-world scale in the ENGINE?
Right-side up, correct axis orientation?
Normals correct (no black/invisible faces)?
Normal map non-colour, AO linked, materials intact?
Validated in the target engine, not just Blender?

Workflow steps

Run the Course-1 handoff checklist again (scale, manifold, names)
Set export units + axis to the engine
Export with maps + correct colour spaces
Import into the engine; inspect under game lighting
Log the in-engine screenshot + settings used

Next module

Course 3 — Rigging & Animation: rig_first_armature. The asset learns to move.

Reflection

Reflection card

Active retrieval — answer from memory before re-reading. Saved to this browser.

1. Why is export a "lossy boundary" rather than a simple save?

2. Which export defect is invisible in Blender but obvious in the engine?

3. Why must a normal map be imported as non-colour / linear?

4. What belongs on an export checklist that is NOT on the modelling checklist?

You've completed this module when…

An asset imported and screenshotted inside a real engine (or engine-like viewer).
Stated export settings (units, axis, maps + colour spaces).
One cross-boundary defect (scale, axis, normals, or map link) caught in-engine and fixed.

Next: Course 3 — Rigging & Animation: rig_first_armature. The asset learns to move.

Finish — back to Game Asset →