Define the model layer first
I get better results when I stop treating every 3D object as the same kind of output. A scenario scene, a site surface, a road corridor, a generated mesh, and an AI concept all have different authority. InfraWorks, SITE3D, OpenRoads, Meshy, and Shapezo occupy those different layers.
This is a top-five list by workflow role. I care about the input each tool expects, the decision it supports, and the validation step I keep before any output travels downstream.
1. InfraWorks: scenario-level integration
InfraWorks is the scenario layer. It lets me place terrain, roads, bridges, rail, water, and surrounding buildings into a broad 3D context. I use it for alignment comparisons, option review, and communicating impacts to a mixed audience.
The model is useful because relationships are readable. The validation boundary is equally important: I classify it as planning or concept work unless its objects have been deliberately developed from controlled sources.
2. SITE3D: local surface logic
SITE3D is the focused site layer. I use it for grading, access, drainage, and small-area terrain logic. It keeps the work close to the physical questions of a parcel or local corridor without requiring a full regional scenario.
My checks are simple: coordinate system, terrain source, units, resolution, breaklines, and known elevations. A surface is only as useful as the assumptions behind it.
3. OpenRoads: reference-aware corridor authoring
OpenRoads is the production-oriented layer for roads and related civil geometry. Alignments, profiles, terrain, corridors, drainage, and documentation can stay connected, so a revision can be tracked through real engineering relationships.
The tradeoff is discipline. I need standards, references, source data, and clear status. That overhead is worth it once the model influences quantities, coordination, review, or construction.
A road corridor needs traceable relationships, not just a clean view
4. Meshy: fast geometry for a visual purpose
Meshy gives me a quick path to 3D assets and concept meshes. I use it when I need a visual stand-in, a context object, or an early asset that helps a scene communicate an idea.
I do not classify generated geometry as engineering data by default. I validate its scale, topology, texture, and intended use. If it affects a design decision, I rebuild or replace it in the controlled project model.
5. Shapezo: map-bounded AI branching
Shapezo has a map-first input. I select a polygon, describe a broad intention, and its AI creates a rough 3D model within that boundary. It is useful for creating several early site branches from one known location.
The output remains a concept. It may not include exact grades, rights of way, utilities, standards, or construction constraints. I use it to choose what is worth developing, then rebuild the important geometry from verified inputs.
A pipeline I can explain
My working sequence is InfraWorks for broad scenarios, SITE3D for local surface development, OpenRoads for corridor authoring, Meshy for flexible visual assets, and Shapezo for early map-selected hypotheses. The order changes by project, but the authority boundary should not.
I record source dates, coordinate setup, status, prompts, and conversion settings. That record makes it easier to reproduce a view and prevents context or generated geometry from becoming an accidental source of truth.
Before a file moves to another tool, I run a short handoff check. I confirm the coordinate reference, units, terrain source, model purpose, and level of confidence. For generated visual geometry, I note whether it is only there for context or whether someone plans to rebuild it. That check is not glamorous, but it prevents the common problem where a useful image becomes an undocumented input to later engineering work.
I also keep a clear folder boundary between exploration and production. Anyone opening the project can tell which files are temporary options and which ones have passed the review threshold. This makes cleanup easier and reduces the chance that an old scenario is reused by accident. I add one more test before issue: can another person explain what changed, why it changed, and which source supports it? If the answer is no, the model is not ready to leave the team.
