Level of Detail, usually shortened to LOD, is one of the most important tools for keeping real-time scenes performant without sacrificing close-up quality. Instead of rendering a single mesh at all distances, engines switch between multiple versions of the same asset depending on distance or screen coverage.
That means the “low poly vs high poly” discussion is incomplete without LODs. A detailed LOD0 can be totally fine in real-time if the asset has sensible lower LODs. A low poly asset can still become expensive if it is reused widely, visible at many distances and lacks an LOD chain.
What an LOD system does
An LOD system swaps an asset’s representation based on distance or screen size:
- LOD0: highest detail for close range
- LOD1: reduced geometry, often keeps silhouette
- LOD2+: aggressive simplification for distance
The goal is stable performance at scale, especially in large scenes and modular environments where the same assets appear at many distances simultaneously.
Why LODs matter more than the base triangle count
Triangle count is easy to compare, but it only describes one LOD level. In practice, what matters is the total cost across the scene:
- how often the asset is reused
- how far it is visible
- how heavy the materials are
- whether distant instances are automatically cheaper due to LODs
Good LODs reduce vertex cost and often allow you to simplify materials at distance, which can matter as much as geometry.
Manual LODs vs automatic LODs
Manual LODs
Manual LODs are authored by artists. They usually produce the best results because the reduction is intentional: silhouette preserved, shading stable, and details removed where they do not contribute.
Use manual LODs for:
- frequently reused props
- modular environment pieces
- assets with strong silhouettes
Automatic LODs
Automatic LOD tools reduce geometry algorithmically. They are useful at scale but must be reviewed because they can:
- destroy silhouettes
- create shading artifacts
- collapse important shapes
Many pipelines use a hybrid approach: manual LODs for core assets, automatic LODs for background objects.
LOD transitions and visual stability
Bad LODs are noticeable even when triangle counts look “good”. Common causes of visible popping:
- silhouette changes that are too aggressive between LOD levels
- shading differences from broken normals or smoothing
- UV and normal-map inconsistencies
- material changes that are too abrupt
A practical rule is that LOD1 should usually preserve the silhouette, and more aggressive reductions should happen later in the chain.
Engine conventions and naming that actually work
This is where accuracy matters most, because naming and hierarchy expectations differ by engine.
Unity LOD naming and setup
Unity can auto-detect LOD meshes in an imported model when they follow a naming convention like:
- ExampleMeshName_LOD0
- ExampleMeshName_LOD1
- ExampleMeshName_LOD2
Unity can then automatically create an LOD Group when it recognizes the grouped meshes and naming.
Practical Unity expectations:
- consistent pivots across LOD meshes
- matching transforms
- stable shading across levels
LOD Group controls thresholds by screen coverage, not distance
CryEngine 5 LOD naming and hierarchy
For Cryengine 5’s FBX pipeline, the current documented approach is:
- Use the $ symbol to force a mesh element to be treated as an LOD
- Naming structure: $lod#_meshname, where # is the LOD number and meshname matches the parent (LOD0) mesh name
- LOD0 remains the parent and keeps the original asset name
- LODs are parented under LOD0, together with $proxy in the hierarchy
Important detail about proxy handling in this game engine:
- physics proxies are taken from LOD0, and successive LODs reuse that proxy
So the corrected Cryengine guidance is:
- $lod1_meshname, $lod2_meshname, …
- plus $proxy under the same parent hierarchy.
More info about that can be found on Cryengine website under this link.
Unigine LOD naming by postfixes
Unigine supports assigning LODs automatically using name postfixes when preparing LODs in a DCC tool. One documented example format is:
- _lod_0, _lod_1, _lod_2, …
Unigine also supports auto-generated LODs via import settings (useful when processing large libraries).
Godot Engine LOD Handling
Godot does not rely on fixed naming conventions for LOD detection in the same way some engines do. Instead, LOD behavior is typically implemented explicitly at the scene level.
In Godot 4, a common approach is to import each LOD as a separate mesh and control visibility using visibility ranges on MeshInstance3D nodes. Each LOD mesh represents a different complexity level of the same asset and shares the same transform and pivot.
Typical preparation for Godot LODs includes:
- Exporting multiple LOD meshes from the DCC tool (often via glTF)
- Ensuring identical pivots, scale and orientation across LODs
- Using consistent materials to avoid shading changes
- Assigning visibility ranges so only one LOD is visible at a given distance
Unlike Unity or Cryengine, Godot does not require specific suffixes such as _LOD1 or $lod1_. Correct behaviour depends on scene structure and visibility settings, not naming.
Godot 4 also supports automatic LOD generation on import, but this is generally used for prototyping or background assets. Manually authored LODs are preferred when silhouette stability and predictable transitions are important.
Because LOD switching is explicit, assets prepared for Godot benefit from clean hierarchy, consistent transforms and well-planned reduction steps rather than engine-specific naming rules.
Material simplification across LODs
LOD optimization is not geometry-only. Distant LODs often benefit from simpler materials:
- fewer texture samplers
- lower-res textures
- dropping normal maps at far LODs
- simpler shading features
If you only reduce triangles but keep expensive materials, you often get disappointing real performance gains.
What to check when buying or evaluating assets with LODs
When an asset claims to include LODs, validate:
- LOD chain exists and is clearly structured
- silhouette reduction is sensible (especially LOD0 ⇒ LOD1)
- shading stays stable across transitions
- pivots and transforms match
- proxy or collision approach is consistent with the engine
LOD workflows are the practical answer to scaling real-time scenes without constantly fighting performance. The best assets are not the ones with the lowest polygon count, but the ones with a coherent LOD strategy that preserves visuals where it matters and gets cheaper when it does not.
Related reading:
If you haven’t read these yet here are some more post we got for you that can solidify your game assets creation knowledge.