Optimize a Generated Asset for Real-Time Use
Get a generated model inside a real budget by fixing draw calls and texture memory before polygon count, building LODs, and exporting to a format the target actually reads.
Learning objectives
- Identify which budget an asset actually violates
- Build an LOD chain with sensible transition distances
- Reduce texture memory without visible quality loss
- Export to the target's expected format, scale, and orientation
ToolDix original visual
Frame
Name the outcome and constraints.
Build
Try one bounded workflow.
Review
Keep evidence, revise, and share.
"Too heavy" is a diagnosis people reach by looking at the polygon count, because it is the number that is easy to see. On modern hardware it is frequently not the binding constraint. Draw calls, material count, and texture memory limit real-time scenes far more often, and reducing polygons while ignoring them is effort that changes nothing measurable.
Measure first. Then fix the budget that is actually violated.
Four budgets, and polygons are rarely the tight one
Draw calls — roughly, the number of separate things the renderer is asked to draw. Generated assets frequently arrive split into many objects with many materials, and each split costs a call. Merging meshes and atlasing materials often produces a larger speedup than any geometry work.
Texture memory — usually the first hard wall, especially on mobile and web. Four 4K maps on one prop is 60-plus megabytes uncompressed, and a scene of those exhausts memory long before the polygons matter.
Polygons and vertices — real but generous on current hardware. Note that vertex count is what the GPU processes, and it exceeds the polygon count wherever UV seams and hard edges split vertices.
Overdraw and transparency — transparent surfaces are expensive and stack. Foliage and glass cost far more than their geometry suggests.
Profile before optimising. Every engine has a frame debugger that reports which budget you are exceeding, and five minutes with it prevents a day of the wrong work.
LODs, and the distances that make them invisible
An LOD chain provides progressively cheaper versions used at increasing distance. Three or four levels is typical: the full asset up close, roughly half at medium range, a heavily reduced version far away, and often a flat impostor or nothing at all beyond that.
Two things decide whether the chain works.
Transition distance. Set it so the switch happens when the difference is below perceptual threshold. Popping is caused by switching too late or by too large a jump between levels, not by having LODs.
Silhouette preservation. Reduce interior detail aggressively and protect the outline, since silhouette is what the eye tracks at distance. Automatic decimation tools generally have a weight for this; raising it is usually correct.
Also reduce texture resolution per level. An LOD3 mesh with a full-resolution texture saves geometry cost and none of the memory cost, which is typically the one that mattered.
Texture memory is where the wins are
Three moves, in order of value.
Right-size the maps. Texture resolution should follow how much screen space the asset occupies. A prop that is never larger than a few hundred pixels does not need a 4K albedo. Halving a texture's dimensions quarters its memory.
Pack channels. Roughness, metallic, and ambient occlusion are each single-channel data and can share one RGB texture. Three maps become one, and most engines expect this.
Use the target's compressed format. Compressed textures are read directly by the GPU and use a fraction of the memory. Which format depends on the platform, and shipping uncompressed PNGs is the most common avoidable memory mistake.
Atlasing several small textures into one also reduces material count, which feeds back into the draw call budget.
Export against the target's expectations
The last mile breaks more deliveries than anything technical above.
Scale and units. Engines differ on whether one unit is a metre or a centimetre. An asset that arrives a hundred times too large is the most common handoff failure, and it is a one-checkbox fix at export.
Up axis and forward axis. Y-up and Z-up both exist. So does an object lying on its back in the destination.
Origin placement. An origin at a character's feet or a prop's base is usable; an origin somewhere in space is not.
Format. glTF or GLB for web and most real-time engines, FBX where an established pipeline expects it, USD for interchange between larger tools, OBJ only when nothing else is available since it carries no modern material information.
What travels with the file. Materials, textures, and any rig either embed or they do not, depending on format and settings. Check by importing your own export into a clean project before sending it — a two-minute test that catches nearly every handoff problem.
Practice
Take one generated asset and get it into a real budget. Profile first and write down which budget it violates. Fix that one, re-profile, and note the change. Then build a three-level LOD chain, pack the roughness, metallic, and occlusion channels into one texture, and export twice — once as glTF for web, once for whatever engine you use.
Import your own exports into empty projects and check scale, orientation, and materials. Whatever fails there would have failed at the client, and finding it yourself is considerably cheaper.
Common mistakes
Optimising polygons because it is the visible number. Profile; it is usually textures or draw calls.
LODs with full-resolution textures. Saves the budget you had and not the one you needed.
Shipping uncompressed textures. The single largest avoidable memory cost.
Exporting without a round-trip check. Scale and orientation errors are trivial to fix and embarrassing to receive.
Sources and license context
These references informed the lesson. ToolDix adds its own explanation, workflow, and practice rather than reproducing source material. Every link below leaves ToolDix and opens the publisher's own site in a new tab.
- threestudio (opens github.com in a new tab)External · github.com (Apache-2.0)
- Blender Manual (opens docs.blender.org in a new tab)External · docs.blender.org (CC BY-SA 4.0)
Keep going
Read these next on ToolDix.
Original lessons that build on what you just read.