Optimising a scene built from generated assets

Generated content fails performance in a specific, predictable pattern. What to do about each part of it.

A scene dressed with generated models tends to run badly for reasons that have little to do with polygon count.

The pattern

Every generated asset is unique. That means:

  • A unique mesh, so nothing instances.
  • A unique material, so nothing batches.
  • A unique texture, so memory scales linearly with asset count.
  • Arbitrary density, usually far above what the role needs.

Four separate problems, and the first three are consequences of uniqueness rather than of quality.

In order of impact

Consolidate materials. The largest win. Group assets by visual family, re-unwrap each group into a shared atlas, and give the group one material. Forty draw calls become a handful.

Generate variants, not instances. If a scene needs thirty crates, generate three and place them thirty times with varied rotation and scale. Uniqueness that nobody notices is uniqueness you paid for.

Retopologise to budget. Not to a generic number — to the tier the asset occupies. Background dressing can be very cheap.

Resample textures. Generated maps arrive at whatever the generator produced. Bring them to your project's texel density rather than shipping the source size.

Set import compression. Defaults are frequently wrong and this is where memory quietly goes.

What not to bother with

LODs on small background props in a draw-call-bound scene. They address the budget that is not binding, and they can make batching worse.

The general lesson

Generation makes producing assets cheap, which makes producing *many* assets tempting. The performance cost of a scene is driven far more by how many distinct things are in it than by how detailed each one is — so the discipline that matters is reuse, not reduction.