Before you generate anything: set the scene up correctly
Three settings cause most of the pain later:
- Units. Set the unit system and scale before generating. A 6 m house generated into a scene configured in centimetres arrives 100× too large, and every camera and light you set afterwards inherits that mistake.
- A dedicated collection. Put generated assets in their own collection so batch operations - reduce, rename, export - can target them without touching the rest of the file.
- A reference object. Drop in a 1.8 m cube to represent a person. It costs ten seconds and instantly tells you whether the asset is the size you asked for.
Write a brief, not a wish
Prompt quality decides most of the result. Four facts belong in every prompt:
- Object - what it is, specifically
- Style - low-poly, stylised, photoreal, cartoon
- Scale - real-world size, in metres
- Destination - game engine, render, 3D print, AR
Low-poly medieval house, tile roof, timber beams, 6 m wide, game-ready is workable. a house is a coin flip. The Blender manual section on scene units explains the numbers you are describing, and it is worth knowing them so your prompts match the data model.
Generate, then inspect before you keep modelling
When the mesh lands, run the same inspection pass you would run on an asset you bought:
| Check | Why it matters |
|---|---|
| Scale and origin | Everything downstream inherits it |
| Polycount | Dense meshes are expensive to edit and render |
| Normals | Flipped faces look fine in the viewport and wrong in the engine |
| UVs | Only critical if you plan custom textures |
| Naming and collections | Cheaper to fix now than after a batch export |
If the mesh is dense, reduce it before you retopologise. If it needs deformation, retopologise only the parts that bend - a technique covered in the model generator workflow.
Where AI helps beyond modelling
- Rendering. Block a camera, place three-point lighting, and iterate before committing to a final sample count. EEVEE for speed, Cycles when bounce light and glass matter.
- Scripting. Batch operations are the highest-value automation: export every object in a collection as its own file, rename assets to a naming convention, assign materials by rule. The Blender Python API is the ground truth for what a generated script can touch.
- Scene hygiene. Cleaning non-manifold edges, merging duplicate vertices and preparing meshes for printing is unglamorous, repetitive, and exactly what a prompt handles well.
Export to the engine without a conversion step
Because the asset was authored in Blender, the export is Blender's own: FBX for Unity and Unreal, glTF/GLB for Godot and the web, OBJ for interchange, USDZ for Apple AR, STL for printing. The glTF specification maintained by the Khronos Group is the reference for what travels in a GLB, including PBR materials and animation.
Two habits prevent most export surprises: open the exported file once in the target engine before you call it done, and keep the .blend file next to it - the next revision is always faster in Blender than in a converter.
