Organizing & Updating Imported Scenes

The Content Browser is your project's file system, and an archviz scene fills it fast - imported meshes, materials, textures, Blueprints, lighting, levels. Without a structure it becomes an unnavigable dump; with one, everything is findable in seconds and, crucially, updates cleanly.

Adopt a top-level project folder with a leading underscore - _Project/ - so it sorts to the top, above the engine and plugin content you should never touch. Inside, mirror the shape of the work: Datasmith/ for raw imports, Maps/ for levels and sublevels, Materials/, Meshes/, Blueprints/, Lighting/. Keep imported Datasmith content in its own folder so it stays quarantined from the assets you author by hand - this separation is what lets you re-import without trampling your own work. The Content Browser figure lays this out.

Pair the folders with a naming convention, the same one professional teams and Epic's own guidelines use: prefix assets by type - SM_ for a static mesh, M_ for a material, MI_ for a material instance, T_ for a texture, BP_ for a Blueprint. So SM_Wall_Ext_Brick is unmistakably a mesh, sorts next to its siblings, and filters instantly. A good name also reads left-to-right from general to specific - SM_Door_Ext_Timber_01 - so related assets cluster together alphabetically. Consistent prefixes are not pedantry; they make search predictable, make a team legible to itself, and - most importantly here - make a re-import merge behave, because Datasmith matches by name. A scene named Object17, Object18 is a scene that breaks on every update.

A discipline that saves real grief is separating what Datasmith owns from what you own. Everything inside Datasmith/ is the engine's to overwrite on the next sync; everything in your Materials/, Blueprints/ and Lighting/ folders is yours, and Datasmith will not touch it. Author your material instances, master materials, lighting rigs and Blueprints in your folders and reference the imported meshes, rather than editing the imported assets in place. That single boundary - imports over here, your work over there - is what turns the next re-import from a nervous gamble into a routine click, and it is worth enforcing from the very first day of the project.

A whole building in one monolithic level becomes slow to open, slow to save, and impossible for two people to work on at once. Unreal's answer is levels and sublevels (level streaming, and in UE5 the newer World Partition for large worlds): you split the scene into a persistent level plus named sublevels that can be shown, hidden, locked and loaded independently.

For architecture the natural cuts are obvious. Split by discipline or system - a Shell sublevel (structure, envelope), an Interiors sublevel (furniture, finishes), a Site/Landscape sublevel, a Lighting sublevel. Or split by floor in a tall building, or by zone in a large plan. Now you can work on the interiors without loading the whole site, hide the shell to see the structure, lock a colleague's sublevel so you do not clash, and stream distant floors out to save performance. It also lets a team divide honestly: one person on lighting, another on interiors, in different sublevels of the same project.

There is a direct tie to updating. Keep your imported Datasmith geometry in its own sublevel (or clearly its own folders), separate from the hand-authored lighting, dressing and Blueprints. Then when the architect reissues the model, the re-import touches only the geometry sublevel, and everything you built in the other levels sits safely untouched. Organisation and update-ability are the same discipline seen from two angles: a scene cut into sensible, well-named pieces is a scene you can update surgically instead of wholesale.

Sublevels also change how the scene performs and how it saves. A monolithic level must be fully loaded and fully re-saved every time, which grows painful past a certain size and invites merge conflicts on a team; streamed sublevels load only what is needed and let Unreal cull whole zones that are out of view. For a large scheme - a tower, a campus, a masterplan - UE5's World Partition takes this further, automatically dividing a vast world into a grid that streams around the camera so you are never holding the entire model in memory at once. You do not need World Partition for a single house, but knowing the spectrum - one level for a room, sublevels for a building, World Partition for a district - lets you match the structure to the job rather than forcing everything into one heavy map.

Now the heart of the lesson: keeping the scene current as the design changes, without losing your work. Datasmith is built for exactly this, and it offers the same two routes as import.

Re-import from an updated file. You re-export a fresh .udatasmith and, on the Datasmith Scene asset in Unreal, choose Reimport. Datasmith does not blindly wipe and rebuild - it performs a diff and merge: it detects which elements are new, changed or deleted, updates the geometry accordingly, and tries to preserve the overrides you added in Unreal - your reassigned materials, your adjusted transforms, your lighting. Direct Link Sync. With a live link established, you simply press Sync and the current model state flows in through the same merge logic, no file step at all. This is the closest thing to a living link between the design model and the immersive scene - the architect edits Revit, you sync, and the change is standing in your lit walkthrough moments later, with your materials intact. The Direct Link figure shows this two-way rhythm.

The merge is powerful but conditional, and the condition is stable names. Datasmith matches old to new by identity, so if you rename imported actors or materials in Unreal, or if the source app reshuffles element IDs, the link loses track and your overrides can detach - the update reverts your careful material work. The rules that keep the link alive: do not rename imported Datasmith assets (rename your own authored assets freely, but leave imports as they came); apply material and lighting changes in a way Datasmith can reapply; keep the source model's structure and naming stable; and re-import rather than re-importing-as-new. Follow them and updates are genuinely a two-minute Sync. Break them and you are rebuilding.

Tie it into a way of working that holds up across a real project's endless revisions.

Set up once, up front. Before you dress or light anything, build the _Project/ folder structure, decide your naming prefixes, cut your sublevels, and quarantine the Datasmith import in its own folder and sublevel. Ten minutes here is repaid on every future update. Layer your work in the right place. Author materials, lighting, foliage, cameras and Blueprints in your folders and sublevels, referencing the imported meshes rather than editing the imports themselves - so your work lives beside the import, not tangled into it. Update through the link, never by hand-rebuilding. When the design changes, re-import or Sync; let Datasmith merge the geometry; then spot-check that your overrides survived and touch up only what genuinely moved. Version the milestones. Keep dated .udatasmith exports (or source-control your project) so you can roll back, and freeze a final file export for delivery even if you used Direct Link during design.

The reward is a scene that is a living representation of the BIM model, not a fragile one-off. This is what makes real-time viable in real practice, where nothing holds still: the model and the immersive experience stay coupled, updates cost minutes not days, and the walkthrough or VR review you show the client next month reflects the design as it is now. That durability - built entirely from folder discipline, naming, sublevels and a well-tended Datasmith link - is the quiet professional skill that turns a one-time demo into a tool the practice actually runs on. It also sets up everything ahead: materials (Module 3), lighting (Module 4) and interactivity (Module 7) all layer onto this organised, updatable foundation.