I spent a winter rebuilding the same six parcels twice, once in Cityweft and once in Shapezo, because I wanted to know whether they were substitutes. They are not, and the difference has nothing to do with how pretty the geometry looks. It is a data-structure question: does the output have parts, do those parts have positions on the earth, and can a program address them. Once I framed it that way the comparison wrote itself.
Query the scene instead of squinting at it
A Cityweft scene arrives as separate geolocated layers: buildings, terrain, vegetation, water, roads and surrounding facilities. Buildings carry attributes, specifically height and roof form, which means I can ask the scene something rather than staring at it. The question becomes 'everything above four storeys with a gable roof inside this buffer', and I get back a set I can count, hide, isolate or edit. Shapezo hands me a triangle soup with no fields, no identity, and no reference system. Excellent triangle soup. Zero schema. If you have ever tried to write a script against a generated mesh you know exactly how dead that branch of the tree is.
Coordinates are the real export format
Layer separation is nice. Layers that agree on where they are is the useful part. I pushed one context into Revit for the structural lead, into Rhino for massing studies, and into SketchUp because the neighbourhood group only opens SketchUp. In every case the parcel landed on the same ground and the same street, so nobody had to align by eye or ask which north I meant. With a single generated object I have two options: trust that its invented position happens to be right, or rebuild the context myself. Rebuilding always takes longer than the thirty seconds the generation saved.
An API turns one scene into a family of scenes
This is where the beauty contest stopped. Cityweft exposes an interface, so I wrote a short script that fetched a base context once, then swapped footprint and height parameters against it and wrote each variant to disk. Fifteen massing options, identical terrain, identical road network, identical tree cover, and I could line the results up next to a spreadsheet of their numbers instead of comparing my memory of them. A generative loop whose input is one mesh is really only a rendering loop. You cannot constrain pieces you cannot name, so the search turns into me clicking a button again and hoping for a different world, which is not design automation at all.
A digital twin has to accept patches
A twin is only worth running if geometry and data drift together. With addressable layers, a change in the world is a patch: one building attribute updates, one road segment moves, everything else keeps its identity and my earlier comparisons stay valid. With a generated lump, any change means a brand-new lump, and every number I quoted from the previous version becomes an anecdote. That is the difference between a living dataset and a screenshot with polygons.
What the fast generator is still correct for
Screening and atmosphere. Eight candidate sites in an hour, or a frame for a conversation about character rather than numbers. I use it there without guilt and I label the output as generated context. What I refuse to do is wire it into a step that has units attached, or hand it to somebody who will read measurements off it. The export path matters here too: a platform that publishes to Revit, Rhino and SketchUp is inviting downstream work, while a single mesh is really a final render wearing a 3D costume.
Two rules I taped to the monitor
First, a model that cannot be filtered is an illustration, no matter how many polygons it has. Second, a model that cannot state where it sits cannot be shared, only sent. Generated context is a superb sketch and a terrible source of truth, and most of the trouble I caused myself last year came from using one as the other. Decide which you need before you open either tool, and your afternoon gets a lot shorter.
