Preparing Revit, Rhino & SketchUp Models

It is tempting to import first and clean up in Unreal, but that is backwards. Your source application is where the semantic tools live: Revit knows what a wall is, SketchUp knows what a group is, Rhino knows what a layer holds. Once geometry crosses into Unreal it is just meshes and actors - you have lost the parametric and organisational handles that make cleanup fast. Reversing a hundred faces is trivial in SketchUp and miserable in Unreal.

So adopt one rule: prepare in the source, refine in Unreal. Cleanup and organisation happen before export; lighting, materials, interactivity and polish happen after. The two figures in this lesson make the contrast concrete - a messy source produces a bloated, broken import no matter how good your engine skills are, because Datasmith mirrors the mess.

There is a second reason. Real-time has a hard performance ceiling that offline rendering does not - you are chasing 60fps on desktop and ~90fps in VR, and every unnecessary triangle, every hidden object, every duplicated component eats into that budget. A clean model is not just tidier; it is lighter, and lightness is what keeps a heavy building walkable. Preparation is your first and cheapest optimisation pass, long before you reach the profiling tools of Module 9.

There is a third reason that people discover the hard way: you will import the same model many times. A real project is not one import - the design changes, the model is reissued, and you re-import or sync again and again (lesson 2.4). Every bit of mess you leave in the source is mess you re-import on every revision, and every good name you set is a name that keeps paying off. So preparation is not a one-time tax; it is an investment that compounds across the life of the project. The ten minutes you spend now is multiplied by every future update - which is exactly why disciplined teams treat source hygiene as non-negotiable rather than optional polish.

Some preparation applies whatever you model in. Run this checklist before every export.

Purge the unused. Every design tool accumulates junk - unused families, components, materials, layers and definitions that bloat the file. Revit has Purge Unused; SketchUp has Purge under model info / statistics; Rhino has the Purge command. Run it - and run it more than once, because purging can free up dependencies that a second pass then removes. Delete or hide what the camera will never see. Interior guts of an object, the far side of a site, mechanical systems inside walls - if it is not seen, it should not be exported. Remember Datasmith exports what is visible, so hiding is genuinely deleting-for-export without losing your model.

Name things like a human. Object17, Layer0 and Group#452 become folders and actors in Unreal that you then cannot find. Rename key layers, groups and materials to meaningful names - Ext_Wall_Brick, Glass_Curtain, Floor_Timber - and future-you, hunting for one surface in a 400-actor scene, will be grateful. Consolidate materials. If three near-identical greys exist, merge them to one; each unique source material becomes a unique Unreal material to manage. Set real-world scale and units. Confirm the model is at true size in real units before export, so it arrives correctly scaled and your camera, lighting and eventually VR all read as life-size. Do these five - purge, hide, name, consolidate, scale - every single time, and imports get dramatically calmer.

Each application has its own characteristic problems worth pre-empting.

Revit tends to over-deliver. A federated model may carry every consultant's system, dozens of design options and worksets, and huge families full of hidden detail. Before export: use a dedicated 3D view with only the disciplines and worksets you want visible; set that view's detail level and turn off the fine annotation and analytical categories you do not need; turn off links you do not need; and be wary of ultra-detailed families (a fully modelled door handle with threads) that explode your polycount. A tip that saves headaches: keep a dedicated 'Datasmith export' 3D view in the Revit file, configured once, so every re-export sends exactly the same curated set rather than whatever happened to be on screen. Revit materials map reasonably, but plan to refine hero surfaces in Unreal.

Rhino is a NURBS modeller, and this is the big one: Unreal cannot draw NURBS, only polygons, so every smooth surface must be tessellated into a mesh on the way in. You control how finely via the mesh/tessellation settings - too coarse and curved surfaces facet visibly; too fine and the polycount balloons. Set a sensible density for the viewing distance, keep layers clean, and watch for tiny sliver surfaces and open edges. (Lesson 2.3 goes deep on tessellation.)

SketchUp is fast and loose, which is its charm and its trap. Two issues dominate. First, reversed faces: SketchUp faces have a front (white) and back (blue-grey), and a back face pointing outward may render dark, culled or full of holes in Unreal - reverse them before export (the figure shows exactly this). Second, organisation: raw loose geometry imports as a chaotic blob, so wrap things in named groups and components so they arrive as sensible, findable actors. Components have a bonus: SketchUp components map naturally to Unreal instances, so a row of identical windows built as one component imports lighter than the same row drawn as loose copies. Also purge unused components, which SketchUp hoards enthusiastically.

A cross-cutting point on materials for all three tools: assign materials in the source rather than leaving raw untextured faces, because a face with no material imports with a default you then have to hunt down and reassign. It is far quicker to give even a rough material in Revit, Rhino or SketchUp - the right base colour on the right surfaces - so Datasmith brings across a clean set of named materials you can upgrade to full PBR in Module 3. Untextured geometry is not just ugly on import; it is untraceable, because you cannot select-by-material something that has no material.

Turn all of the above into a routine you run in two or three minutes before every export. Print it, tape it to your monitor, and it becomes muscle memory.

Purge unused families, components, materials and layers. Isolate the view: hide everything the camera will not see - other disciplines, interior guts, distant site, construction junk. Name your key layers, groups and materials meaningfully; kill the Object17 names. Orient faces correctly (SketchUp especially) - no reversed faces pointing out. Tessellate sensibly if you are in Rhino or another NURBS tool - set mesh density for the viewing distance. Scale to real-world units and confirm true size. Consolidate duplicate materials down to one each. Then, and only then, run the Datasmith exporter.

A quick word on where to draw the line. Preparation is not the same as optimisation for its own sake - you are not trying to build the leanest possible model, you are trying to send a clean, honest, well-labelled one. Do not spend an hour hand-reducing a mesh that Nanite will happily swallow, and do not agonise over a distant object nobody will inspect. The pre-flight is about removing genuine junk, fixing genuine errors and labelling things clearly, not about chasing an ideal polycount - that tuning happens later, in Unreal, where you can actually see the frame rate. Match the effort to what the camera and the frame budget will notice.

Here is the payoff, stated plainly. A prepared model imports as a light, well-organised, correctly oriented, sanely named scene that you can start lighting and dressing immediately. An unprepared one imports as a heavy, dark-faced, cryptically named tangle that you fight for an hour before any real work begins - and that you re-fight every time the design updates and you re-import. Preparation is not busywork; it is the difference between real-time archviz feeling effortless and feeling cursed. Do it once, do it every time, and the rest of this course gets easier.