Levels of Detail (LOD): Designing Models That Scale With Distance

Level of detail, usually shortened to LOD, means using a cheaper representation when an object cannot reveal all of its original detail. A close product view may need a rounded silhouette, modeled openings, and small bevels. The same object occupying 40 screen pixels cannot display most of that information, yet the renderer may still process every triangle unless the application chooses another representation.

LOD is not synonymous with automatic decimation. It is a runtime policy plus a family of assets. The policy decides which representation is appropriate; the assets must preserve the right features at each viewing condition. Bad thresholds can make excellent meshes pop, and well-designed thresholds cannot repair a collapsed silhouette.

The real variable is projected size#

Distance is a convenient proxy, but visible detail depends on projected screen size. A 10-meter statue and a 10-centimeter figurine at the same camera distance do not occupy the same number of pixels. Field of view, viewport height, object scale, and camera projection also matter.

Screen-relative measurements provide a more portable rule. Unity's LOD Group documentation defines thresholds using an object's screen height relative to total screen height. Unreal also exposes screen-size-based LOD behavior. Three.js offers a simpler distance-based LOD object, so applications that need projection-aware switching may calculate their own thresholds.

Suppose an object's bounding height projects to 600 pixels on a 1200-pixel-tall viewport. Its relative height is about 0.5. If the camera pulls back until it projects to 120 pixels, the ratio becomes 0.1. An LOD policy can use these ratios without assuming a fixed physical distance.

Bounds are only an estimate. A long diagonal object can have a large box but few visible pixels. An animated character's bounds change with pose. Establish thresholds with captures from representative cameras, then use the runtime metric as the repeatable trigger.

What should change between levels#

Geometry reduction should be selective. As projected size falls, preserve features in roughly this order:

the outer silhouette;
large holes and negative spaces;
major material regions and color blocks;
broad curvature that controls highlights;
animation volumes and contact points;
shadow-casting features large enough to remain visible;
medium surface breaks;
small bevels, fasteners, and recessed details;
microgeometry already below a pixel.

Far levels can make changes beyond triangle count. They may combine materials, use smaller textures, remove transparent inner layers, drop bones or morph targets, replace complex hair with cards, or become an impostor. Each change needs separate validation because it alters a different cost.

A lower LOD should normally keep the same origin, orientation, overall dimensions, and semantic identity. If its pivot shifts 2 centimeters, switching can look like motion. If material order changes unexpectedly, runtime bindings can apply the wrong surface.

Choosing how many levels#

More levels allow smaller steps but increase asset storage, build time, review work, and runtime state. Three or four geometric levels are common starting points, not a law.

Choose another level when both conditions hold:

there is a meaningful cost gap between two representations;
there is a range of projected sizes where the new representation passes visually.

Imagine a source with 120,000 triangles. Candidate outputs contain 60,000, 28,000, 11,000, and 3,000 triangles. If the 60,000 version looks identical only within a narrow close-up range and saves no measurable frame time, it may not justify another asset. If 28,000 passes through most interaction and reduces vertex work across 80 repeated props, it probably does.

Storage can grow if each LOD is delivered inside one initial package. Geometry compression reduces transfer cost, but the browser may still download and decode levels that are never shown. Consider progressive loading: fetch the interaction level first, request close detail when the camera or user intent requires it, and cache it afterward.

Define a loading fallback for every moment. A distant level can appear immediately while LOD0 downloads, but the system should avoid oscillating back to a missing level or showing nothing. Record time to first visible model, time to interaction-quality detail, and bytes fetched during a session that never zooms in.

Generating candidates#

Automatic simplifiers make fast search candidates. Generate a broad range rather than betting on one ratio:

75% of original triangles;
50%;
30%;
15%;
8%;
3% for a very distant test.

These percentages say nothing about quality by themselves. They sample the curve. Render all candidates, find where failure begins, then generate closer ratios around that boundary.

Protect or weight features that the algorithm cannot infer from geometry alone. A thin antenna may contribute few triangles yet be central to recognition. Material borders, UV seams, skin-weight discontinuities, hard normals, and open boundaries may need preservation constraints. Manual cleanup after automatic reduction is often worthwhile for hero assets.

The Unreal automatic LOD documentation describes quadratic simplification that collapses edges based on estimated visual difference. That estimate is useful, but production acceptance still requires the project's cameras, materials, and motion.

Deriving switch thresholds#

Find the largest screen size at which a lower level is indistinguishable or acceptably different. If LOD1 first passes below 35% relative height, switch somewhat below that boundary to provide safety. Repeat for each pair.

Test at the final output resolution. A threshold approved in a 700-pixel editor panel can fail on a 4K display. Also test different fields of view: a wide-angle camera and telephoto camera can place the same object at different distances while producing similar projected size.

For distance-only systems, derive a starting distance from the camera projection and bounding size, then verify empirically. Do not copy 10, 25, and 50 meters from an unrelated asset. The Three.js LOD API associates levels with distance and supports hysteresis as a fraction of distance, which can reduce rapid boundary switching.

Hysteresis prevents thrashing#

If the switch threshold is exactly 100 pixels, camera jitter can make the object alternate between 99.9 and 100.1 pixels every frame. This thrashing wastes work and creates visible flicker.

Hysteresis uses different boundaries depending on direction. The system might switch from LOD0 to LOD1 below 95 pixels but not return to LOD0 until above 105 pixels. That 10-pixel dead band stabilizes the choice. A time-based delay can help too, though it may feel laggy during fast camera movement.

Track transition counts during a normal play or viewing session. Hundreds of switches per minute for one object indicate unstable policy even if the exact pop is hard to notice in a still capture.

Hiding the transition#

An instantaneous mesh swap can pop because positions, normals, silhouettes, or shading change at once. Several techniques reduce the artifact:

Switch below visibility. The cheapest method is to place the transition where differences occupy less than the accepted number of pixels.

Cross-fade. Render both levels briefly while a dither or alpha pattern transfers coverage. This can double geometry submission during the fade and may interact with transparency, temporal antialiasing, or depth.

Geomorph. Move corresponding vertices from one representation toward another. It requires a relationship between levels and more runtime data.

Fade small components separately. An antenna or badge can disappear gradually before the main mesh changes, but this adds authoring and draw complexity.

Match normals and materials. Even when silhouettes align, different tangent bases or roughness can flash. Bake or transfer shading data consistently.

Watch transitions while the object and camera move. A slow editor scrub is not representative of a rapid turn, teleport, or VR head motion.

LOD for animated models#

Animated LODs must preserve deformation and attachment behavior. Simplification can remove loops around joints, change skin weights, or delete vertices referenced by cloth and morph systems.

Validate:

identical skeleton hierarchy or a documented reduced rig;
stable bind transforms;
matching root and pivot;
extreme joint poses;
sockets and attachment points;
blend shapes or an explicit fallback;
cloth and physics handoff;
shadow representation;
transition during animation, not only in bind pose.

A lower level may use fewer bones, but mapping must be deliberate. Removing finger joints while the character is 30 pixels tall is reasonable; shifting a held tool because its socket disappeared is not.

Crowds benefit strongly from LOD because costs multiply across instances. Reducing one character from 70,000 to 12,000 triangles saves 58,000 triangles; across 50 visible characters that is 2.9 million triangles for the relevant pass. Animation evaluation, skinning, and shadows may need their own LOD policies too.

Materials, textures, and shadows#

Geometry is only one part of a level. A distant model that retains six 4096 textures and 14 material primitives may save less than expected. Consider a coordinated material LOD:

reduce image dimensions for streamed distant use;
combine compatible materials;
remove clear-coat or transmission layers when imperceptible;
replace blended detail with masked or opaque approximations;
omit normal-map microdetail below its surviving mip scale;
use a cheaper shadow mesh or disable tiny-object shadows.

Avoid making the transition itself reveal a color or exposure change. Compare both levels under identical lighting and inspect the frame immediately before and after switching.

Shadow LOD may be decoupled from visible LOD. A low-detail shadow caster can be adequate while the camera still sees a higher-detail render mesh. Conversely, a distant recognizable silhouette can need a careful shadow even when its material is simple.

Performance validation#

Do not declare success from triangle reduction alone. Profile a representative scene with realistic instance counts and passes. Capture:

CPU frame and render-submission time;
GPU vertex and fragment time where tools expose them;
drawn triangles and rendered vertices;
draw calls or primitives;
texture and geometry memory;
animation or skinning time;
shadow-pass work;
LOD switches per minute;
download and decode behavior;
image differences at switch boundaries.

If the scene is fragment-bound by a full-screen effect, reducing mesh vertices may not change total frame time. It can still reduce power or create headroom in other views, but make that claim with measurements.

Test the worst useful case, not only an empty demo. Eighty mid-distance trees, a moving camera, shadows, UI, and post-processing reveal different bottlenecks than one tree centered on a desktop GPU.

Common LOD failures#

Thresholds based only on distance. Scaled instances and different camera lenses switch at inconsistent visible sizes.

Every level ships up front. Network and decode work can exceed the geometry saved during rendering.

Origins or bounds differ. The object jumps or chooses a level at the wrong time.

The simplifier removes signature features. Small but recognizable parts need constraints or manual rebuilding.

No hysteresis. Camera noise repeatedly crosses the boundary.

Cross-fade is assumed free. Both meshes render during the overlap, sometimes with expensive transparency.

Only the bind pose is reviewed. Reduced joints collapse in motion.

Materials are ignored. Draw calls, texture memory, and shader cost remain unchanged.

LOD acceptance checklist#

Each level has a measured visual purpose and performance benefit.
Projected-size thresholds are tested at supported resolutions and cameras.
Silhouette, holes, and signature features survive their required ranges.
Origins, scale, materials, and component alignment remain stable.
Hysteresis prevents rapid repeated switching.
Transition behavior is reviewed at realistic camera speeds.
Animated levels pass extreme poses and attachment tests.
Material, texture, shadow, and geometry policies work together.
Initial delivery does not fetch unnecessary levels without justification.
The production scene shows a measurable improvement.
Metrics distinguish CPU, vertex, fragment, memory, and network effects.
Approved captures document both sides of every transition.

Sources and further reading#

LOD works when it is treated as a measured representation system. Build candidates, find the screen-space range where each is sufficient, stabilize the transitions, and verify the full scene. The result is not merely fewer triangles; it is detail spent where the viewer can actually perceive it.