Skip to content

Nanite virtualised geometry

What it is

Nanite is UE5's virtualised geometry system. It stores meshes as hierarchical clusters of triangle groups in a compressed internal format, streams only the visible clusters on demand, and renders them in a dedicated pass that bypasses traditional draw calls entirely. The LOD selection is automatic and continuous — clusters swap at the pixel scale based on the camera view, with no visible cracks between adjacent clusters.

Key properties of the format: - Data is highly compressed; Nanite meshes typically occupy less memory and disk space than their equivalent traditionally-rendered counterparts. - Streaming is on-demand from disk, so only the detail that is actually visible needs to reside in memory at any given frame. Use an SSD for runtime storage to avoid streaming stalls. - Per-vertex tangents are not stored; tangent space is derived implicitly in the pixel shader to reduce data size. This can cause edge discontinuities in rare cases; Epic plans to add explicit tangent storage in a future release. - Virtual textures are not required but are strongly recommended — they solve the same streaming problem for texture data that Nanite solves for mesh data.

When to use it

Enable Nanite wherever the platform supports it. Any mesh that has it enabled will typically render faster and use less memory. A mesh is an especially strong candidate when it:

Condition Why Nanite helps
High triangle count, or triangles small on screen Clusters are culled to pixel scale; excess triangles never reach the rasteriser
Many instances in the scene Nanite's own draw-call-free pass scales better than traditional instanced draws
Acts as a major occluder of other Nanite geometry Nanite occlusion culls at the cluster level
Casts shadows via Virtual Shadow Maps VSMs share the Nanite cluster pipeline; shadow geometry is also streamed efficiently

Exceptions exist (e.g. a sky sphere — large on-screen triangles, no occlusion value, single instance) but are rare, and the performance cost of incorrectly enabling Nanite on them is usually small. Don't over-engineer the exclusion list.

Some use cases are not supported; check the Costs & gotchas section below.

Costs & gotchas

Hard instance ceiling. The scene-wide maximum is 16 million instances across all streamed-in content (not just Nanite-enabled meshes). This includes foliage and instanced components. Profile instance counts in large open worlds.

World Position Offset (WPO) displacement is bounded. Nanite splits WPO meshes into smaller clusters, each with its own bounds, and culls them individually on the GPU. You must clamp the displacement amount to the bound you declare — exceeding the declared bound causes culling artefacts. If you use WPO on a Nanite mesh, set the Preserve Area displacement bound carefully in the material.

Deformation is limited. Nanite supports dynamic translation, rotation, and non-uniform scaling (anything expressible as a 4×3 matrix applied uniformly to the whole mesh). Anything more complex than that requires WPO and the bound caveats above.

No tangent storage. The implicit per-pixel tangent derivation is usually invisible, but can produce edge artefacts on low-curvature geometry with strong normal detail.

Import time increases significantly with Build Nanite checked on dense meshes, and an additional UV channel is generated for Lightmap UVs unless you disable Generate Lightmap UVs. If your project uses dynamic GI (Lumen) and not Lightmass, disable lightmap UV generation to avoid the cost.

Processing requires DDC. Nanite mesh compilation is expensive; on large teams use a shared Derived Data Cache to avoid re-cooking the same assets across machines.

Plays well with

  • Lumen GI and reflections — Nanite static meshes have full Lumen support.
  • Virtual Shadow Maps (VSMs) — VSMs are the recommended shadow method for Nanite scenes; the two systems share the same cluster-level visibility pipeline.
  • Instanced / Hierarchical Instanced Static Meshes, Foliage Painter, Landscape Grass — all are valid Nanite component types.
  • Nanite Foliage — a dedicated subsystem combining Nanite rendering with skinned meshes, voxelisation, and animation for large-scale foliage; see the dedicated foliage documentation.
  • Landscapes — Nanite can be enabled on landscape terrain, especially beneficial alongside Virtual Shadow Maps.
  • Spline meshes — Nanite-enabled meshes support both Landscape Splines and Blueprint Splines by default.

Avoid when

  • The mesh's triangles are large on screen relative to pixel density, there is only one instance, and it does not occlude anything (e.g. sky sphere). Nanite overhead is minimal but non-zero in these cases.
  • The platform does not support Nanite — check target hardware before enabling project-wide.

Settings that matter

Setting / workflow Where Notes
Build Nanite Import dialog Enables Nanite compilation at import time. Disable Generate Lightmap UVs alongside this if you're not using Lightmass.
Enable Nanite Support Static Mesh Editor → Nanite Settings Toggles Nanite on an individual static or skeletal mesh.
Enable Nanite Geometry Collections Editor → Nanite section Equivalent toggle for geometry collections (Chaos Fracture).
Batch enable Content Browser → right-click selection → Nanite > Enable Fastest way to upgrade an existing project's assets in bulk.

Optimisation

  • Profile instance counts against the 16 million hard ceiling using the Nanite visualisation modes (NaniteStats and the viewport visualisation overlays).
  • For WPO meshes, keep the declared displacement bound as tight as possible — oversized bounds defeat cluster-level culling and increase GPU work.
  • Treat high-poly film-quality source assets (ZBrush sculpts, photogrammetry) as first-class Nanite inputs rather than baking detail into normal maps. The baked-normal workflow can still help for low-geometry-count setups, but Nanite removes that constraint for dense assets.
  • Nanite Static Displacement Mapping (offline adaptive tessellator) and Nanite Tessellation (runtime programmable displacement) are separate features with different cost profiles; choose static displacement for authored detail that doesn't need to animate, and tessellation for material-driven or animated displacement.
  • Foliage and open-world scenes: enable Nanite Foliage rather than raw Nanite instances where wind animation and LOD-based animation banks are needed — it is architecturally designed for that scale.

Faceted meshes and poor vertex reuse

Faceted meshes and poor vertex reuse

Faceted or hard-surface meshes — where every face has split normals and therefore unshared vertices — produce poor triangle-to-vertex ratios in Nanite. The worst case is 1 triangle per 3 vertices (no vertex sharing at all). This cascades across multiple systems:

Affected system Cost mechanism
Nanite visbuffer (GPU) Cluster overhead grows because clusters contain fewer usable triangles
Nanite streaming (memory) Poor detail streaming; large memory footprint from the inflated cluster count
Fallback mesh simplification Simplification quality degrades, producing a bloated fallback mesh
Lumen tracing Bloated fallback mesh inflates the Lumen tracing geometry cost
Physics Large physics body is built from the fallback mesh; body creation stalls level streaming
Disk Both Nanite data and physics body data are larger than they need to be

The root cause is seam placement in the DCC tool. Edges marked as seams (for UV unwrapping) force vertex splits, and over-seamed assets carry far more splits than the geometry actually requires.

Fixing in Blender

Select the problematic edges, then use Remove Seam to clear incorrectly marked seams. This reduces vertex splits, restores vertex sharing, and improves the triangle-to-vertex ratio before re-export.

FBX export note (Blender): disable Enable Nanite on the Static Mesh asset in UE before re-exporting from Blender, or UE will export the fallback mesh rather than the original source data. You need the original source data to meaningfully fix vertex sharing.

Fixing assets individually is expensive at scale. Enforce a high import standard upstream — catching over-seamed assets at the point of authoring is cheaper than triaging them after they cause in-game performance problems.

Scalability and r.Nanite.MaxPixelsPerEdge

r.Nanite.MaxPixelsPerEdge (default 1) controls the maximum screen-space edge length Nanite targets when selecting cluster detail. Raising the value reduces GPU cost at the expense of geometric detail.

This CVar can be exposed to the scalability system to reduce Nanite detail dynamically at lower quality tiers (e.g. Medium view-distance scalability). Epic's own Scalability settings do not wire this up by default; consider adding a dedicated MeshDetail scalability group to your Scalability.ini rather than reusing ViewDistance, which carries other consequences.

Profile with stat gpu to confirm GPU savings after either a mesh fix or a r.Nanite.MaxPixelsPerEdge change before committing to either approach.

Note: the official Epic documentation page "Faceted and Hard-edge Normals" covering this topic appears to have been moved or removed as of the UE 5.7 documentation revision.

— source

— source