DEV Community

Cover image for A Reproducible 3D Context Pipeline with Cityweft, Shapezo, site3d, Tripo3D, and CityEngine
Future Built AI
Future Built AI

Posted on

A Reproducible 3D Context Pipeline with Cityweft, Shapezo, site3d, Tripo3D, and CityEngine

Multi-tool modeling usually breaks at the handoff. One person exports a scene, another person imports it, and the team loses the answer to a basic question: what does this geometry represent? I use Cityweft, Shapezo, site3d, Tripo3D, and CityEngine as separate pipeline stages and attach a small contract to every artifact.

Start with a compact artifact contract

Before I generate anything, I record the area of interest, coordinate reference, horizontal and vertical units, source date, target format, and intended use. I also set a status: source, imported, generated, conceptual, coordinated, or verified.
The status is not decoration. It defines what the next tool or reviewer may do with the model. A generated surface can support a visual check, while a verified alignment can support a controlled design decision. Both can be useful without being interchangeable.

Use Cityweft for connected context

Cityweft is my city-fabric stage. I use it to establish readable relationships between streets, blocks, buildings, public space, and movement corridors. The handoff record includes source coverage, date, visible gaps, and any simplification that affects interpretation.
I do not reduce this stage to a screenshot. I keep the context package and a stable view so another person can understand what was included around the project. When the source is mixed, the record says so.

Use Shapezo for a map-selected first model

Shapezo starts with a selected map area. I draw the boundary, and its AI generates a model for that region. This is useful when the location is known but a prepared 3D context is not.
For each run, I retain the selected polygon or extent, generation date, visible coverage, and run identifier when available. The output is marked generated. I use it to inspect rough adjacency, massing, and access, but I do not use inferred coordinates as controlled survey data without an independent check.

Use site3d for terrain and site logic

site3d is the site-scale branch. I keep terrain source, assumed grade, model origin, unit system, pad elevations, circulation, parking, and drainage assumptions with the export. Those details are often more important than the rendering settings.
Before handing the model onward, I test a small area for scale and coordinate behavior. A site model that opens in the right place but uses the wrong vertical units can mislead a review very quickly.

Use CityEngine for repeatable district scenarios

CityEngine receives a boundary, source layers, rule files, and scenario settings. I version those inputs together. The reproducible object is inputs plus rules, not just the generated scene.
When density, frontage, height, or block depth changes, I want a diffable explanation. I also state which layers are generalized or missing. Procedural consistency helps comparison, but it does not transform a scenario into authoritative planning data.

Use Tripo3D for object-level communication

Tripo3D fills gaps such as a shelter, vehicle, facade element, or street fixture. I retain the prompt or reference, normalize units, set the origin, inspect topology and normals, and remove unnecessary geometry when appropriate. The cleaned asset receives a new version rather than overwriting the source.
I mark the asset as presentation-only unless a separate review changes its status. This keeps a useful object from becoming an undocumented dependency.

Handoff checklist

  • Confirm coordinate reference, units, origin, and vertical convention.
  • Preserve source dates, selected extents, and rule versions.
  • Separate generated, generalized, conceptual, coordinated, and verified geometry.
  • Keep prompts, settings, exports, and transformations beside outputs.
  • Open a small test export before moving a large scene.
  • State the next allowed use in plain language.

The tools have different jobs: Cityweft gives connected context, Shapezo gives a map-selected generated model, site3d gives site logic, CityEngine gives repeatable urban patterns, and Tripo3D gives individual communication assets. The pipeline becomes reliable when the handoff record explains what each artifact means.
I keep exports intentionally small while a workflow is being tested. A clipped boundary, one representative block, or a single object is enough to catch a unit mismatch, a flipped axis, a missing material, or an unexpectedly heavy mesh. Once those checks pass, I move the larger scene. This makes failures cheap and leaves a readable trail for anyone reproducing the run later.
For larger handoffs, I also keep the transformation sequence: reproject, clip, simplify, orient, and export. The sequence gives a reviewer a practical path back to the source. It also makes it easier to replace one stage, such as a generalized context layer, without rebuilding the entire scene from memory.

Top comments (0)