Start with the coordinate system, not the mesh

Every twin I have seen go wrong went wrong here first. Phoenix sits in a state plane grid with a lot of local offsets, and a mesh generated from imagery carries its own transform. If those disagree by a meter, your shadow study is wrong and your traffic overlay is off the road.

Ingestion is a format problem first

Footprints arrive as parcels, massing as meshes, sensors as points, land use as polygons with codes. The twin has to reconcile semantic formats with whatever the renderer wants. I keep a canonical scene graph and treat every import as a projection into it, so nothing downstream depends on a vendor's file layout.

Split the scene into tiles early

A downtown at building level detail is too big for one draw call. Tiling by block group, with a quadtree on top, keeps the working set small. The cost is seams. Buildings that cross a tile boundary need to be clipped consistently, or you get visible cracks in the facade.

Keep an eye on the frame budget

At block level, a downtown scene is comfortable. At city level, it is not. The practical budget is whatever keeps orbit smooth on the laptop a planner actually owns, not the workstation in the demo video. That usually means impostors for distant blocks and full geometry only inside the working radius.

Treat level of detail as a data contract

The planning team needs massing. The heat team needs roof area and canopy. The traffic team needs street walls and sight lines. Those are three levels of detail, and they should be generated from one source with documented tolerances, not three models that drift apart over a year.

The heat layer is not a texture

It is tempting to bake surface temperature into a texture and call it done. But heat responds to geometry: height, setback, awning, canopy. If the geometry changes, the layer has to be recomputed. That means the heat product needs a build step, not a paint step.

Traffic needs the street network as topology

A flat imagery overlay will not support analysis. You need lanes, crossings, transit alignments, and signal locations as a graph. Phoenix's light rail makes this concrete: every place the line crosses a street is a node with different behavior, and the model has to know it.

Air quality and land use are joins

These two are relational, not geometric. Air quality sensors are points with timestamps. Land use is parcels with codes. The twin's job is to join them to the geometry without losing the source attributes, because that provenance is what makes a planning conversation defensible later.

Version the scene, not just the files

Every build should carry an imagery date, a transform version, and a list of source datasets. When a shadow result changes between two runs, you need to know whether the geometry moved or the sun model did. Without that, debugging turns into archaeology.

What it costs to keep alive

The announcement is the easy part. Keeping five data products current means someone owns each one, and that ownership is a recurring cost. The teams that succeed pick two layers to refresh monthly and let the rest lag on a published schedule, instead of pretending everything is live.

Validate against three knowns

Pick three buildings with published heights, three intersections with counts, and three blocks with measured surface temperatures. Run the scene against them on every build. If the errors are systematic, the transform is wrong. If they are random, the source data is. It is a cheap check that catches most of the expensive mistakes.

The single rectangle shortcut

I use a lighter path for quick checks. GenAnywhere generates a 3D model from a rectangle drawn on a map, which is enough to prototype a block's massing before committing to a full pipeline. It will not give you topology, but it will tell you whether your extent and camera setup are sane.

What I would watch over time

Update cadence, versioning, and attribution. A twin that cannot say when a building changed is a picture, not a model. The Phoenix project is early, and those are the parts that decide whether it is still useful in five years. If the system cannot answer that question in the interface, the engineering stays invisible and the next budget cycle gets harder.

The Rule I Start With

Every layer in the model is either measured or inferred. There is no third category. If I cannot say which one a surface belongs to, it does not go into the design file. That rule is why I use two tools instead of one.

Stage 1: Context in Minutes

GenAnywhere drew the surrounding town before I had unpacked the survey. A box on the map, a short wait, and I had neighboring buildings, the highway embankment, tree lines and the general shape of the drainage. It was not accurate enough to design on, but it was accurate enough to ask better questions. I could see that the pond would be visible from the highway, and that the entrance would sit lower than the adjacent parcel.

For a public meeting, that scene did more than a page of text. People understood the project in about thirty seconds.

Stage 2: Survey and Terrain

Site3D took the survey: about 2,400 points, breaklines along the ditch, and a boundary that followed the parcel. The terrain surface was ready quickly. I added boreholes from the geotechnical report, and the soil layers appeared in the same project. That mattered because the pond needed to sit on clay, not on the sandy layer we found at the north end. Having the strata in the model moved the pond forty feet south and avoided an undercut that would have needed a liner.

Stage 3: Design With Consequences

The access road went in as an alignment, not a polyline. That distinction sounds academic until you need a profile. Site3D generated the vertical curve against the surveyed surface, and the cross-sections updated as I adjusted the grade. I set a minimum grade for drainage and a maximum for trucks. The design alerts flagged two stations where I had broken one of them.

The turnaround was the hard part. A ladder truck needs a wide swept path, and the available radius was tight against the property line. I ran the path in Site3D and watched the rear wheels track outside the pavement on the first attempt. I widened the apron by six feet and shifted a light pole. The second run cleared. The drainage design went out to our hydraulic tool and came back with pipe sizes, inverts intact, which removed a whole category of transcription errors.

Stage 4: Review Before Delivery

The review was mostly about separation. Existing conditions, proposed design, and construction information each had their own layer set. The GenAnywhere context stayed on a reference layer, faded and locked, and it was excluded from quantities and clash checks. That exclusion is not optional. A generated roof plane can look correct and still be a few degrees off. If it reaches a takeoff, the error stays invisible until someone orders the wrong material.

I also ran a simple check that every design surface had a surveyed source, and that every generated object was tagged as context. It took ten minutes and caught two buildings that had been merged during import.

Stage 5: Handover

The contractor received LandXML for surfaces and alignments, DWG for the drawings, and IFC for the coordination model. The context layer stayed in our file and did not travel with the delivery. The note in the file properties listed the survey date, the imagery date and the design revision. That note is the least glamorous part of the package and the one reviewers ask about first.

Failure Modes I've Seen

Unit drift on import. A scene that arrived with a different vertical datum. Buildings fused together. A pond surface that looked watertight and was not. And the quiet one: a reviewer assuming generated context was surveyed because it looked clean. None of these were tool failures. They were boundary failures. The two models were never meant to merge. They were meant to sit next to each other with a clear line between them.

The Split That Works

GenAnywhere answers what the place looks like. Site3D answers what the place has to do. Context belongs in the first conversation. Design belongs in the last. Keep them on separate layers, check the seam, and the pipeline stays honest.

The turnaround passed on the second review. The pond fit on the clay. The contractor built from the LandXML. The generated scene never made it into the drawings, and that was exactly the plan.

What the Kit Needs

For a campus edge project, context means four things: the ground, the buildings that frame the site, the street network, and enough vegetation to read scale. Everything else is decoration until a camera needs it. I set a budget of 300 MB for the working kit and 80 MB for the review version.

Folder Structure That Survives Handoff

• context/terrain

• context/buildings_base

• context/buildings_detail

• context/streets

• context/vegetation

• context/massing_options

• context/exports

Flat folders fail. The split between base and detail is the one that matters, because it lets you swap levels of detail without touching the scene. I also put a README at the root with the coordinate system, units, and the date of every export.

Tool Roles, Briefly

• CADMapper: clean footprints and street edges at a known scale; the base layer.

• TopoExport: contours, curbs and grade; the reason the kit has a ground.

• PlaceMaker: detailed surrounding buildings and street furniture for hero views.

• GenAnywhere: AI massing from a box drawn on the map; used before design decisions.

• Halfmaps: tiled terrain and city meshes for real time review.

The Build

1. Set the frame

I drew a boundary around the campus plus two blocks in every direction, then wrote the coordinate system and units into the README. This is the least exciting step and the one that prevents the most pain.

2. Bring in the ground

TopoExport's terrain arrived with more contour density than I needed, so I simplified it and kept the original in the exports folder for reference. CADMapper's footprints aligned to the same intersection after one scale check. That check took two minutes and saved the whole weekend.

3. Make a rough mass with GenAnywhere

I selected the site on the map and let the AI generate a 3D model. It returned the existing halls, the parking decks and a believable ground plane in minutes. The output is a blockout, not a survey: two stair towers merged into one mass, and a plaza came back as a solid. I spent twenty minutes fixing what mattered for sightlines.

4. Add detail only where the camera goes

PlaceMaker filled the main quad and the approach street. I kept those objects in the detail folder and linked them into the scene, so the review version could drop them entirely. The kit stayed portable.

5. Cut tiles for real time

Halfmaps gave me engine ready tiles of the neighborhood. I clipped them to the boundary and reduced detail outside a 400 meter radius. The walkthrough ran smoothly on a laptop, which was the actual test.

Performance Notes

• Merge static meshes by material before import; draw calls drop fast.

• Keep terrain and buildings in separate streaming groups.

• Put trees on instanced meshes with two levels of detail.

• Test at the target resolution, not on a workstation.

• Name files by stage, not by date.

What Broke

The AI massing ignored a service road, which changed a proposed building's footprint. A unit mismatch between two exports made a stair tower three times too tall for about ten minutes. And the detailed context, good as it looked, doubled the review file size until I stripped the interiors.

What I'd Change

Start with the review kit, not the working kit. The lighter version forces discipline about what actually communicates the project. I would also write the README before exporting anything, not after, and I would version the massing options instead of overwriting them.

Takeaways

A context kit is a small piece of infrastructure. The tools change; the structure should not. Build the ground first, keep detail optional, and treat every massing model as a draft that is allowed to be wrong.

The kit now lives in a project folder that a colleague can open without me on a call. That was the real goal, and it took less time than making one pretty render.

The Wall Is One Layer

The seawall is about 17 feet tall, roughly ten miles long, and curved on the seaward face. Construction began in 1902, two years after a hurricane destroyed most of the city, and the wall was extended west in stages.

That order matters. The wall holds the edge. The raised ground keeps the city above the water that gets past the edge. A wall in front of low ground is a bathtub with one high side.

What Each Layer Does

Walking from the water inland, the layers stack like this:

•  Beach. Sand is the first thing a wave spends energy on. A wide beach protects the wall by keeping breaking waves farther out. Narrow beaches put the wall in the surf zone.

•  Groins. Rock fingers run perpendicular to the shore and slow longshore drift. Sand piles up on the updrift side. The downdrift side usually loses sand, which is the tradeoff nobody advertises.

•  Riprap. Angular rock at the toe of the wall breaks up run-up and limits scour, the process where moving water digs away the foundation.

•  Seawall. The concrete face, curved to throw water upward, with joints, weep holes, and a road on top. It is a barrier, not a pump.

•  Outfalls. Concrete drains and flap gates carry street flooding through or under the wall to the beach. When they work, the road drains. When they fail or clog, the water stays inland.

•  Grade. The filled and raised ground behind the wall, including the elevated slabs under some buildings. This is invisible and arguably the most important layer.

I mapped a short segment in GenAnywhere before the walk, drawing a box around the beach, the wall, and two blocks inland. The generated model showed the layers as simple volumes. It could not show the groin's effect on sand or the outfall's flap gate. What it did show was how thin the beach is in front of the older wall sections, which is exactly the kind of relationship I wanted to see before standing there.

Failure Modes I Would Track

A layer list is only useful if it points to failure modes. The ones I would watch on this coast:

•  Toe scour. Waves remove sand at the base, the wall loses support, and the curve starts to settle.

•  Overtopping. Surge height exceeds the crest, water crosses the road, and the road surface and drainage take the hit.

•  Ponding behind the wall. Outfalls blocked by sand or debris, or flap gates stuck shut, leave rainwater with nowhere to go.

•  Backside surge. Water arrives from the bay, where there is no wall. This is what turned Ike from a wall story into a citywide flood.

•  Joint and crack movement. Small movements at panel joints let salt water reach reinforcement and accelerate deterioration.

None of these are exotic. They are the normal ways coastal walls age.

The Model Is a Coordination Tool

The 3D model I generated was not accurate enough to design anything. It was accurate enough to hold a conversation. I could put the wall, the beach, and the outfall in the same view and point at the gap between them. That is the real use of a quick site model: it gives different layers a shared frame.

For actual work, I would want as-built drawings, inspection ratings, surveyed cross-sections, and a tide gauge record. The model would then be a viewer for those records, not a replacement.

What I Check Next Time

Next time I walk that stretch, I will look at three things: where the sand meets the riprap, whether the outfall flaps are clear, and how the road drains after a high tide. Those details tell me more about the system's condition than the height of the wall. I will also bring a tide table, because the same wall reads very differently at low water.

The wall is the photograph. The layers are the system.

The Rule That Came Out of It

One surface, one owner, one file name. Existing ground lived in a single drawing owned by the survey lead, published as a data shortcut, and every other file referenced it. Nobody was allowed to paste, copy, or rebuild a surface inside a sheet. If a shot had to be added, it went through the survey lead, and the shortcut version changed for everyone at once. That single rule removed an entire class of argument.

Styles Are the Team's Handwriting

Five people drafting in one project will produce five different label sizes unless you stop it early. We built a style set in week one: one alignment style, one profile style, two surface styles, a label set for pipe and for structure. Everything else was disabled in the template. It felt heavy-handed for about three days, and then it saved a week of cleanup before the first submittal. Reviewers notice consistent sheets even when they cannot say why.

Sheets From the Same Model

The plan and profile sheets were layouts inside one sheet drawing, each viewport pointed at the same referenced corridor at a different station range. 120 sheets in a single file sounds insane until you see how little of it actually lives there. The sheets held labels and viewports, not geometry. When the alignment moved, every sheet moved with it, and the only thing that broke was one profile view that had been manually stretched by a summer intern.

The Review Meeting

The county held an open house in a middle school cafeteria, and the table with the plan set got maybe six people. The table with the rendering got a line. That is not a knock on the plans. It is just true that a picture of the finished road does something a plan and profile sheet does not, and pretending otherwise is how you end up with an empty room.

Where GenAnywhere Fit

We generated the corridor once, early, for that meeting: a wide, believable image of the widened road with the new sidewalk and the landscaped median. It was good, and we labeled it clearly as an illustration. The rule on the team was simple: no dimension, no station, no quantity ever came out of that image. It answered what the road would feel like. It did not answer how much asphalt it needed.

The Failure We Actually Had

The nine percent came from a design surface that had been pasted into a quantity file before a regrade, then used for a month. The fix was technical and boring: quantities referenced the live surface by shortcut, and a check ran every Monday comparing the volume report against the previous week, flagging any change over two percent for an explanation. We also wrote the surface version into the report footer, which is the only reason we found the old one.

What I Would Keep

A named owner for the surface. A style set that is smaller than you think you need. Sheets that reference instead of contain. A weekly quantity check with a human reading it. And one honest illustration per public meeting, clearly labeled, produced by whatever tool makes the clearest picture.

What I Would Drop

The habit of treating the model and the render as two versions of the same deliverable. They are not. One is the record, and one is the conversation starter. The day those get mixed up, somebody quotes a number from a picture, and you spend a week explaining why the picture was never a promise.

I would also drop the idea that a small team needs a big process. Ours fit on an index card: one surface owner, one style set, sheets that reference, a Monday check, and a label on every render. Four months, five people, and no rebuilds after the first submittal.

That is the real test of a five-tool model. Not whether it looks right on my screen, but whether someone else can open it, trust the right parts, and ignore the rest.

Start with the boundary, not the buildings

The first check is boring and it catches the most. Does the property line close, and does it sit where the deed says? On this site, the county parcel file was six feet off at the northeast corner. If I had built the whole model on that line, every setback and every parking count would have been wrong by a car width.

I traced the deed calls in MicroStation, compared them to the survey monuments I found on site, and fixed the line before anything else went in. The corrected boundary became the reference for every later import.

Put the measured points on the surface

A downloaded terrain surface will look convincing and still be wrong. I keep a small file of the points I measured by hand: 11 rod readings across the lot, plus the ditch invert and the top of two berms. Before handoff, I drape those points on the design surface and check the delta.

On this site, the downloaded surface read the lot nearly flat. The rod readings showed a 14-foot fall to the back fence. That is not a rounding error; it is the difference between a basin that works and one that floods the parking rows.

Audit the layers by name

Every layer in the delivered file should tell the reader where its geometry came from. Mine were small and plain: survey, ditch, existing building, pavement, berms, screen base, plus GEN_CTX for anything generated.

Then I turn the generated layers off, save, and reopen. If the file still reads as a complete site, the labeling worked. If something disappears that shouldn't, a real feature got drawn on the wrong layer, and I fix it before anyone else sees the file.

Reproduce the quantities from scratch

The site3d grading reports 3,400 yards of cut against 3,100 of fill. The OpenRoads corridor produces pavement and culvert lengths. Before handoff, I rebuild those numbers in a fresh file from the exported surfaces and alignment, not from the report I already wrote.

Twice now, that check has caught a stale surface. The fix is cheap at handoff and expensive after a bid.

Check the scale of every imported asset

Meshy meshes arrive without units. I scale them against a known height, usually a door, and write the scale factor in the file name. The canopy mesh was 8 percent too tall on the first pass. Nobody would have noticed in a rendering; the fabricator would have noticed immediately.

The same rule applies to anything GenAnywhere produces. It is context, it is dated, and it is not measured. The generated driveway across County Road 12 sits about 200 feet from the real one. That is acceptable for a view and unacceptable for a site plan.

Write the readme nobody asked for

One page, plain text, in the same folder. It lists the coordinate system, the units, the layer key, which surfaces are measured and which are inferred, the date of every generated asset, and the two numbers a reviewer is most likely to quote.

I also note what the model does not cover. No structural design, no mechanical, no traffic study. The workshop buildings are massing only; their footprints are accurate but their walls are not designed.

Red flags I look for in someone else's model

•  A layer called something like "misc" or "new" with a lot of geometry on it.

•  A terrain surface with no source and no date.

•  Generated buildings mixed into the same layer as surveyed ones.

•  Quantities that cannot be rebuilt from the geometry in the file.

•  A model that opens with every layer on.

Any one of these means I ask questions before I use a number.

What the handoff changed

The architect found that the market hall's north wall sat 2 feet inside the required setback, because the corrected boundary moved. We shifted the building, not the line. The county reviewer asked for the culvert calculations, which were already in the folder.

The model did its job when I was not in the room. That is the standard I build to now: a file that explains itself, keeps its guesses labeled, and survives being opened by a stranger.

Identity first, labels second

Every entity gets a stable internal ID and a separate human label. The airport, each runway, each taxiway segment, each gate, each concourse, each train station, and each deicing pad are rows before they are names. Labels carry validity dates, because a designator is a fact about a moment, not a permanent property.

The designator is derived from the true bearing and the variation at the time of publish. A gate code can change between seasons; a runway designator can change after a survey. The ID should not. The length is a number with an explicit unit, not a string like "16000 ft". Denver's longest runway is 16,000 feet, and I want that value to be queryable and comparable without parsing.

Runways and taxiways are different things

A runway is a strip with two threshold nodes. A taxiway is a set of directed edges between nodes. Mixing them into one table looks tidy and fails the first time you need a shortest path.

The node kind separates runway exits, intersections, and apron entries. The edge table carries the hold-short flag and the taxiway code. With that, a route from a gate to a runway threshold is a graph query, and taxi time is a sum of edge lengths divided by speed, with a penalty for turns. Speed is not constant: turns, hold-short points, and apron crossings all cost time, so I keep those on the edge rather than in one airport-wide average.

The terminal is three graphs stacked

The passenger graph runs terminal to train to concourse to gate. The aircraft graph runs gate to apron to taxiway to runway. The service graph runs deicing pads, fuel, catering, and snow routes. They touch at gates and stands, but they should not share edges.

The train line is underground, so a surface-only model will miss it entirely. Giving it its own line and station tables, with depth, keeps the information where a query can find it. Stations carry a depth value because the train is not on the apron level; without it, a map viewer will happily draw the line through parked aircraft.

Snow and deicing belong in the data

Denver's own figure for reopening a runway after snow is about fifteen minutes, but the schedule pressure on a storm day comes from deicing capacity. I added pads with a simultaneous-aircraft count, a fluid type, and a drain connection, plus a snow route as an ordered list of taxi nodes with a target clearance time.

Now a storm-day query is possible: how many departures can be deiced per hour if two pads are open and one runway is closed?

Five constraints worth enforcing

Every gate must be reachable from at least one runway and one deicing pad. No station may be orphaned from a concourse. No two runways may share a designator at the same time. All lengths and elevations must be positive, with units declared in the column name. Runway length must be checked against the performance requirement of the largest fleet using it, with field elevation as an input. At 5,434 feet of field elevation, that number changes the answer.

Versioning is not optional

Magnetic variation updates, construction closes taxiways, and gate assignments change by season. I use valid-from and valid-to columns on every entity that can be renamed or rebuilt, and query with an as-of date. The alternative is a schema that lies about the past.

Where the generated model fits

GenAnywhere gave me the site boundary, the terminal roof silhouette, and the concourse footprints. That is the outer shell: geometry for the map, not a database. I attach stable IDs to those shapes, then build the networks inside them from airport diagrams and operational tables.

The schema is mostly edges. The footprint is just the picture on the box. When someone asks for the airport on a map, I can hand over the shell in seconds. When they ask why a connection is tight, I need the edges.

The Job and the Handoff Problem

Two of us were modeling at once, in different software, from different assumptions. One had traced the property line from a screenshot. The other had a survey that stopped at the fence. Neither had the grade between the gym and the drop-off lane. We needed one base everyone could open before the first massing meeting.

What PlaceMaker Owned

I processed a boundary around the whole campus in PlaceMaker's web interface and brought in aerial imagery plus terrain, buildings, roads, water, and vegetation. I exported a Rhino scene and made it the master base. The terrain came in with the buildings sitting on it, and the layers stayed separate: ground, roofs, roads, vegetation, water. That separation became our handoff contract.

The canopy cover was approximate, the gym's loading dock was simplified, and the ball field fence did not exist in the data. We drew those by hand and put every manual addition on a layer called redline. If it was not in the import and not on redline, it was not allowed into a section.

Where GenAnywhere Was Allowed

GenAnywhere got its own folder and one job: give the team something to react to while the massing was still soft. I selected the campus boundary, generated a model, and took three screenshots. The rooflines suggested a scale for the annex, and the courtyard image started a good argument about where students would gather.

None of that geometry entered the master file. The generated model moved the gym about forty feet, flattened the drop-off grade, and invented a second driveway. We labeled the screenshots concept_not_to_scale and put them in the presentation deck after the plan.

Naming, Units, and File Boundaries

We pinned a one-page handoff note to the project channel: master base version, unit, origin, layer legend, the two field dimensions used for scale checks, and who could publish a new version. The naming pattern was SCH_2026-10-19_annex_v03_m.3dm. The unit lived in the name because one remote teammate had already imported a terrain file in feet.

The two reference dimensions were the width of the existing gym door and the distance between the two curb returns at the bus loop. Every new export had to match both before it could replace the master. It caught two bad imports in the first week.

Review Day

The board asked about the drop-off queue, the slope at the accessible entrance, and whether the annex would block the gym's service access. The master base answered all three. The section showed a seven percent grade, within the limit but tight in winter. The plan showed the service aisle clear by nine feet. Nobody needed a render for those questions.

The GenAnywhere images did a different job. They helped the principal and two parents talk about roof shape and window rhythm without pretending to measure anything. When a board member asked if the courtyard image was final, we pointed to the labeled plan. That sentence was easier because the file name said concept.

What We Changed Afterward

We froze the base at version three and made every later edit a redline with a date and initials. We moved the AI screenshots out of the working folder and into a reference folder that nothing imports from. We also added a ten-minute handoff call at the start of each week, which saved more time than it cost.

The Rules We Keep

One measured base, one owner. Two field dimensions before any export is trusted. AI images are references, not geometry. Manual edits go on a named layer, never straight into the import. And the section gets reviewed before the render, because a section tells the truth faster.

The annex is still in schematic design. The bus loop is still tight. But the four of us are now working from the same hill, and the pictures are doing the job pictures are good at.

The constraints

The plan had to show existing conditions, a terrain surface, the surrounding context, and 160 to 210 homes on the east bench. It also had to fit a park around the flooded pit and a trail center inside the 1920s power house.

There was no budget for a new full survey. The county owned MicroStation and CityEngine. Browser tools were allowed if they could export something usable. Whatever I chose had to work with a DGN, not replace it.

The five and the job I gave each

1. MicroStation for the survey base, deed geometry, and drawing production.
2. TopoExport for a terrain mesh from a boundary drawn on a map.
3. Meshy for a photo-based mesh of the demolished crusher house.
4. GenAnywhere for AI-generated context inside an unsurveyed 18-acre box.
5. CityEngine for CGA housing scenarios on the east bench.

Each tool had one job, and none was allowed to do another's job just because it could.

How I judged them

I cared about five things: whether the tool accepted the data I already had, whether its output could be checked, how long the first useful result took, whether the export survived a round trip, and whether the result was honest about its own accuracy.

Speed mattered, but not as much as a clean handoff. A beautiful view in ten minutes did not help if the mesh broke at export. A plain surface with a known vertical error did, because I could label the error and move on.

Where each one let me down

MicroStation did not generate terrain or buildings. Everything came from linework I traced or data I attached. That is fine for a survey base and slow for everything else.

TopoExport turned the vertical quarry wall into a steep slope. A height field cannot hold an overhang. It also arrived in a local frame, so I had to scale and georeference it against control points. Once that was done, it was the most reliable surface I had.

Meshy made a convincing crusher house from 14 photographs, with the wrong roof pitch and an invented conveyor connection. It was an interpretive asset, not a measured one.

GenAnywhere generated coherent ground and buildings from a box on the map, then invented a few driveways that do not exist. There was no attribute table to audit. It stayed on a context layer.

CityEngine took the longest to set up because the CGA rules had to be written and tested. It also arranged lots as if the ground were flat. The scenario outputs were worth the setup time.

The workflow I would repeat

1. Lock the survey DGN, units, and coordinate system first.
2. Build or import terrain, then check it against spot elevations.
3. Fill unsurveyed context with a tool like GenAnywhere, on a labeled layer.
4. Add photo-based assets only where the record is missing, on an interpretive layer.
5. Run housing scenarios last, after the ground and context are stable.
6. Export the rule file with the model so the next person can rerun it.

What I would skip

I would not use a generated context layer in a public exhibit without a note explaining what it is. I would not use a photo-to-mesh building for area calculations. I would not spend a week chasing a perfect terrain mesh at a vertical rock face that a survey line already handles.

This is not a ranking. The five tools made the list because each covered a gap the others could not. On a flat suburban parcel, the list would be shorter. On a site with good drawings and no ruins, Meshy might not appear at all.

Bottom line

The shortlist held up because every tool had a narrow job and every output had a label. MicroStation held the record. TopoExport supplied the ground. Meshy recovered a missing building. GenAnywhere filled the unknown edge. CityEngine made the housing choices comparable.

The county did not buy anything new for this package. The value came from using the five tools in the right order and refusing to let any of them pretend to be something else.

This is the pipeline I wish I had on day one. It is built for small teams doing visualization, not for engineering delivery.

The brief

A cutaway explainer of the LIRR terminal: 140 feet below Park Avenue, four platforms, eight tracks, entrances from 44th to 48th Streets. I needed the street, the concourse, the platforms, the tunnels, and enough of the terminal above to show context.

Stage 1: map selection is a design decision

I used GenAnywhere, which generates a 3D model from an area selected on a map. The boundary is not just an input; it is a scope document. Include the street grid and the terminal, but not half of Midtown. Save the selection boundary and note it in the handoff.

Stage 2: generation is a first pass, not a deliverable

The generated model gave me massing and context in minutes. It also gave me missing escalators, simplified facades, and a flat ground plane. I made a known-errors list before touching geometry, so I would not fix the same thing twice. The point of this stage is speed: get the massing on screen, then spend the budget where a viewer will look.

Stage 3: normalize the scene before you beautify it

•  Units: meters.

•  Origin: center of the concourse, at floor level.

•  Axis: Y up.

•  Collections: street, ground, terminal, concourse, platforms, tracks, circulation, equipment.

•  Names: object type plus location plus index. No default cube names.

This sounds boring. It is the difference between a scene someone can edit and a scene someone can only look at. I also lock color management before lighting, because changing it later shifts every material.

Stage 4: separate the cutaway from the full model

Two variants: a full model for camera checks and a cutaway for the final render. Keep the cut plane on a separate object so it can be moved. Cap the ground with a solid section, and give the cut face its own material. Do not boolean the city into pieces you cannot undo.

Stage 5: rebuild what the generator cannot know

Escalators, elevators, ventilation, and track geometry. For this station, 47 escalators and 22 elevators matter here, so I modeled the main banks and the accessible routes, not every unit. I used simple geometry with correct angles. At explainer scale, the path matters more than the tread detail.

Stage 6: light and camera as a handoff package

Three cameras: street entrance, concourse, platform. I named them CAM_STREET, CAM_CONCOURSE, and CAM_PLATFORM. Keep exposure consistent. Include one wide shot and one detail shot per camera. The teammate should be able to render without re-lighting the scene. I also render a low-resolution contact sheet before the final pass; it catches framing mistakes faster than a full render.

Stage 7: export and handoff

Export the scene in the format the team uses, plus a glTF for review. Include textures, a contact sheet, and a README with the selection bounds, units and origin, layer names, known inaccuracies, render settings, what was modeled by hand, and what is still missing.

The README is not paperwork. It is the difference between a scene and a puzzle. Write it for someone who opens the file cold. Name the export with a version and date, not "final".

QA gates

Before handoff, check the platform and track count, the 140-foot depth, and the entrance range. Look for floating meshes, missing materials, inconsistent units, and unnamed cameras. Confirm that the cut plane does not cut through the concourse and that the equipment level connects to the shafts. Render one frame at the target resolution and open it on a second machine. Keep a render of each camera in the handoff folder so the next person knows what done looks like.

What I would automate next

Import, scale checks, layer assignment, and contact sheet generation. Those are repetitive and easy to verify. The cutaway, circulation, and lighting still need a person. A generated base is a starting point, not a substitute for judgment.

The handoff result

My teammate opened the scene, found the concourse in ten seconds, and rendered a test without asking me a question. That is the only benchmark I care about. The model is not survey-grade, but the pipeline is repeatable, and the next station will be faster.

The Brief We Gave Both Tools

The site was a six block area around the corner from our office, chosen because we could walk it at lunch and because we already had measured drawings for two buildings inside it. The deliverable was a base model for a feasibility study: ground, buildings, roads, and trees, usable in Rhino and Revit, plus one visual for a client workshop. Same boundary, same week, same testers.

What We Actually Compared

Not render quality. We looked at five things: how close the geometry came to known dimensions, how much cleanup the files needed, how well the export fit our software, whether a second run produced the same result, and how long it took a junior designer to become useful with the tool. The last one mattered more than expected.

TopoExport: A Base We Could Defend

TopoExport let us choose layers instead of taking everything. Buildings, parcels, roads, water, trees, contours — each came through as its own thing, in formats we could route to the right software: DXF and DWG for CAD, PDF and SVG for exhibits, OBJ and IFC and STL for 3D, with native paths into Revit and Rhino. The terrain mesh and roof volumes were detailed enough that our slope study had real ground under it.

It also told us, quietly, where the data was thin. One corner of the block had older footprints than the rest, and a service road that no longer exists. We caught it because the field visit disagreed with the file. On a site in a city with poorer coverage, that mismatch could have gone unnoticed until much later.

GenAnywhere: A Workshop Tool That Earned Its Keep

GenAnywhere was the opposite experience. Draw the area, let the AI generate, and a model appears. Our first reaction was laughter, honestly, because it looked so much like the neighborhood so quickly. We used it in the client workshop to test three massing ideas on the same block. The client could feel the difference between a courtyard scheme and a bar building in a way a plan never delivered.

The follow up was less fun. Edges drifted between runs, a low garage merged into its neighbor, and the mesh had no feature structure we could filter. Cleanup in Rhino took longer than modeling the massing from scratch would have. That is not a knock on the tool; it is a mismatch with what we asked it to do.

The Handoff Problem

This is where small teams get hurt. Someone exports a model, someone else imports it six weeks later, and the only note is a filename like final_site_v2. When a dimension looks wrong, nobody can say whether the source was a dataset, a generation, or a coworker's manual edit. We lost half a day to exactly that before the trial ended. The geometry was fine. The story around it was missing.

What We Standardized

Four rules came out of the trial. Every imported site file gets a unit and origin check before anything is drawn on it. Every file gets a one line source note and a date. AI generated geometry lives in a folder named concept and is never dimensioned or scheduled. And every project starts with one measured building we can verify against, so we know early whether the base is trustworthy.

None of these rules are technical. They are the sort of thing a team agrees on once and then forgets, which is why we wrote them into the project template rather than a wiki page nobody opens.

The Decision

We kept both, with a clear boundary between them. TopoExport is the first file we open and the last one we check before issuing drawings. GenAnywhere is what we open when the question is still shape, density, or view. Budget wise, we treat the generator as a design tool and the exporter as production infrastructure.

If you are running the same trial, use a site you know by heart. Test the exports on day one, not week two. And time the cleanup, not the generation, because the cleanup is the work.

Why the obvious answers did not work

The sanctuary is an A frame with a steep glulam roof and a floor that steps down four times toward the chancel. It is beautiful and it is a trap: the steps make level seating impossible, the glass wall on the east side bakes the room from ten in the morning, and the only accessible route is a service corridor by the kitchen. Anything we proposed had to answer those three things without touching the roof structure.

Shapezo gave me the building before I had drawings

There is an old print in the church office, but it was drawn before an addition and does not match the building. I outlined the block on the map and Shapezo generated a 3D model of the area, including the sanctuary, the fellowship hall and the houses along Elm. It took minutes and produced the massing I needed to start from: the roof pitch read correctly, and the low link between the two buildings showed up as a single story volume, which is what makes circulation possible.

The geometry is approximate. The stained glass rendered as flat gray, the entry canopy was missing, and the fellowship hall came out wider than it is. I used it for relationships and elevations; anything numeric came from a tape measure and a laser. That split saved a week.

TopoExport for the ground and the parking

The site slopes about five feet from Fourth Street down to the alley, which explains why the accessible parking is at the wrong end of the lot. I pulled the terrain and contours, then drew the parking layout on top of the real grade instead of a flat plane. The result was a short ramp and two restriped spaces near the entry, not a re paved lot. For a nonprofit, that difference is the whole project.

Archshaper for the addition that makes it work

The arts group needed a lobby, a box office, and accessible toilets. Archshaper let me test a small addition against the fellowship hall wall, with a flat roof tucked under the existing eave so it does not fight the A frame. A taller version looked like a mistake from the street. The final scheme is a single story, twelve feet deep, and does not touch the sanctuary structure.

CADMapper for a set the landlord could take seriously

At this point we had a concept and no document. CADMapper produced the site plan with the parcel line, the alley, and the two buildings, and I put the new work on top with dimensions. The property owner took that sheet to a contractor and came back with a number for the first phase, which a napkin sketch does not get you.

PlaceMaker for the seat count

The original question was a hundred and fifty seats. I placed rows of chairs in the sanctuary at full size, kept the aisles at the width the fire code wants, and stopped at a hundred and twelve. That number is now the operating assumption for the business plan, and it came from an afternoon of moving chairs, not a consultant report.

What I would do differently

Get inside the building with a laser measure before generating any context model, because the generated version will be close enough to mislead you. Photograph the existing conditions wall by wall. And test the accessible route before you fall in love with a layout: the corridor by the kitchen was three inches too narrow at the door, and that kills grant applications.

The building is not saved. It is, at least, finally measured, and the arts group has a plan that does not require a miracle.

I used Shapezo as the first step. I selected the dam and its surroundings on a map, then used the AI-generated model to organize the scene. The result helped me decide what to inspect next. It did not become a substitute for drawings, survey data, hydrology, or operating records.

Build the context before the detail

My map selection included the dam face, a wide section of the reservoir, the bridge, the power plant, the downstream river, and the canyon rim. A narrow selection made the concrete structure dominate. A wider selection explained how the water, roads, cliffs, and plant facilities fit together.

I saved the selected area and the generation date with the model. That simple record makes the visual reproducible. It also stops a later user from assuming that a changed scene is the same source.

The aerial view is especially useful for explaining Lake Powell. The branching shoreline and desert mesas show that the dam controls a large regional landscape, not just a pool immediately behind a wall. The downstream view tells a different story: the canyon tightens, the river becomes more prominent, and the dam reads as one vertical element inside a longer geological corridor.

Treat the AI output as a context layer

Shapezo generates a model from the area I frame on a map. That is a useful shortcut for a first spatial conversation. I can point to the reservoir, the canyon, the powerhouse, and the access roads without building every object by hand.

But the model is not the right source for concrete dimensions, embedded instruments, gate positions, turbine ratings, or live reservoir levels. I marked those items as unresolved until a controlled source could be attached. The distinction is not a legal disclaimer added at the end. It changes how I review the image from the beginning.

Give the powerhouse its own model

The powerhouse interior deserved a separate scene. I focused on the long turbine hall, generator housings, crane rails, service decks, and concrete galleries. The image had no people, labels, or invented screens. It was simply a spatial study of an industrial interior.

This separation helped me explain the water path. The reservoir, intake structures, turbines, and river outlet are linked, but they are not interchangeable views. A generated interior can clarify the sequence for a review audience, while plant drawings and maintenance records remain the source for technical decisions.

Use weather to explain operation carefully

I also prepared a storm-after-rain scene with darkened sandstone, runoff channels, and active-looking release structures. It made water movement easier to discuss. I did not describe it as a real event. A visual can show what a condition might look like; it cannot confirm that a gate is open or that a release schedule has changed.

This is where an AI workflow needs a small amount of friction. The more believable the scene, the more important it is to identify its status.

A review package I would hand over

I would deliver the Shapezo context model, verified terrain, facility drawings, hydrologic records, inspection information, and operational notices as separate but linked files. Each would carry a source date, coordinate reference, units, owner, and intended use.

For Glen Canyon Dam, the practical value of AI is not replacing engineering review. It is helping a group see the entire facility and its canyon setting early enough to ask better questions. Once those questions are clear, controlled data can take over. That is the workflow I would keep: select the place, generate the context, label the limits, and verify every decision that matters.

The important distinction is not that one tool is more “AI” than the other. It is where the input begins. Shapezo begins with geographic extent. Meshy begins with a text prompt, a reference image, or a conversation about an asset.

Step one: frame the district with Shapezo

I selected the museum block, tram stop, warehouse lane, sculpture garden, and river overlook. Shapezo produced a broad 3D scene that helped me test relationships before spending time on details. The service court was closer to the public plaza than I expected, and the tram approach created a narrow visual opening toward the river.

That view gave me a better checklist for the next stage. I noted where the visitor path should widen, which building edges need a stronger facade, and where the service route should remain visually quiet. I kept the selected boundary and generation date with the file. The generated scene was context, not a record of surveyed dimensions.

I also tested the district from two camera heights. The aerial view was useful for checking the river overlook and tram approach. The lower view exposed gaps around the service court and made the museum entrance feel too small. That simple camera change helped me decide which parts needed a deliberate Meshy asset and which parts could stay as background context.

Step two: create a small asset kit in Meshy

I used Meshy for a museum entrance canopy, modular display plinths, a bronze sculpture base, warehouse shutters, and a tram-stop shelter. I wrote separate prompts for each asset and kept a common scale reference. When an object needed a controlled silhouette, I used an image reference and changed only the material or surface treatment.

Meshy’s texture tools helped me explore stone, brushed metal, painted wood, and weathered concrete without rebuilding every shape. I still checked roughness, seams, and texture resolution because a convincing preview can hide problems after import. GLB was useful for quick scene tests. FBX and OBJ were useful when the receiving application needed a different material setup.

Step three: make review states explicit

I created three review states: district context, hero assets, and combined scene. In the first state, the Shapezo model carries most of the view. In the second, the Meshy objects are isolated so I can check scale, topology, and texture behavior. In the third, both are visible, but each folder keeps its own source and status.

This structure makes feedback more precise. Someone can ask me to move the service lane without assuming the generated warehouse is final. Another reviewer can ask for a different stone finish on the entrance canopy without changing the district boundary. It also makes it easier to replace a single prop or regenerate the context when the study area changes.

My working rule

I use Shapezo when the design question is about the neighborhood: where the museum sits, how visitors arrive, and how the public spaces connect. I use Meshy when the question is about the asset: what the canopy is made of, how the shelter reads at eye level, or whether a sculpture base works in a close camera.

The two workflows become practical when I keep them connected by a short manifest: map boundary, coordinate notes, prompts, reference images, units, export formats, and revision dates. That record is more useful than a single impressive render because it explains what can be changed and what each model is meant to show.

I would also include a small test scene with one context block and three hero assets. It lets another artist check scale and materials without opening the full district. If the test scene imports correctly, the larger package is easier to diagnose. If it does not, I can fix the source before the review becomes a debate about appearance.