Optimisation Is a Budget, Not a Vibe
“Optimise it” fails as an instruction because optimisation is not a quality an asset has — it is a set of numbers an asset fits: this many polygons, textures no larger than this, this many materials, LODs switching at these distances, all inside a scene-wide frame budget measured in milliseconds. Learning how to optimise game assets therefore starts with the numbers themselves: the working polygon budgets by asset class, the texture-size rules that govern memory, how LODs and draw calls quietly dominate real frame times, and the profiling habit that tells you whether the asset in front of you is actually a problem (many aren’t). This guide gives typical ranges used on current PC/console projects — mobile budgets sit roughly a third to a half lower — and, more importantly, the reasoning behind them, so the numbers flex correctly for your platform and art direction. It assumes the asset was built through a sane pipeline; if you’re still at the workflow stage, our guide to how to create 3D models for games covers the creation order that makes optimisation a planned property instead of a rescue operation. Budgets set at the start of a project are art direction; budgets imposed at the end are triage — same numbers, very different moods.
Polygon Budgets by Asset Type
Working ranges for a mid-scope PC/console title, stated in triangles (the unit engines actually render): Hero characters (the player, major NPCs): 30,000–100,000, with the face and hands claiming a disproportionate share because cameras live there. Standard NPCs / enemies: 10,000–40,000. Weapons and held props: 3,000–15,000 — first-person view models sit at the top of that range, since the player stares at one for hours. Interactive props (chests, terminals, doors): 1,000–8,000. Background dressing (crates, barrels, rocks, debris): 200–2,000, because these multiply across a scene by the hundred and their cost is aggregate. Architecture modules: highly variable, but the discipline is modularity — repeated pieces the engine instances cheaply — rather than raw count. Three judgement rules ride on top of the raw numbers. First, spend where the camera spends time: silhouettes and close-range surfaces earn polygons; flat surfaces and perpetually distant objects don’t. Second, density evenness matters: a model with a 500-poly body and a 20,000-poly belt buckle wastes twice — once on the buckle, once on the normal map that could have carried it. Third, normal maps fake the small stuff: bolts, seams, panel lines, fabric weave belong in textures, reserving real geometry for shape the silhouette shows. An asset inside budget with detail in the right places looks richer than one at triple the count spent carelessly — players read silhouette and texture, not triangle totals.
Texture Sizes, Memory, and the LOD System
Textures, not polygons, eat most of a scene’s memory, and their arithmetic is unforgiving: memory scales with the square of the side length, so a 4096 texture costs four 2048s. Working rules: hero assets justify 2048 (occasionally 4096 for a main character’s face/body set); standard props live at 1024; background and small items at 512 or 256; and every texture in powers of two, because mipmaps — the pre-shrunk versions the engine swaps in at distance — require them. The multiplier beginners forget is the map set: a PBR material carries base colour, normal, roughness, metallic/AO — four textures at 2048 is not one 2048 decision, it’s four, plus mip chains adding a third again. Sharing materials and texture atlases across related props is the professional counter-move: ten props on one 2048 atlas frequently look better and cost less than ten private 1024 sets. LODs (levels of detail) then handle distance: LOD0 the full model, LOD1 at roughly 50%, LOD2 at 25%, and an optional billboard/impostor last stage — with switch distances tuned so the swap happens below the threshold of player notice, and shadows usually dropped a stage earlier than the mesh itself. Unreal and Unity both auto-generate serviceable LODs; hand-tuned ones earn their keep on hero assets and anything with a distinctive silhouette, where naive reduction eats exactly the outline the player recognises.
Compression and Platform Targets: The Settings Behind the Numbers
Two settings layers decide whether the budgets above survive contact with a real build. Texture compression is non-negotiable on every platform: uncompressed textures are a development-only luxury, and the standard formats (BC7/BC1 on PC and console, ASTC on mobile) cut memory by 4–8× at quality levels players cannot distinguish on properly authored source art. The practical habits: assign compression by map type (normal maps get their dedicated format or they shimmer), let the engine generate mipmaps rather than shipping your own unless you have a specific reason, and stream the largest textures rather than loading whole pools for a single room. Platform targets then scale the whole budget table: a mobile title typically targets a scene triangle count a modern console title spends on one district, draw-call ceilings an order of magnitude lower, and texture pools measured in hundreds of megabytes rather than gigabytes — which is why “typical budget” tables always need the platform footnote this guide keeps repeating. The professional workflow names the minimum target hardware first, authors to it, and treats headroom on stronger platforms as polish budget (higher LOD0 ranges, larger hero textures) rather than permission to let the base assets bloat. Optimisation done this way is not the art department’s enemy; it is the reason the art survives onto the machines players actually own.
Draw Calls, Materials, and Proving It With the Profiler
The final cost centre is invisible in the asset viewer: draw calls. Every mesh-plus-material combination asks the CPU to set up a draw, and scenes die of a thousand small meshes long before they die of triangle counts — a classic profile shows 8 million triangles rendering fine while 4,000 draw calls strangle the frame. The counters: keep material slots per mesh low (one or two is the prop ideal; every additional slot is another draw), merge static scenery that shares materials, use GPU instancing for repeated props (grass, crates, columns — the engine draws hundreds in one call), and be suspicious of transparency, which sorts and overdraws expensively wherever it layers. Then verify with the profiler, not with hope: both major engines show frame time split by CPU/GPU, triangle and draw-call counts per view, and texture memory pools; the optimisation loop is measure → find the pool that’s over → fix its worst offenders → measure again. Optimising unmeasured is redecorating in the dark: studios regularly discover the “heavy character” was innocent and the true cost was a forest of unmerged fence posts calling home 3,000 times a frame. The numbers in this guide — budgets, sizes, LOD ratios — are starting points that profiling adjusts to your scene. Hold them as defaults, check them against the profiler on real hardware (the minimum-spec machine, not the dev workstation), and the frame budget stops being a hope the game ships with and becomes a property it was built to have.
