Frame Cost per Scene: How to Predict It Before You Build
Estimate GPU and CPU frame cost per scene from asset metadata—draw calls, LODs, texture memory, shader complexity—before a build ever runs.
·8 min read
Frame cost per scene can be estimated before a build by reading asset metadata: draw calls and instancing, LOD coverage, texture memory, shader instruction counts, overdraw-prone materials and light/shadow casters. It is not a replacement for profiling, but it catches the expensive mistakes days earlier.
GPU cost signals you can read statically
Static scene data already predicts most GPU spikes.
- Unique materials and draw calls per scene
- Texture memory by platform and compression format
- Missing or badly distributed LODs on high-triangle meshes
- Translucent and masked materials stacking overdraw
- Dynamic shadow-casting lights per view
CPU cost signals
CPU frame time is usually actor and tick driven: number of ticking components, physics bodies, animation instances, blueprint or MonoBehaviour update chains and spawn bursts. These are countable before you press play.
Turn estimates into budgets
An estimate is only useful against a target. Set a per-platform budget for frame time, texture memory and draw calls, then flag the scenes that exceed it as part of the merge check instead of at milestone crunch.
Trend it per scene, per commit
Absolute numbers matter less than direction. A scene that grew 18% in estimated cost over ten commits is a regression you can still fix cheaply; the same scene discovered at cert is a rewrite.