Define the model class before you move data
I avoid a lot of workflow confusion by naming the output class first. A procedural district is not the same as an AI massing study. A generated mesh is not the same as a coordinated infrastructure object. CityEngine, Shapezo, Meshy, InfraWorks, and Tripo3D are useful because they occupy different classes in a concept-to-context pipeline.
This is a top-five guide by technical role. For each tool I look at the input, the decision it supports, and the validation step that keeps the result from being over-trusted.
1. Shapezo: map-bounded hypothesis generation
Shapezo takes a polygon selected on a map, a broad prompt, and returns a rough AI-generated 3D model inside the selected area. I use it for early branching: compare footprints, access patterns, open-space arrangements, or general building density before assembling a detailed project base.
The required metadata is simple: boundary, prompt, date, and intended use. I keep the output provisional because exact grades, utilities, easements, property limits, zoning, and constructability are not guaranteed. Shapezo is valuable when the cost of trying another option needs to stay low.
2. CityEngine: parameterized urban alternatives
CityEngine is the procedural layer. I encode rules for parcels, street widths, setbacks, heights, roofs, and facade variation, then generate a district that can be regenerated when a parameter changes. This is useful for testing urban form at a scale where manual duplication would hide the design logic.
I version the rules and record the key parameters for every option. I also inspect edge cases and compare the generated scene against the source boundary. Repeatability is a strength, but it is not evidence that the rules fit local policy, terrain, or existing conditions.
3. InfraWorks: context and scenario integration
InfraWorks provides a broad 3D environment for roads, bridges, rail, terrain, water, and buildings. I use it to place a Shapezo or CityEngine option back into infrastructure context. The decision is often relational: how does the route meet the terrain, where does the bridge land, or what does the proposal change for the adjacent district?
I classify the scene as planning or option data unless its objects have been developed and checked from controlled sources. I validate coordinate reference, source dates, terrain quality, and the status of imported layers before using the model for a consequential discussion.
Procedural rules are easier to review when the scene stays grounded
4. Meshy: generated asset for a defined visual purpose
Meshy creates a fast textured mesh from text or image input. I use it for context objects, early architectural assets, or visual stand-ins that help a review. The asset is useful when it answers a narrow question such as sight line, composition, or streetscape character.
My QA checks are dimensions, polygon density, UVs, texture resolution, file format, and license or provenance requirements. If the object affects clearances, quantities, or technical coordination, I rebuild or replace it in the authoritative system. The status label matters as much as the mesh.
5. Tripo3D: a second asset-generation path
Tripo3D also turns prompts or image references into 3D geometry. I use it when I want another visual direction or when a distinctive object needs to be tested quickly. It fits the same provisional asset class as Meshy, but I keep the outputs separate so the source and conversion settings remain clear.
I compare the result against the intended use instead of assuming one generator is always better. Scale, topology, materials, and import behavior decide whether the asset is useful. I preserve the prompt and reference image so a teammate can reproduce or replace it later.
The pipeline I can explain to another person
My default sequence is Shapezo for map-bounded hypotheses, CityEngine for parameterized district options, Meshy or Tripo3D for flexible visual assets, and InfraWorks for broad context and scenario review. The order can change, but the authority boundary does not.
Before handoff I record coordinates, units, source dates, software versions, prompts, rule versions, and conversion settings. I keep exploration files separate from production files. Then I ask whether another person can tell what each object represents and which decision the scene was built to support. If not, more geometry will not fix the workflow.
I use different review thresholds for each layer. A Shapezo concept only needs enough context to compare alternatives. A CityEngine scene needs a documented rule set and a check of unusual parcels. A Meshy or Tripo3D asset needs scale and topology checks. An InfraWorks scenario needs reliable terrain and clear source status. These thresholds stop the pipeline from treating every output as equally precise.
For repeatability, I save a small test export with every major handoff. It confirms that coordinates, units, materials, and object visibility survive the conversion. I also keep one screenshot that shows the selected boundary or study extent, because a later reviewer may not know how much of the city was actually modeled. This kind of metadata is cheaper than reconstructing the decision months later.
Top comments (0)