The Team and the Deadline

I was the architect. The planner cared about street edges and connections. The landscape designer wanted to know where water moved and where trees could survive. Three people, three sets of questions, one site. A single generated model would never answer all of them, but a shared base with switchable layers could keep us in the same conversation.

Day One: One Base, Three Sets of Layers

We located the depot block in Archshaper and built the scene from the map: buildings, roads, water, green space, each on its own layer. The planner spent the first hour toggling layers, checking how the street grid met the old rail alignment. The landscape designer read the grade along the creek in 3D. I tried two visual styles, one diagrammatic and one softer, and exported a PDF so we shared the same reference.

The preview was free, which mattered on day one. Export credits came later, when we needed files. 2D formats are PDF, SVG, and DXF; 3D formats are GLB, OBJ, and Rhino 3DM. Archshaper is online only, and the data is only as good as the local source. The building footprints were reliable; the tree layer was patchy.

Day Three: Feeding the Conversation

With the base settled, we gave GenAnywhere the same block. Draw a box, wait, and the AI generates a 3D model. The planner tested three massing arrangements in an afternoon. The first put too much weight at the corner; the second broke the street edge; the third suggested a lower bar along the creek that none of us had drawn. That third model earned its place.

The landscape designer was less convinced. GenAnywhere's ground read smoother than the site, and a cluster of small sheds disappeared between runs. We treated the models as sketches, not records. When we needed to know whether a route could meet the accessible slope, we went back to Archshaper's terrain. The AI suggested what to test; it did not tell us what was true.

Day Five: The Scale Argument

On day five we caught a scale problem before it reached the board. A GenAnywhere view had been pasted into a layout at roughly 1:500, and the market hall read too small against the street. We rebuilt it from the measured base and kept the generated model as reference. A pretty perspective is not a scale drawing, however carefully cropped.

The Archshaper exports held up. The DXF came into CAD at the right size, the SVG scaled cleanly in the layout file, and the GLB opened in Rhino without a unit argument. I checked the origin anyway. That habit has saved me more than any feature list.

Day Seven: Building the Board

The final board used three things: a plan from the Archshaper base, a perspective rebuilt from the same 3D scene, and a route diagram that began as a GenAnywhere study. The mix was not a compromise. Each piece answered a different question. The base gave us dimensions; the generated models gave us the appetite to try a looser arrangement.

We spent our credits on the exports we actually used. No subscription, no unused seats, which suited a team that may not touch this kind of project again for months. The limits were real: browser dependency, uneven map coverage, and presentation styles that needed editing before they looked like ours. None of them sank the week.

Would We Do It Again?

Yes, with the same order. Base first, options second, rebuild the chosen idea on the measured layers. The rule that saved us was simple: never let a generated mesh become the floor plan. Use it to ask better questions, then answer them with data you can defend. The depot block did not get built, but our entry made the shortlist, and the site plan was the reason.

Start with the deliverable Before a demo, write down what leaves your office: a plan set, a GLB for a web viewer, a LandXML surface, a model for a public meeting. One district can require all four, and no platform covers all four well. Once the list exists, evaluation stops being about interface taste and becomes about handoffs. The five questions I ask before any demo

1. Where does the geometry come from, and who is responsible when it is wrong?

2. What happens to attributes after export?

3. Can I rebuild the model from source data without manually clicking through it?

4. How does the tool behave when the site is larger than the demo site?

5. Who on my team will actually open it next month? Question five kills more purchases than the other four combined. A platform only one person can drive is a single point of failure, however good the output.

How each platform answers them

Halfmaps

Halfmaps is a map-to-geometry web tool: choose an area and layers, then export DXF, GLB, OBJ, STL, or 3MF. The map is the source of truth, so accuracy is capped by the map itself.

Its strength is time-to-first-model. Its weakness is provenance: no project file, no attribute schema. Decide whether you need traceability or only context. For the latter, it's the fastest route I've found.

CityEngine

CityEngine answers the rebuild question best. Rules are code, so a district regenerates when assumptions change — a real advantage on large, repetitive areas.

The cost is expertise. CGA is a language, and someone has to own it. Ask who writes the rules, how they're versioned, and what happens when that person leaves.

GenAnywhere

If your first demo question is "how fast can we get existing context into the file," look at GenAnywhere. You outline a district on the map, and the AI returns massing for whatever sits inside it.

In my test that took minutes, which changed how I scoped the work. The caveat is precision: generated geometry is conceptual and must be labeled that way in any model engineers will touch. Evaluate it on coverage, not survey-grade accuracy.

OpenRoads

OpenRoads Designer is a civil platform first, a site modeler second. It shines when the deliverable includes profiles, corridors, intersections and drainage, and it exposes every weakness in a conceptual mesh.

With no roadway or grading scope, this is probably the wrong purchase. With it, the question isn't whether it can model the site, but whether your team can consume what it produces.

InfraWorks

InfraWorks is an aggregation and review environment: terrain, buildings and corridor concepts in one place, legible to people who don't use modeling software.

Evaluate it on meeting metrics — assembly time, laptop stability, how easily a non-modeler navigates it. Design precision isn't the job it's applying for.

Licensing and team fit

Two are enterprise platforms with seats, deployment overhead and training plans. Two are lightweight web tools one person can adopt on a Tuesday. One sits in between.

Don't price the annual cost. Price the unused seat, and the project that stalls because the only licensed user is on vacation.

A 30-day trial plan

Week one: one district, one deliverable, two tools. Week two: export into your actual downstream software, not a viewer. Week three: hand the file to a colleague and watch where they get stuck. Week four: rebuild from source and compare.

People skip that last step. It's the one that predicts whether the tool survives a real schedule.

Final note

These five aren't competing for the same job. Halfmaps and GenAnywhere shorten the distance from map to massing. CityEngine turns assumptions into rules. OpenRoads carries the engineering. InfraWorks carries the conversation.

Buy for the job you have, and note which job you outsourced to a tool. That note separates a model from a mess.

The wall creates the resource

A dam does one physical thing: it holds water higher than the river below. That height difference is the resource. Everything at Bonneville is a way of spending it. The pool behind the dam is the forebay; the water below is the tailrace. Between them sit a navigation lock, two powerhouses, a spillway, and fish ladders. Each takes water from the high side and gives it back to the low side. The interesting questions are how much, when, and in what order.

The lock spends water to save time

A lock cycle is not free. Every lockage moves a chamber of water downstream without passing through a turbine. Compared with the flow of the Columbia the amount is small, but it is scheduled, and schedules matter. The chamber is 86 feet wide and 675 feet long, sized for a full tow of barges. Watching a cycle, the service is obvious: the chamber fills, the tow rises, the gates open, and the queue moves one step.

What surprised me is how much of the operation is about holding still. The lock does not push a ship up. It lets the upper pool into a sealed room and waits for the levels to match.

The powerhouses spend the drop

The two powerhouses sit on opposite sides of the river. Water enters, turns the turbines, and leaves. The pool is not large enough to store a season of water, so generation follows the river rather than the clock. This is run-of-river: the dam takes its share of the flow as it arrives. Head is set by the pool, flow is set by the river and the operating rules, and output is the product of the two, minus what the other systems take.

The fish spend the flow

Fish passage is where the ledger gets complicated. Adult salmon need to find a ladder and climb a series of pools that feel like a steep stream. Juveniles need to get downstream without going through a turbine. Both consume water that could have been generated.

The ladders are parallel hydraulic structures with their own gates, weirs, and attraction flows, monitored closely enough that the counts are published. The spillway belongs here too, at least for part of the year: spilling water over the top moves juvenile fish with less risk than sending them through the turbines, and it means giving up generation. That trade-off is decided season by season.

The three systems meet in one ledger

Add up the water through the turbines, over the spillway, through the lock, and down the ladders, and you have most of the river. Every increase in one column comes out of another. Spring spill is a decision about fish. A lock schedule is a decision about shipping. A generation target is a decision about the grid. None can be maximized at once.

The dam stopped looking like static civil engineering and started looking like a standing argument about priorities, with concrete holding it in place.

The whole wall on one surface

Before the trip I boxed the site in Shapezo, which generates a 3D model of an area selected on a map, and looked at the arrangement from above. The value was not detail but relationships: the island in the middle, the two powerhouses, the lock at the south end, the ladders tucked between structures.

A flat map showed me the parts. The model showed me how a tow lines up, where the forebay narrows, and why the spillway sits where it does. When I reached the bank, I knew where to stand.

What I would tell a first-time visitor

Start at the downstream lock wall, because the cycle explains the elevation change immediately. Then walk to the spillway and count how many gates are open; that tells you what season the dam thinks it is. Then look at the fish counts posted by the window.

Stay for a full cycle, even if nothing large is waiting. The dam is not a monument. It is a decision about where the water goes next, repeated every few minutes.

The difference is easy to miss in a final render. Both models can sit in the same 3D scene, but they begin with different inputs. Shapezo begins with geographic extent. Tripo3D begins with language or image references for one model. I kept that distinction visible through the whole workflow.

Shapezo set the civic context

I selected the courthouse square, the records building, two blocks of storefronts, the bus stop, and the service lane. Shapezo gave me a broad scene for checking arrival routes and public-space relationships. The bus stop was visually disconnected from the square, and the service lane dominated one side of the courthouse.

That view helped me set priorities before making assets. I marked the places where a canopy could improve shelter, where paving needed a stronger edge, and where the service lane should remain visually quiet. I kept the boundary, generation date, and context status with the export so a later refresh would be easy to recognize.

Tripo3D built the object kit

I generated a courthouse entrance door, a stone memorial plinth, a bus shelter, a records cart, and a set of square planters in Tripo3D. I wrote prompts for material and proportion, then used reference images when I wanted the door or shelter to keep a particular outline. Segmentation and retopology were useful when a first result had parts I wanted to edit separately.

I also made a low-poly version of the planters for repeated use. For the courthouse door, I kept more detail because it would appear in the opening shot. I tested textures under daylight and overcast lighting, then exported a GLB for the combined scene. FBX and OBJ remained useful alternatives for a pipeline with different material requirements. 

Keep review states simple

I created three review states: context, asset kit, and combined district. In the context state, Shapezo carried the visual explanation. In the asset state, Tripo3D models were isolated for mesh, material, and scale checks. In the combined state, both sets were visible but kept in separate folders.

This made feedback more precise. A reviewer could ask to move the bus stop without treating the generated storefront as a surveyed facade. Another person could request a quieter stone texture without changing the map boundary. If the district grew, I could refresh Shapezo and keep the Tripo3D assets available for reuse.

My working rule

I use Shapezo when the question is where the courthouse district sits and how people move through it. I use Tripo3D when the question is what the entrance, shelter, planter, or cart should look like up close. Before sharing the package, I record coordinates, units, prompts, source images, exports, and revision dates.

I keep one small validation scene beside the full district. It contains a context block, the entrance door, and the bus shelter. A teammate can open it quickly, confirm the size and materials, and report a problem before importing the heavier environment. This also gives me a stable place to compare a regenerated object against its earlier version.

That short record is more useful than a single polished render. It tells another creator which parts are context, which parts are editable assets, and which assumptions still need checking. The two tools work well together when their different jobs remain visible.

The result was a practical stack of models. Each platform answered a different question, and each handoff needed a clear warning about what could be measured and what was only for orientation.

Start with a shared map frame

I used Halfmaps to define the working extent and organize the base layers. The frame included both bridge landings, the riverbank path, the warehouse street, the opposite neighborhood, and the bus routes that already crossed the district. I kept notes on access, public space, and environmental limits in separate layers.

This gave me a stable starting point. When the team suggested moving the plaza to the other side of the bridge, I could update the frame without rewriting every downstream model.

Use Shapezo for fast area-level context

Shapezo works by letting me select a region on a map and then generating an AI model of that area. I selected the riverfront blocks, bridge, open park land, and service street. The generated view helped everyone see the same setting while the detailed inputs were still being assembled.

I treated the output as a context model. It was good for asking which edges needed a site visit and whether a pedestrian route was missing. It was not the source for surveyed elevations, property lines, or design geometry. I saved the selection and date with the file so the context could be refreshed without losing its history.

Explore the block rules in CityEngine

CityEngine let me test the urban form around the plaza. I built rule variations for a warehouse-compatible edge, a denser mixed-use frontage, and a lower park-side profile. The comparison focused on street enclosure, open-space continuity, and the visual relationship between the old warehouse and new buildings.

The rule-based workflow was useful because I could change several blocks consistently. I still documented the assumptions. A procedural scene is easier to discuss when reviewers can see which rule created the height or setback.

Develop the transportation model in OpenRoads

The bridge approach and transit street moved into OpenRoads. I loaded the controlled terrain, set the roadway criteria, created the horizontal alignment and vertical profile, and applied typical sections. The 3D corridor showed how the road met the park and plaza, while the profiles and cross sections exposed the actual constraints.

The bus platform was the useful stress test. A small profile change improved the vehicle path but pushed the sidewalk toward a steeper transition. I could review that change in the connected views instead of relying on a single attractive render.

Grade the service yard in Site3D

Site3D handled the space that the roadway model did not fully describe: the warehouse pad, loading access, local grading, and stormwater network. The river-side corner needed a shallow route for runoff. I adjusted the pad and swales, then compared the public connection with the OpenRoads surface.

That comparison also showed why version names matter. A change to the service road affected the Site3D drainage layout but did not automatically become a change to the bridge corridor. I kept the two sources separate and documented the shared tie-in.

A simple review order

My review sequence became: Halfmaps for extent, Shapezo for generated context, CityEngine for urban massing, OpenRoads for roadway geometry, and Site3D for site-level ground work. I asked reviewers to use the model that matched their question.

That order avoids a common mistake: asking a generated city scene to prove a road grade, or asking a corridor model to explain a whole neighborhood. Five platforms can support one project when the boundary, source, coordinate system, units, and status travel with every exchange.