Nanite is virtualised geometry; Lumen is dynamic global illumination. Together they remove two of the oldest constraints in real-time art — and introduce new ones people are still learning.
What Nanite changes
It streams and renders geometry at a density matched to screen resolution, so a mesh with millions of triangles costs roughly what its screen coverage costs rather than what its triangle count costs. In practice: LODs become largely unnecessary for Nanite meshes, and high-poly source assets can ship directly.
What Nanite does not do
- Skeletal meshes. Support has been arriving but the classic path — animated characters need conventional LODs — still governs most projects.
- Translucency. Nanite is opaque-first. Glass, foliage with alpha, particles all remain conventional.
- Small instanced props. Overhead per Nanite mesh means very small, very numerous objects can be worse, not better.
- Draw calls and materials. Nanite reduces geometry cost, not material cost. A scene with hundreds of unique materials is still slow.
What Lumen changes
Bounced light without baking. That removes lightmap UVs and bake times from the workflow, which is a large practical saving — and it means lighting can change at runtime.
What Lumen costs
It is expensive, scales with resolution, and its quality settings are a real dial rather than a formality. Projects targeting lower-end hardware often still bake. And software Lumen (no ray tracing hardware) behaves differently from hardware Lumen — testing on both matters if you ship to both.
For generated assets
Nanite genuinely reduces the pressure to retopologise for static props: a dense reconstructed mesh can go in largely as-is. That is a real workflow change.
It does not remove the need for clean UVs, sensible materials, or correct scale — and the moment an asset needs to deform, the conventional pipeline returns in full.