A polygon budget is a per-asset allowance derived from a whole-scene target. Numbers quoted without that context are close to meaningless.
Work backwards from the frame
Start from the target: platform, resolution, frame rate. That gives a total geometry budget per frame. Divide by how many objects are typically visible. Divide again by role — a hero asset takes a large share, a background prop a small one.
The result is a budget you can defend, and it changes if the scene composition changes.
Role-based tiers
Rather than one number, define tiers:
- Hero. Seen close, inspected, central. The largest allowance.
- Standard. Normal props at normal distance.
- Background. Never approached. Cheap.
- Instanced. Repeated many times. Cheapest per instance, because the cost multiplies.
Assign every asset a tier at planning time and the budget conversation happens once rather than per asset.
Count triangles, and watch vertices
Everything renders as triangles, so quote triangles. But the vertex count is what the vertex shader processes, and vertices duplicate at every UV seam, hard edge and material boundary — so a mesh's effective vertex count can be well above what its triangle count suggests. Two models with identical triangle counts can differ substantially in cost.
Geometry is often not the bottleneck
On modern desktop hardware, a typical scene is limited by draw calls, texture memory or overdraw long before vertex count. Optimising polygons in a draw-call-bound scene achieves nothing.
Measure first. The profiler tells you which budget is actually binding.
Where it is binding
Mobile, VR (two eyes, high frame rate), very large scenes, and anything heavily instanced. There, geometry discipline matters directly.
Generated meshes
Reconstruction density is arbitrary — an artefact of the algorithm rather than a decision. It bears no relationship to your budget and is usually far above it. The budget is the input to retopology, not something the generated mesh informs.