Nanite is not always the answer
Short answer: Nanite is excellent when the problem is rendering a small number of very detailed, mostly rigid meshes. It is not a blanket replacement for LODs, instancing discipline or runtime measurement. Every visible instance still has work, world position offset changes the case, and the triangle number exposed for a Nanite mesh is commonly its fallback mesh—not the geometry Nanite actually streams and rasterises.
What Nanite is good at
Nanite breaks source geometry into clusters, streams the detail needed for the current view and rejects clusters that do not contribute. That makes it a strong fit for high-detail environment meshes, scanned assets and rigid props where hand-authoring several conventional LODs would otherwise dominate the content workflow.
It does not mean source triangle count has become irrelevant. Disk size, import time, build time, fallback data and material cost still exist. It means Nanite has a different mechanism for choosing and drawing visible geometry at runtime.
There is still fixed work per instance
Nanite reduces geometry detail; it does not erase actor, component, visibility and instance-management costs. Each visible instance must be represented, culled and placed before its clusters can be considered. Thousands of tiny Nanite props can therefore be limited by per-instance work even when each prop contributes very few visible triangles.
The exact crossover depends on engine version, hardware, scene structure and materials. Do not infer it from one asset in the Static Mesh Editor. Compare a representative population in the level and watch both the GPU and render thread.
World position offset changes the decision
World position offset moves vertices after their stored positions have been built into the asset. Nanite support for WPO has changed across UE5 releases and includes limits, but support is not the same as a free path. Continuous deformation makes bounds and cluster work harder to predict and can increase work substantially.
Wind-driven foliage is the common trap. Leaves and branches may be individually detailed, but the scene also contains many instances, masked material cost and continuous WPO. That combination can make Nanite the wrong default. Conventional foliage LODs, impostors or a different wind setup may be better. There is no reliable answer without testing the actual population and camera path.
The Triangles tag is the fallback count
When a tool reads the ordinary triangle-count metadata from a Nanite-enabled static mesh, the number it receives is generally the fallback mesh count. The fallback exists for rendering paths and platforms that cannot use Nanite and for several engine systems that need conventional geometry. It is not the count of triangles Nanite will rasterise for a frame.
This matters in both directions. A low fallback count does not prove the Nanite asset is cheap, and a high source count does not prove the visible frame is expensive. A scanner that ranks Nanite meshes by the ordinary Triangles tag without labelling it as fallback data is ranking the wrong number. Framegain treats that distinction explicitly rather than presenting a false runtime triangle total.
Use Nanite's own views
r.Nanite.Visualize.Overview 1 r.Nanite.Visualize.Overdraw 1 stat gpu profilegpu
The visualisations help explain cluster visibility and overdraw. They still need context: target hardware, a realistic camera, representative instance counts and the materials you intend to ship.
A decision that survives measurement
- Use Nanite as a strong candidate for rigid, high-detail geometry.
- Question it for very small repeated props where instance count dominates.
- Test WPO foliage as a population, not as one mesh in isolation.
- Keep the fallback mesh appropriate for the systems and platforms that use it.
- Compare frame time and visual result before and after. The checkbox is not the result.