I prefer a city-modeling pipeline where every object has a visible status. Shapezo produces inferred geometry from a map-selected boundary. CADMapper converts source-backed CAD and map information into a 3D base. CityEngine applies rules, joins GIS context, and prepares the scene for visualization or analysis. Treating these as separate states makes the workflow easier to debug.
The risk is not that one tool is fast and another is detailed. The risk is that a plausible object loses its label as it moves downstream. My workflow keeps the distinction between generated concept, imported source geometry, procedural content, and validated analysis input.
State 1: a bounded hypothesis
I start with a question that has a boundary. It might be a station block, a hospital expansion parcel, a logistics edge, or a waterfront connection. In Shapezo, I generate a few options for massing, access, density, and open space. I store the boundary, request assumptions, date, and a short note about what the AI could not know.
The output is useful because it is cheap to change. It is not a site survey, a zoning envelope, or an engineering layout. I keep it in an exploration folder and do not let it silently become the project's base model.
State 2: source-backed geometry
When an option survives, I prepare the inputs for CADMapper. I may have DWG or DXF plans, PDF or SVG drawings, terrain, imagery, and GIS layers. I check units, coordinate reference, layer meaning, coverage, source dates, and file cleanliness before conversion. A broken polygon or an offset coordinate can create a very convincing wrong scene.
CADMapper gives me a way to carry building footprints, roads, terrain, utilities, and other infrastructure into 3D while keeping their relationship to the source visible. I compare a few known dimensions against the plan before moving on. This is also where I decide which layers should remain lightweight for the current task.
State 3: procedural city content
In CityEngine, I can place the converted geometry beside rule-driven content. Parameters can control floor count, building height, setbacks, roof types, street widths, landscape density, and other repeated features. I use rules to make assumptions explicit and adjustable instead of scattering one-off edits across the scene.
The surrounding GIS context matters here. Terrain, water, roads, existing buildings, and land-use layers allow the proposed parcel to be evaluated as part of a network. I can test a viewshed, daylight condition, movement pattern, or access route without pretending that the proposal exists in an empty field.
State 4: fit the export to the job
CityEngine can support exports such as CityGML, OBJ, FBX, PLY, STL, or 3D Tiles, but I choose after checking the consumer. A semantic exchange needs object meaning. A browser view needs efficient geometry. A renderer may need materials. I do not use an export setting as a substitute for deciding what the model is supposed to prove.
Validation checks I keep small
Before analysis, I check coordinate alignment, scale, terrain continuity, missing objects, duplicate surfaces, and model date. I inspect the selected parcel and a few surrounding blocks from more than one view. I also compare a generated option with the source-backed scene so the difference between concept and evidence stays visible.
A compact layer manifest helps. For each major object, I record the source file or rule, the model status, the level of detail, and the last update. If a reviewer asks why a road moved or a building height changed, I can trace the change to a source revision or a parameter edit.
I keep the manifest close to the project rather than in a separate personal notebook. That small habit makes reviews calmer: someone can open the scene, select an object, and understand whether it came from CADMapper, a CityEngine rule, or an early Shapezo test. The handoff becomes a data conversation instead of a guess.
The pipeline rule
Shapezo answers, 'What could fit here?' CADMapper answers, 'How do I carry the known drawing into 3D?' CityEngine answers, 'How does this behave as part of a rule-driven city?' Keeping those questions separate gives me speed at the front and auditability at the end.
Top comments (0)