Rendering & exporting

There is no export button

Nothing in the addon exports a file. There is no export operator anywhere in it, and no control that writes one. The only trace the idea ever left is an Export entry in an old tab rail in the editor’s source, commented out in both of the places it would have to be listed to appear — and that whole rail is commented out too. The rail you actually see down the left edge is the editing-mode column: Graph (Theme in Design), Roads, Blocks, Lots, Massing, Scatter, and the tools for whichever one is active.

Blender’s own File → Export is the answer, and it works because the dress leaves ordinary Blender data behind. Element families and prop assets are appended into your file rather than linked from the library, so the mesh data is in the .blend; materials are Principled BSDF node trees; the dressed objects are meshes in collections. Nothing about them is an iCity datatype, and nothing needs the engine running to stay there.

The one thing that stays outside the file is the surface materials’ images, which are texture nodes pointing at basecolor.png, roughness.png and the rest inside your Library Folder. What is in your .blend after a dress covers the whole inventory.

Before you render or export

A dressed city is not a static scene. Three things can change it while you are working on output, and all three are worth settling before you start rather than in the middle of a render.

• —Be in Design. The module switch sets Disable in Viewports and Disable in Renders explicitly on every object it classifies, every time you switch. In Draft the entire dress is disabled in renders, so a render started there gives you the undressed draft city.
• —Leave City sync on Manual. It ships that way, because it spends credits. Switched to Auto, a Draft → Design switch re-dresses the city by itself: it waits 2.0 seconds for the switch to settle, compares the draft’s signature against the last dress, and fires a paid frontend job (about 3 credits) if anything changed. It refuses when nothing changed, and there is a 30-second floor between two automatic fires.
• —Have no cloud job in flight. When a job’s outputs finish downloading, the addon re-dresses on the spot — the same full link the manual button runs. Wait for the job to land before you export the result of the previous one.

City sync’s mode lives on the ▾ beside the sync button in the editor header. The button itself re-dresses now; the arrow chooses Auto or Manual, and the menu prints which one is in force.

Rendering a dressed city

Rendering is Blender’s, unchanged. The addon adds no lamp and no world, and leaves your render engine as it found it — the one place it touches the engine at all is the screenshot capture, which sets one for the length of its own shot and puts yours back afterwards. So the lighting in a dressed file is whatever your .blend already had. A scene with no world and no lamps renders black in EEVEE or Cycles however good its materials are, which is a case the addon’s own screenshot lane tests for before it renders anything. Light the city yourself.

What ends up in the frame is decided by flags the linker and the module switch set for you:

If you render on another machine, or from a farm, pack the images first from Blender’s File → External Data menu. The surface materials point at files in your Library Folder, and without that folder present they come up without their maps.

Exporting with File → Export

The procedure is Blender’s, with two iCity-specific precautions: the draft city is still in the file, and the props are not mesh until modifiers are evaluated.

1. Switch to Design and put City sync on Manual, so nothing re-dresses under you.
2. Select what you want to take. The iCity 2 collection tree holds the dressed objects filed beside the draft objects they dress, so an untargeted export of everything picks up both cities.
3. Choose File → Export and a format. Limit the export to your selection, or to visible objects — in Design the visibility flags already describe the dressed city exactly.

   rendering-and-exporting-file-export-menu.png

   Blender's File menu open with the Export submenu expanded, listing the export formats this Blender build offers. A dressed iCity city visible behind it in the viewport.

   /docs-shots/blender/

4. Turn on whatever the format calls applying or evaluating modifiers. Props are Geometry Nodes instances on point clouds; an exporter that skips modifiers writes the points and none of the props.

   rendering-and-exporting-instancer-modifier.png

   A prop point cloud object selected in the viewport with its props visible, and the Properties editor on the Modifier tab showing the Geometry Nodes modifier named 'iCity2 Instancer' with its collection sockets.

   /docs-shots/blender/

5. Check the textures in the result. If the surface maps are missing, they were still external references into the Library Folder — pack them from File → External Data and export again.

If the dress is not in the scene at all — outputs downloaded while Blender was closed, for instance — press F3 and search for Dress City from Outputs. It runs the same link the automatic path runs, from the files already in the project, and it is safe to press more than once.

What a format has to carry

Do not assume every format takes the whole city. Three parts of a dress make different demands, and which format suits you depends on which of them you actually need.

The naming scheme travels with the geometry, so the result stays readable in another application: a dressed twin ends in _FE, a prop cloud is named for its placement, and the node groups are ICT2_<placement>. What is in your .blend after a dress has the full table.

The USD files already in your project folder

Before you export anything, there are two USD files sitting in the project folder under Documents/iCity 2. Both were written by the dress, and either can be opened by another application directly.

Documents/iCity 2/<project>/
  outputs.usd     the geometry the cloud produced
  outputs.csv     the point data props are placed from
  assets.json     the theme's material, element and prop picks
  send/city.usd   the city meshes that were uploaded
  send/city.json  the parameters that went with them

outputs.usd is not the finished city, and this is the trap. It is the geometry the frontend baked, wearing the placeholder asphalt, sidewalk and roof materials it was baked with. The library’s surface materials are swapped in locally afterwards, the facade elements are appended locally, and every prop is instanced locally from assets.json and your library. Opening outputs.usd elsewhere gives you the shape of the city and none of its dressing.

send/city.usd is the other direction: the undressed city meshes the addon uploaded, kept so a re-send has its inputs. It is the draft, not the dress.