Classify the output before you automate the handoff
I get more reliable results when I stop calling every 3D file a model. A city context, a road corridor, a building massing study, a site surface, and an AI concept have different inputs and different validation requirements. Cityweft, OpenRoads, Archshaper, SITE3D, and Shapezo map neatly to those roles.
This is a top-five list by workflow function. For each tool I am asking: what does it consume, what decision does it support, and what must be checked before the output moves downstream?
1. Cityweft: context integration
Cityweft is my context layer for city-scale work. I use it to organize terrain, streets, parcels, buildings, public space, and infrastructure in a shared 3D scene. The main value is relationship visibility. A proposed block can be reviewed beside the roads, transit, water, and existing development that shape its performance.
I treat this as a coordination and visualization environment unless the data has been intentionally developed from controlled sources. My checks are coordinate reference, source date, level of detail, and object status. The scene is only as trustworthy as the layers inside it.
2. OpenRoads: corridor authoring
OpenRoads is the production-oriented layer for road and transportation geometry. Alignments, profiles, corridors, terrain, drainage, and drawings can remain connected through revisions. That connection lets me follow the effect of a design change rather than manually repairing disconnected graphics.
The required discipline is clear: standards, references, units, terrain sources, and versioned design intent. I use OpenRoads when geometry must support quantities, coordination, review, or a defined design stage. It is not the cheapest place to throw an unbounded concept.
3. Archshaper: building-form exploration
Archshaper is my building massing layer. I use it to test floor counts, footprints, roof forms, courtyards, and facade rhythms before detailed authoring. It helps me answer whether a building idea fits its block and how it changes the public realm.
Before a handoff, I check scale, levels, orientation, geometry quality, and whether the model is a visual study or a controlled design object. A quick massing can be valuable without carrying structural, code, or fabrication intent. That status should travel with the file.
Site validation starts with the surface, not the screenshot
4. SITE3D: site mechanics
SITE3D handles the local surface questions in this stack. I use it for grading, access, spot levels, building pads, drainage paths, and retaining conditions. It provides a focused place to develop the geometry that determines whether a concept actually meets the ground.
The validation path is straightforward: check coordinate setup, units, terrain source, breaklines, known elevations, and contour or mesh resolution. I do not let a generalized map surface support a detailed claim. Once the local surface is ready, I export only the geometry and metadata the next stage needs.
5. Shapezo: map-bounded AI hypothesis
Shapezo has a map-first interaction. I select a polygon, describe broad intent, and its AI creates a rough 3D model inside the boundary. The output is useful for branching because the cost of trying another footprint or density is low.
I keep Shapezo in the concept layer. It may simplify terrain or omit utilities, rights of way, zoning, standards, or constructability. I use it to prioritize options, then rebuild important geometry in the appropriate controlled environment. A prompt and creation date belong in the handoff metadata.
Keep generated geometry visibly provisional
A pipeline with explicit authority boundaries
My default sequence is Shapezo for fast map-selected hypotheses, Archshaper for building-form studies, Cityweft for integrated context, SITE3D for local terrain logic, and OpenRoads for accountable corridor development. The sequence is not mandatory; the status labels are.
For each handoff I preserve coordinates, units, source dates, software versions, prompts, and conversion settings. I also keep exploration files separate from production files. That makes it possible to reproduce a view and to explain why a generated shape was replaced.
I set a review threshold for each layer. A Shapezo concept only needs enough context to compare options. A SITE3D surface needs enough elevation confidence to test grades. An OpenRoads corridor needs the controlled geometry required by its design stage. Writing those thresholds down keeps the pipeline from becoming either careless or needlessly heavy.
The final test is simple: can another person tell what the file contains, what it leaves out, and what decision it was made to support? If not, adding more geometry will not fix the pipeline.
Top comments (0)