How to Set Polygon Budgets for Mobile Games

There is no universal polygon budget for a mobile character, prop, or scene. A triangle's cost depends on vertex attributes, skinning, shader work, projected area, overdraw, draw submission, cache behavior, resolution, and the rest of the frame. A 100,000-triangle opaque mesh can be cheaper than a 20,000-triangle layered transparent mesh.

Useful budgets begin with the weakest supported devices and the production camera. They allocate a measured scene envelope to asset roles, then use LOD and population tests to keep the worst representative view inside it.

Define device and quality tiers#

List actual supported devices, operating systems, engine version, renderer path, resolution policy, target refresh, thermal session length, and quality settings. Group devices by measured capability rather than only release year or brand.

For each tier record:

display and internal render resolution;
30, 45, 60, 90, or 120 Hz target;
CPU and GPU frame thresholds;
memory and package constraints;
lighting and shadow tier;
material and post-processing features;
maximum visible characters and props;
camera field of view and typical height;
world streaming and culling policy;
profiler and capture procedure.

A 30 Hz target has 33.3 milliseconds per frame; 60 Hz has 16.7. The renderer does not receive all of it because simulation, UI, audio, networking, and platform work share the interval.

Measure a representative scene first#

Build a vertical slice containing terrain or environment, the maximum normal character population, effects, UI, lighting, shadows, and streaming behavior. Use a difficult but plausible camera, not an empty test room.

Capture on a lower-tier physical device after 10–15 minutes so thermal behavior has stabilized. Record CPU submission, vertex and fragment GPU stages where available, draws, visible triangles, post-transform vertices, materials, texture memory, overdraw, shadows, and frame percentiles.

Run controlled toggles:

hide major geometry groups;
replace materials with a simple opaque shader;
disable shadows;
reduce render resolution;
freeze animation;
substitute low LODs;
disable particles and transparency;
reduce instance population;
remove post-processing;
capture warm and cold content states.

These experiments identify whether geometry is actually limiting. If halving visible triangles changes GPU time by 0.4 milliseconds while disabling transparency saves 5 milliseconds, polygon reduction is not the first priority.

Allocate a scene envelope#

Use the profiling result to establish a visible-scene triangle or vertex envelope with margin. The envelope is not a hardware maximum; it is a production planning number for one renderer and quality tier.

Suppose a lower-tier device holds 30 Hz with 420,000 visible triangles, 180 draws, simple opaque materials, and 5 milliseconds of GPU margin in the vertical slice. The team might set a 350,000 normal-view geometry budget and reserve the remaining margin for effects, variation, and regressions.

Allocate that 350,000 by system:

environment and terrain: 150,000;
8 characters: 120,000 total;
interactive props: 40,000;
weapons and attachments: 20,000;
VFX meshes and UI geometry: 20,000.

This suggests 15,000 visible triangles per character in that particular worst view, not a universal character rule. A boss close-up can borrow from an environment that is culled; a crowd view needs lower character LODs.

Budget vertices as well as triangles#

The GPU processes vertices after UV seams, hard normals, material boundaries, colors, skin attributes, and other discontinuities split them. A DCC can report one position shared by several faces while the delivery mesh stores multiple vertex records.

Record post-import or runtime vertices and attribute stride. Position, normal, tangent, 2 UV sets, color, 4 joints, and 4 weights make a much wider vertex than position and normal alone.

Index width and platform support matter. Some pipelines split meshes around 16-bit index limits; modern targets may support wider indices with different memory consequences. Follow current engine and device documentation rather than inheriting an old 65,535-vertex rule blindly.

Remove attributes unused by the shader and gameplay. A second UV set for lightmaps is valuable only when that lighting path uses it. Tangents are unnecessary for a material without tangent-space normal mapping.

Classify assets by role and screen size#

Define roles such as hero character, standard character, crowd character, first-person weapon, large environment landmark, modular kit, small prop, foliage cluster, and VFX mesh. For each, record maximum projected height or screen coverage and population.

Set LOD0 based on the closest normal camera, not an editor zoom that players cannot reach. Protect silhouette and animation joints. Allocate less density to flat interior areas and hidden surfaces.

An asset viewed at 120 pixels tall cannot communicate hundreds of one-pixel triangles reliably. Android's current game geometry guidance specifically warns about micro-triangles: the GPU processes them even when they contribute little to the final image.

Use one-pixel and subpixel density visualization where the profiler supports it. Replace distant geometric texture with stable baked or material detail.

Create LOD budgets from screen contribution#

Build LOD tiers at measured screen size. Example targets for one standard character might be 28,000 triangles at close interaction, 13,000 at normal gameplay, 5,000 at mid distance, 1,500 in crowds, and an impostor beyond that. The actual transition should come from contour and motion tests.

Reduce skeletal complexity with geometry. Later LODs can use fewer bones, simpler weights, disabled morphs, lower animation update rate, and cheaper materials. A triangle-only LOD that retains every facial morph and 8 material sections misses much of the cost.

Use hysteresis or fade where the engine supports it and where the fade cost is acceptable. Test a moving camera and animated silhouette. Avoid synchronized popping across 50 crowd members.

Strip unused high LODs from lower device tiers if memory and package size matter. Engine support for per-platform minimum LOD can prevent mobile from storing detail it will never render.

Account for material sections and draws#

Every material section can become a draw, and shadows, depth, outlines, or extra passes can multiply work. Budget section count beside triangles.

A 12,000-triangle character with 9 materials may cost more CPU submission than a 20,000-triangle character with 2. Merge skin, cloth, and accessories where their shading and customization rules allow. Preserve a section only for a real shader, visibility, or variant requirement.

Use instancing for repeated static props and foliage, but partition instances spatially enough for culling. One giant instance group can draw many hidden objects; thousands of tiny groups restore submission overhead.

Do not merge an entire level into one mesh solely to reach a draw target. Visibility, streaming, collision, lightmaps, and lifecycle constrain useful batching.

Separate static and skinned budgets#

Skinned vertices require bone transformation and often wider attributes. Morph targets add buffers and shader work. Shadows can redraw the skinned mesh. Budget characters with animation enabled and the production skeleton.

Test the maximum simultaneous population and animation diversity. Ten copies sharing geometry and animation data do not necessarily cost 10 times one copy, but skinning and draws still scale.

Remove unused bones and influences. Preserve deformation quality around joints. Lower LODs can collapse finger, facial, cloth, or accessory bones that no longer change the silhouette.

For static environment geometry, focus on culling granularity, overdraw, lightmap data, and repeated materials. A larger static mesh can be efficient when visible together; a dense occluded mesh still wastes work if bounds keep it submitted.

Include shadows and transparency#

Shadow-casting geometry can be rendered from one or more light views. Build simplified shadow meshes or disable distant casters where the visual result permits. A foliage asset with 30,000 cutout triangles can be expensive in the camera and shadow passes.

Masked and blended surfaces produce overdraw and can reduce early-depth efficiency. Mobile renderers are often sensitive to layers covering large screen areas. Measure with overdraw or shader-complexity visualization.

If reducing a transparent particle mesh from 2,000 to 1,000 triangles does not reduce its covered pixels, the fragment cost may barely change. Shrink overlapping quads, simplify the material, reduce layers, or lower resolution instead.

Budget opaque, masked, and blended geometry separately. Do not add them into one triangle total and assume equal cost.

Use starter ranges carefully#

Early production needs placeholder numbers before final content exists. Use ranges as hypotheses tied to a test scene, never as guarantees.

One project might start with:

20,000–40,000 triangles for a close hero on high tier;
8,000–18,000 for a normal gameplay character;
1,000–5,000 for crowd LODs;
500–8,000 for common props based on size;
50,000–150,000 for a large landmark visible alone;
250,000–600,000 total visible geometry by tier.

Another project with unlit materials and few draws may support more; a high-resolution game with layered materials and dynamic shadows may support less. Replace provisional ranges with captured evidence as soon as the vertical slice runs on devices.

Keep 15–25% scene margin where feasible for gameplay peaks, effects, engine changes, and measurement noise.

Automate asset and scene checks#

Example budget reallocation#

Suppose a forest encounter exceeds the lower-tier envelope by 110,000 visible triangles. The first instinct is to cut the hero from 32,000 to 16,000, but the capture shows 140 distant rocks retaining LOD0 at 900 triangles each. Correcting their screen thresholds saves about 100,000 triangles with no close-up loss. Reducing 3 shadow-only foliage clusters and merging copied materials supplies the remaining margin.

Now preserve the hero budget because its face and weapon dominate the camera. This is why a scene envelope outperforms a per-asset spreadsheet: it directs reduction to geometry that contributes least in the failing view.

Document the revised thresholds and rerun adjacent camera paths. A fix that works in one angle can expose popping or a different visibility peak 5 meters away.

At import or build time, report triangles, runtime vertices, sections, materials, attributes, LOD counts, reduction ratios, skeleton joints, influences, morph targets, bounds, collision complexity, and texture estimates.

Apply role-specific warnings. A small background prop over its 8,000-triangle provisional budget should warn or fail; a deliberately approved landmark should carry an exception with owner, reason, target scene, and expiry review.

Run scene capture routes in continuous performance tests. Record visible triangles, draws, CPU and GPU milliseconds, memory, and frame percentiles by device profile. Asset checks prevent obvious outliers; scene tests validate composition.

Do not silently auto-decimate every violation. Geometry damage needs visual review and often rebaking.

Revise budgets with evidence#

Budgets are contracts, not monuments. Update them when renderer path, resolution, lighting, device floor, camera, or population changes. Maintain versioned profiles.

If an engine update makes vertex processing 20% faster but increases material cost, do not raise every polygon limit automatically. Repeat the controlled tests. If gameplay changes from 6 to 20 enemies, character LOD and material work likely need a new allocation.

Review rejected and approved exceptions. If half the props require the same exception, the role definition or art direction may be wrong. If one asset consumes 30% of the visible envelope, give it an explicit scene rule.

Communicate budgets in artist-facing reports with screen views and suggested actions, not just red numbers.

Mobile polygon-budget checklist#

Device, renderer, resolution, refresh, and quality tiers are named.
A thermally stable physical-device vertical slice defines the baseline.
Geometry is proven to be a limiting or material contributor.
A visible-scene envelope includes gameplay margin.
Asset-role allocations include population and screen size.
Runtime vertices, attributes, sections, and triangles are all reported.
LODs reduce skeleton, morph, material, and shadow cost where appropriate.
Static, skinned, opaque, masked, and blended geometry are evaluated separately.
Draw calls, culling granularity, instancing, and streaming remain balanced.
Provisional ranges are labeled and replaced with captured evidence.
Automated asset gates and scene routes detect regressions.
Budgets are versioned when the renderer, device floor, or game changes.

Sources and further reading#

A polygon budget is a scene allocation backed by a device capture. Define the frame and population first, distinguish vertex, draw, material, skin, and overdraw costs, and revise role limits as production evidence replaces placeholder folklore.