Setting Up Levels of Detail (LOD) for Graphics
LOD is not just "make three versions of a model". Incorrectly configured LOD Group in Unity can give opposite effect: LOD0 switches to LOD1 too early, player sees sharp pop, perceived as bug. Or transitions set by Screen Relative Height without accounting real distance, and on orthographic camera LOD doesn't work at all.
The point is LOD is a system for managing scene complexity depending on object visibility. And it works correctly only when accounting for: camera type, player movement speed, lighting (dropped shadows at LOD1 often worse than LOD0), and how engine calculates distance.
Real Problems That Break LOD in Production
LOD Pop—main visual problem. Happens when geometry and/or textures between levels differ too much. Classic case: artist made LOD1 with 60% fewer polygons, but UV unwrap shifted, and normal map doesn't compensate shape loss. Transition from 10 meters—noticeable to naked eye. Solved via proper LOD generator (Simplygon, Unity LOD Generator) with UV seam preservation and normal projection check.
Shadows don't follow LOD transitions. In Unity Shadow Caster Culling works independently from LOD Group. If you have LOD2—flat billboard with 2 polygons, but shadow still calculated from LOD0 mesh (because Force Shadow Casting = On), you pay for shadow render of full geometry object that visually isn't there. Easy to miss—Frame Debugger shows Shadow Pass with full Draw Call budget.
HLOD (Hierarchical LOD) not configured for large scenes. In open-world projects standard LOD Group doesn't work beyond 500 meters—objects just culled, but Scene not unloaded. Unity HLOD (via HLOD Creator package) combines distant objects into one mesh automatically. Without this you might have 3000 Draw Calls from trees on horizon.
How We Configure LOD in Projects
We start with game camera profile: FOV, typical object distance, movement speed. For first-person shooter with FOV 90° and 6 m/s movement speed LOD thresholds differ fundamentally from RTS with isometric camera.
For each object category (characters, buildings, props, vegetation) we set separate LOD policy. Example from practice—mobile RPG, open world 2×2 km. Trees: LOD0 (500 polygons) to 15 meters, LOD1 (80 polygons) to 50 meters, LOD2 (billboard cross) to 150 meters, Culled beyond 150 meters. Buildings: LOD0 to 30 meters, LOD1 to 80 meters, LOD2 to 200 meters. This setup gave transition from 680 Draw Calls city center to 210.
For Unreal Engine we work with Nanite where applicable—on static meshes with high poly count. But Nanite doesn't replace LOD for moving objects and doesn't work with translucent materials. HLOD in UE5 we configure via World Partition HLOD Layer.
Cross-fading instead of hard pop. Unity LOD Group supports Cross Fade mode—dithering transition between levels. Works via Dither Fade shader keyword. On mobile platforms dithering cheaper than seems—Adreno parallelizes it well. Enable for large objects front-scene, leave instant-transition for small distant prop.
Vegetation—separate story. SpeedTree LOD integrates in Unity via separate pipeline. Main trap—SpeedTree billboard LOD renders via separate BatchRendererGroup, needs profiling separately from main Draw Call count. Saw projects where 40% GPU time went to 2000 billboard trees that seemed "already optimized".
LOD Configuration Process
Audit starts with Profiler → GPU Usage and Frame Debugger filtered by Draw Calls. We look how many objects render beyond visible detail. Then—Scene View in Overdraw mode to find objects with high overdraw without LOD.
After audit we prepare LOD-specification: table with object categories, level count, threshold distances, shadow policy for each level. This artifact we agree with artist team—they need to understand how far "beautiful" geometry needed.
Implementation: either configure existing LOD Group, or create LOD assets (if missing), or auto-generate via Simplygon with manual fixes for critical objects.
| Task Scale | Estimated Timeline |
|---|---|
| LOD settings audit + report | 1–3 days |
| LOD setup for one scene (up to 200 object types) | 1–2 weeks |
| LOD-policy development + open-world implementation | 3–6 weeks |
| HLOD/Nanite integration in existing project | 2–4 weeks |
Cost determined after scene analysis and target platform requirements review.