Nanite & Virtualized Geometry

Nanite is virtualized geometry - the same idea as virtual texturing, applied to triangles. A virtual texture system keeps a huge texture on disk and streams only the tiles the camera can see at the resolution it needs. Nanite does that with the mesh itself: your model is preprocessed into a hierarchy of tiny triangle clusters, and each frame the engine picks the clusters and detail level that resolve to about one triangle per pixel on screen. A wall filling the view gets its full density; the same wall thirty metres away is drawn from a coarse cluster, seamlessly, with no visible switch.

The practical consequence is that source triangle count stops being the number you fear. A ten-million-triangle CAD assembly and a one-million-triangle one cost almost the same to draw once both are Nanite, because Nanite renders in proportion to screen pixels, not to how many triangles you fed it. Detail you cannot see is never processed. That is why the Epic demos throw hundreds of millions of triangles at the screen and still hold frame rate - the on-screen triangle budget barely moves.

There is a real cost, just a different one. Nanite meshes carry a base memory and disk footprint (the cluster hierarchy has to live somewhere), and there is a small fixed per-frame overhead to run the Nanite pass at all. For a scene of a few simple boxes, classic meshes can be cheaper. Nanite pays off precisely when geometry is dense - which is exactly the situation archviz imports create.

It is worth pausing on why Nanite lands so squarely on architectural work, because that is what tells you when to reach for it. A model that starts life in Revit, Rhino, SketchUp or 3ds Max and comes across through Datasmith is almost always heavier than a game asset would ever be. CAD and BIM tools tessellate curved surfaces into dense triangle meshes without a second thought - a single moulded cornice, a curved stair balustrade or a NURBS-derived facade panel can carry tens of thousands of triangles each. Multiply that across an entire building and you routinely land in the tens of millions of triangles before you have placed a single light.

Under the old rules that number was a crisis: you would spend a day decimating, retopologizing and building LOD chains just to make the scene open without crawling, and you would lose crisp profiles and clean edges in the process. Nanite inverts the situation. Because it costs in proportion to screen pixels rather than source triangles, that same dense import is no longer a problem to be tamed - it is simply the input. You keep every mullion, every chamfer, every bolt head that the fabricator actually detailed, and the renderer only ever processes the fraction of it the current view can resolve.

The deeper point is about fidelity to the design. Before Nanite, the model you walked through was often a simplified stand-in - a marketing mesh cleaned up for performance - which quietly diverged from the real project. With Nanite you can review the actual construction geometry, at full resolution, and trust that what you are judging is what was drawn. For architecture, where the whole value of a walkthrough is honest decision-making, that is not a minor convenience; it removes a layer of translation between the design and the review.

Before Nanite, keeping a heavy scene interactive meant Levels of Detail - LOD0 through LOD3, each a hand-made or auto-generated lower-poly version of the mesh, swapped in as the object shrinks in the distance. LODs work, but they are labour: you author or generate each level, choose switch distances, and still fight the visible pop when one level snaps to the next. Module 9's next lesson on LODs, draw calls and culling covers that craft in full, because it still matters for everything Nanite does not handle.

For Nanite meshes, that whole apparatus disappears. Nanite is continuous LOD - it does not step between three baked levels, it smoothly dials detail per cluster every frame, so there is effectively no pop and nothing to author. You do not build LOD chains for Nanite geometry; you do not set screen sizes; you do not decimate. The mesh is imported once at full detail and the engine handles the rest.

This is the mindset shift the lesson is really about. The instinct drilled into every archviz artist - reduce the poly count before you import - is often now the wrong move for opaque hard-surface geometry. You keep the detail, enable Nanite, and let the renderer be smart. The skill becomes knowing which meshes to leave dense and which still need the old discipline, not blanket decimation.

Be honest about the boundaries, because switching Nanite on blindly will bite you. Nanite loves opaque, static, hard-surface geometry: building shells, structural steel, furniture, facades, trim, bolts, kit-bashed detail, Megascans rocks and photogrammetry scans. This is the bulk of an architectural import, which is why archviz benefits so much.

The caveats are real and worth memorising. Historically Nanite did not support masked or translucent materials well - the cut-out leaves of a foliage card, glass, water - so thin vegetation and transparent surfaces were left as classic meshes. It does not apply to skeletal or animated meshes (a rigged character, an animated door on a skeletal mesh); those stay conventional. Very thin, alpha-tested foliage was a weak spot, and effects like wind through World Position Offset interact with Nanite carefully. Crucially, support keeps widening with every UE5 release - masked-material and foliage handling have improved substantially since Nanite first shipped - so the honest rule is: know your engine version, and test rather than assume.

The other caveat is that Nanite is not free memory. Converting thousands of tiny, trivial meshes to Nanite can cost more than it saves. Reach for it on the dense stuff; leave the trivial props and any animated or translucent geometry on the classic path.

In practice, enabling Nanite is almost anticlimactic. On any Static Mesh you can right-click in the Content Browser and choose Enable Nanite, or tick Nanite Settings > Enabled in the Static Mesh editor and save. You can do it in bulk: select every mesh in your imported folder, right-click, and enable Nanite across the lot. When importing through Datasmith from Revit, Rhino, SketchUp or 3ds Max, recent workflows let you have qualifying meshes marked for Nanite on import, so the dense building shell arrives ready.

A sane workflow for a heavy import: bring the model in with Datasmith; select the opaque structural and furniture meshes and enable Nanite on them; leave foliage, glass and anything animated as classic meshes with LODs; then verify. The verification step matters - use the viewport Nanite visualization modes (the View Mode menu has a Nanite section, including a triangle and cluster overview) to confirm which meshes are actually running as Nanite and to watch the on-screen triangle density. If a mesh silently fell back to classic rendering (because its material or type disqualified it), these modes show you.

The pay-off is concrete: a Revit import that would once have needed a day of decimation and LOD work becomes usable in minutes, at full detail. You spend the reclaimed time on light and materials - the things that actually sell the space - instead of on polygon janitorial work.