What is in your .blend after a dress

What arrives in the scene

A dress imports two files out of your project folder. outputs.usd becomes geometry. outputs.csv becomes one point cloud per source object, with every column of the file kept as a point attribute. The linker then renames what arrived, files it, surfaces it and populates it.

Everything it leaves behind is an ordinary Blender object. Meshes with vertices, materials with Principled BSDF node trees, collections you can drag around in the Outliner. Nothing in the scene is a special iCity datatype, and nothing needs the engine running to stay there.

The linker mints every name, and the scheme is fixed:

The draft object each twin replaces is not deleted. It is hidden — Disable in Viewports and Disable in Renders — and stamped so the addon can put it back. Both cities stay in the file, in the same place, one of them out of sight.

Where it lands in the Outliner

Every dressed object carries a property called icity2_group, a collection path the engine itself wrote. The linker files the object into that path under the iCity 2 root, beside the draft object it dresses — so the dressed geometry for a road sits with that road, not in a pile of its own.

iCity 2/
  Roads/Segments/Road_<id>/...
  Blocks/Block_0/Buildings_0/...

Older builds put every imported object into one flat collection called iCity2 Front End. The current build does not create it, and sweeps away one left behind in a file saved by an older build. The sweep moves the collection’s contents to the scene collection first and removes the collection only once it is empty, so nothing in it is lost.

Four more collections appear at the top of the scene. They are the library data the dress needed, not part of your city:

All four are excluded from the view layer rather than hidden. An excluded collection stays in the depsgraph, so Geometry Nodes can still instance from it, while contributing nothing to the render. Leave the checkboxes off.

Appended, not linked

Element families and prop assets are appended into your file, not linked from the library. Those meshes are in the .blend, so no element or prop datablock points at a file outside it, and the geometry survives moving, renaming or clearing the Library Folder. Surface-material images are the one thing that does not — see the end of this section.

Linking was measured and rejected. With linking the saved file stores an absolute path into a cache directory the addon deletes on a library change, on its own size cap, or on a Blender upgrade — and the failure is silent and total: every element family comes back an empty placeholder and the whole facade disappears. Appending trades file size for a file that keeps working.

So expect a large .blend. The measurements recorded in the addon:

• —916 MB with the elements appended, against 223 MB for the same file linked.
• —About 1 GB for a fully dressed city.

Textures land in two different places, which matters if you move the file. Element and prop meshes are imported from .glb files and their images travel inside the .blend. Surface materials are built as image texture nodes pointing at basecolor.png, roughness.png and the rest in your Library Folder, and those images stay external references. Open the .blend somewhere that folder is not present and those materials come up without their maps, unless you pack them first from Blender’s File → External Data menu.

Editing what arrived

Draft city objects cannot be clicked in the viewport — the addon marks them unselectable, which is why Draft is driven by gizmos. Dressed objects are not marked that way. In Design you select them by clicking, move them, edit their meshes and parent them like anything else in the file.

Materials open in the Shader Editor as a Principled BSDF with an image texture node per map the asset ships. You can retint, remap and rewire them.

Props are not individual objects. The dress bakes point clouds, then puts a Geometry Nodes modifier named iCity2 Instancer on each one; the node group instances a collection of assets across the points, varying the asset per point. Selecting a cloud selects every prop it places, and there is no single bench to click. The prop meshes themselves sit in iCity2_Assets.

What happens to any of these edits the next time the city is dressed is a separate question with a definite answer — What survives a re-dress.

Draft hides it, Design shows it

The draft city and the dressed city occupy the same space, so showing both puts one z-fighting through the other. The module switch resolves it: entering Draft disables every dressed object in the viewport and in renders; entering Design turns them back on and hides each draft object that has a dressed twin. A draft object still waiting for its first dress stays visible, so the city never shows a hole where a result is still in flight.

The practical consequence: render from Design. A render started while Draft is the active module gives you the undressed draft city, because the dress is disabled in renders at that moment.

One class of object is deliberately viewport-only. The path and scattering-base objects the scatter runs on are drawn as wireframes so you can find them, and are never included in a render. Stray wireframes in the viewport that do not appear in your render are those.

Undo after a dress

Ctrl+Z immediately after a dress does not unwind it. The dress operator pushes nothing onto Blender’s undo stack, and the linker suspends global undo for the duration of the run.

That is a measured decision, not an oversight. A global undo push snapshots the entire .blend, and the cost tracks the file size: on a dressed city one snapshot measured 868 ms. A warm dress still makes 43 element imports, and 277 on a cold library — each one an operator that would take its own snapshot.

Your own undo is not affected. The guard restores the original setting when the dress ends, on every path including a failure, and it restores the value it found rather than forcing undo back on.

The rule underneath is that the dress is derived data: you do not undo a dress, you re-dress. See Re-dressing after a change.

Getting it out to another application

iCity has no export command. There is an Export tab in the rail’s source and it is commented out; no export operator is registered. Moving geometry to another application is Blender’s own File → Export, and the dressed city is ordinary enough for that to work.

1. Switch to Design. In Draft every dressed object is disabled in viewport and render, and exporters that respect those flags will write nothing.
2. Select what you want to take. The draft objects are still in the file, hidden, so limit the export to your selection rather than exporting everything.
3. Choose File → Export and your format.
4. Make sure the exporter evaluates modifiers. Props are Geometry Nodes instances on point clouds — an export that skips modifiers writes out the points and none of the props.

An export is a one-way copy of a result. Nothing you change in the exported file finds its way back to the project, and the project is what the next dress reads.