Geometry Cleanup & Tessellation

Your CAD and BIM tools describe form in two broad ways. NURBS modellers like Rhino store surfaces as exact mathematical descriptions - a curve is an equation, infinitely smooth at any zoom. BIM tools like Revit mix precise solids with procedural families. Real-time engines store and draw neither; they draw polygon meshes made of triangles. Tessellation is the conversion: approximating a smooth surface with enough flat triangles that the eye reads it as curved.

The key insight is that tessellation is a trade, and you control the dial. Dice a curve into a handful of segments and it renders fast but visibly faceted - you see the flats. Dice it into hundreds and it looks perfectly smooth but carries a heavy triangle load. Neither extreme is right; the sweet spot depends on how close the camera gets and how curved the surface is. The tessellation figure shows the same arc as true NURBS, as a coarse low-poly chain, and as a fine high-poly chain - same shape, wildly different triangle counts.

Datasmith and the CAD importer expose this through tessellation settings, usually as chord tolerance (how far the flat triangle may deviate from the true surface, in millimetres) and angle/normal tolerance (how many degrees the surface may turn before a new triangle is forced). Tighter tolerances mean more triangles and smoother results. As a feel for numbers: a chord tolerance around 0.1mm is extremely fine (reserve it for surfaces the camera pushes right up to), something in the 0.2-0.5mm range suits most hero architectural curves, and a looser value is plenty for background geometry. Angle tolerance works alongside it - a smaller angle catches tight curvature that a chord value alone would miss. The professional habit is to tessellate for the viewing distance: generous triangles on the hero curved facade the camera caresses, few on the distant curved railing nobody inspects.

There is a subtlety worth internalising: tessellation and the smoothness you see are two different things. Even a moderately faceted mesh can read as smooth if its normals are shaded smoothly (interpolated across the flats) rather than flat-shaded - the silhouette will still show facets, but the surface across the middle looks curved. So the honest rule is: tessellate enough that the outline of a curved form reads clean at its viewing distance, and let smooth normals do the rest. You can always re-import a surface with different settings if it facets in shot, so start moderate and tighten only where the camera demands it rather than cranking everything to maximum and drowning in triangles.

Every triangle costs something to draw, and real-time lives inside a hard frame budget - roughly 16ms per frame at 60fps, and tighter still for VR's ~90fps. So polycount (the triangle count in view) is a currency you spend deliberately. Blow the budget and the scene stutters; VR, which renders the world twice (once per eye), punishes it hardest of all.

Where does the budget go wrong? Almost always in over-tessellated small stuff. A single fully-modelled door handle with threaded screws can carry more triangles than an entire wall. Imported trees, ornate railings, bolts, pipes and duplicated furniture quietly balloon the count. The polycount figure sketches a rough interior budget - comfortable under a couple of million triangles in view, watchful into the mid-single-millions, and trouble beyond without help. Treat those as feel, not law; they move with your hardware.

Two forces relieve this. First, discipline: tessellate sensibly, delete unseen geometry, reuse (instance) repeated objects rather than duplicating unique copies, and use LODs - lower-detail versions of a mesh that swap in with distance (Module 9). Instancing deserves a moment: if your scene has two hundred identical chairs, importing them as two hundred unique meshes is far heavier than referencing one mesh two hundred times, both in memory and in draw calls (the per-object cost of telling the GPU to render something). Repeated architectural elements - balusters, mullions, pavers, light fittings - are exactly where instancing rescues a scene, so prefer components and blocks in the source app that Datasmith can bring across as instances.

Second, Nanite, Unreal Engine 5's virtualized geometry system, which streams and renders enormous triangle counts efficiently and dramatically relaxes the old polycount ceiling for opaque, rigid meshes. Nanite is genuinely transformative - a Nanite-enabled CAD import that would once have crippled the viewport can now spin smoothly - but it is not a licence to be careless: it has limits (it historically did not cover translucency, foliage or skinned meshes cleanly), it costs some memory and disk, and clean, sensibly built geometry still profiles better and behaves better in every case. Budget first; lean on Nanite second.

Beyond tessellation, four artifacts recur in almost every architectural import. Learn to spot and fix each.

Flipped normals. A face's normal is the direction it considers 'out'. If it points the wrong way, the surface renders dark, invisible or inside-out - the Unreal cousin of SketchUp's reversed faces. Fixes: correct it at the source, flip normals in Unreal, or as a quick patch assign a two-sided (double-sided) material so the face draws from both sides (at a small cost). Coplanar faces / z-fighting. When two surfaces occupy the exact same plane - a rug laid dead-flush on a floor, a decal coincident with a wall - the engine cannot decide which is in front and they flicker as the camera moves. This z-fighting is fixed by nudging one surface a few millimetres off the other so there is a clear winner.

Wrong pivots (origins). Datasmith often sets a mesh's pivot at the world origin or bounding-box centre, not where you would want to grab it. A door that should rotate about its hinge instead spins about its middle; a lamp you want to place by its base lifts off by its centre. Set pivots meaningfully - especially for anything you will move, rotate or make interactive with Blueprints in Module 7. Missing or wrong collision. Imported meshes may arrive with no collision, so in a walkthrough you fall through floors and walk through walls, or with auto-collision so crude it blocks doorways. Add appropriate collision - simple box or convex hulls for most architecture, and 'use complex as simple' sparingly for genuinely intricate shapes - so people can actually navigate the space. None of these are hard; they are just the standard tidy-up list every import needs.

Put it together into a pass you run on every fresh import, ideally in this order.

One - triangulate the scale of the problem. Turn on the viewport's triangle statistics and wireframe view to see where the polycount actually lives; the offenders are usually obvious and few. Two - retessellate the heavy curved offenders by re-importing them with looser tolerances, or replace an over-detailed imported prop (that threaded handle) with a lighter version. Three - sweep for dark and inside-out surfaces, fixing normals at the source where you can, or applying two-sided materials as a stopgap. Four - hunt z-fighting by orbiting the camera and watching for flicker on floors, rugs, signage and stacked panels; nudge the loser off the shared plane. Five - set pivots on anything you will place, array or animate, and add collision to floors, walls and stairs so the space is walkable.

A note on tooling: Unreal ships a Datasmith / geometry cleanup toolkit and the broader modelling tools that let you do much of this in-engine - retessellate, weld, fix normals, set pivots, generate collision and simplify meshes - without a round-trip to the source app. For deep structural fixes, still prefer the source; for import tidy-up, the in-engine tools are fast. Either way, the goal is the same: hand the next stages of the pipeline - materials, lighting, interactivity, VR - geometry that is smooth where it should be, light enough to stay interactive, correctly lit, flicker-free, sensibly pivoted and walkable. Get the geometry right and everything downstream gets easier.