DEV Community: Future Built AI

Reconstructing a Desert Nuclear Site in 3D From One Map Selection

Future Built AI — Mon, 02 Nov 2026 06:41:14 +0000

I build small 3D scenes of industrial sites as a way to study layout. It is cheaper than flying somewhere, and it forces me to notice how infrastructure is arranged. Palo Verde is a good stress test: three reactors, a very large switchyard, a water system that wraps around the site, and almost no vertical clutter to hide behind. This is a build log, not a product review. No drone, no CAD files, no survey. Just public imagery, a map selection, and a lot of orbiting.

Scope and constraints

The goal was a walkable massing model, not an engineering asset. I wanted to answer questions like: how far is the switchyard from the reactors, how much of the site is water infrastructure, and where does the transmission corridor enter the property. Those questions do not need centimeter accuracy. They need correct relationships. I also set a rule: every feature in the model had to be checkable against public imagery. If I could not verify something, it stayed a question rather than a wall.

Picking the bounding box

GenAnywhere takes a rectangle on a map and returns a textured 3D model of the area inside it. The box matters more than any prompt. Too tight, and you lose the transmission corridor that explains why the switchyard is where it is. Too wide, and the plant becomes a small cluster in a sea of desert while the mesh resolution drops. I settled on a box that included the fence line, about a mile of desert to the west, and the first row of transmission towers.

First pass: what the generator infers

It inferred the big primitives well: domes, halls, rectangular cooling towers, roads, and parking areas. It inferred the switchyard as a grid of gray boxes, which is roughly right at a distance. What it cannot infer is function. A low building could be a warehouse, a pump house, or a security post. The model picks a plausible shape and moves on. That is fine for massing and useless for operations. It is also confidently wrong in places: a row of parking stalls became a long low shed, and a drainage channel became a road. Those mistakes are easy to spot from above, and a reminder that the output is an interpretation, not a copy.

Where it breaks

Three failure modes showed up. Thin structures such as pipe racks, fences, and light poles tend to disappear or merge into walls. Repetition gets simplified: rows of identical transformers or parking stalls collapse into a slab. Grade is flattened. The site is nearly level, but the water basins sit slightly below grade, and the generator tends to put everything on one plane. None of these are fatal for a layout study. All of them matter if you care about drainage.

Second pass: reference-driven correction

I exported screenshots of the first model, compared them with satellite tiles, and marked the deltas: a missing pipe bridge, a turbine hall that was too short, a switchyard pushed too close to the fence. Regenerating with those references improved the silhouette. The lesson is that this workflow is iterative. Treat the first output as a draft and budget time for two or three passes.

Time budget

The whole exercise took an afternoon: about forty minutes to define the box and run the first pass, an hour to compare it with reference imagery, and another hour for the second pass and screenshots. Most of that time went into looking, not generating. If I had tried to model every pipe and fence, I would still be at it. The constraint was useful. It kept the model at the scale of the questions I actually had.

What I would do differently

Start with a diagram. Before touching the map, sketch the site as five zones: reactor, turbine, cooling, water, and electrical. Then choose the box to include the transitions between zones, because that is where the layout logic lives. Finally, keep a margin of empty desert in frame. The space around the buildings explains the buildings.

Takeaway

A generated 3D model will not replace a site visit or a proper CAD file. It does something different: it makes spatial relationships cheap to inspect. For a site like Palo Verde, where the interesting information is distance and arrangement rather than detail, that is enough to learn something real. I came away with a better mental map, three useful screenshots, and a longer list of questions than I started with. That is a good outcome for an afternoon.

InfraWorks Model Builder, IMX, and Where the Automation Actually Stops

Future Built AI — Fri, 30 Oct 2026 08:25:19 +0000

I spent two weeks trying to make InfraWorks do something it does not want to do: run unattended. The goal was a repeatable corridor model for a rail extension study, rebuilt from a config file every time the alignment moved. What I learned was more useful than the script I ended up with.

What Model Builder Gives You for Free

Model Builder is the closest thing to an API in the normal workflow. You hand it a name, a coordinate system and a bounding area, and it pulls terrain, roads, buildings and water from open sources into a cloud model. For the rail study I scripted the request side in Python: build the payload, post it, poll until the model exists, then download. That part is boring and reliable, which is what you want.

The Model Is a Database, Not a File

InfraWorks models live in the cloud and sync down. Your automation is really a sync problem wearing a modeling hat. Two of my first three failures were not code errors at all. They were a machine holding a stale local copy and pushing it over a newer one. Treat the cloud model as the source of truth and the local copy as a cache with an expiry, or you will lose an afternoon to a conflict that looks like corruption.

IMX Is the Real Interface

The exchange format that matters is IMX. It moves content between InfraWorks and Civil 3D, and it is the seam where concept meets design. My pipeline ran like this: build context in InfraWorks, export IMX, open in Civil 3D, swap the concept alignment for the surveyed one, export back. The round trip works with caveats. Styles do not survive cleanly, and anything modeled with components rather than native objects tends to return as dumb geometry, which means no editable parameters on the other side.

Where the Script Ends and the Human Starts

There is no supported way to drive bridge design or traffic simulation from a script. I looked, and I asked. The traffic simulation needs a cleaned network, and cleaning a network is a series of judgment calls about how a real intersection behaves. That is not something I want an automated step guessing at. Sight distance is similar: the check is automated, the decision about whether a crest is acceptable is not.

GenAnywhere in the Same Pipeline

GenAnywhere has no pipeline to speak of. Draw a box, get a mesh. For the rail study I used it once, to generate a quick valley backdrop for a presentation slide while the InfraWorks model was still ugly. Export options are limited, the geometry is a surface, and there is no way to query it for lane widths or vertical clearance. As a source of plausible 3D background it is fast and cheap. As a data source it is not one, and I stopped trying to make it into one.

What I Actually Shipped

The deliverable was a Python wrapper around three things: the Model Builder request, an IMX export, and a Civil 3D batch that regenerated plan and profile sheets. The wrapper logs every step to a JSON file so the next person can trace which config produced which output. A full corridor run takes about forty minutes, most of it spent waiting on the cloud and pretending to read logs.
One piece I did automate was validation. A short script reads the exported model and checks that every alignment has a matching profile, that stationing increases, and that no structure pokes outside the clearance envelope we set. It caught a bridge deck that had drifted about a foot low after a profile edit. That kind of check pays for itself because it enforces a rule instead of making a decision.

Advice If You Try This

Version the config file, not only the script. Pin the coordinate system explicitly, because the default is not what you expect on a corridor that crosses a state plane boundary. Check the cloud model's modified time before syncing. And keep a manual path for anything that touches design decisions, because the moment your automation quietly changes a bridge length, you have a much worse problem than a slow build.
InfraWorks rewards automation around the model and punishes automation inside it. Once I stopped trying to script the design and started scripting the handoffs, the whole thing settled down and my weekends came back.

Five Tools, One Closed Airfield: A Repeatable Pipeline

Future Built AI — Thu, 29 Oct 2026 06:06:27 +0000

Kestrel Field is a 96-acre county airport in eastern Iowa that closed in 2011. The town wants nine blocks of housing, forty workshop bays carved out of the T-hangars, a market hall in the maintenance hangar, and a greenway on the runway. I worked it in three weeks with five tools, in a fixed order.
This is the order I used, and what broke along the way.

Fix units and coordinates before anything else. Everything downstream inherits the mess.
Halfmaps for the base map, GenAnywhere for context, Cityweft for streets, Archshaper for massing, CityEngine for rules and counts.
Keep one folder of exports per stage, named by date and stage. You will go back two steps at least once.- The context model caught two problems that plan drawings missed. ## 1. Fix the units first The site is in Iowa State Plane South, NAD83, US survey feet. Half the county data comes in that projection, the other half comes in lat/long, and the old airport drawings are in feet with a local benchmark that nobody can find. I set the project to state plane feet and wrote it in the readme first. Every tool handled that projection, but only because I checked each import. CityEngine will accept a model in the wrong units and generate a district at 3.28 times the intended size. It looks fine until you measure a lot. ## 2. Build the base map in Halfmaps Halfmaps combined the county parcels, a recent aerial, and the two-foot contours into one base map with a slope tint. The site falls eleven feet to the creek, and the flat middle is what makes the runway reusable. ## 3. Box the context in GenAnywhere This is the step I used to skip. The box went around the airfield and four blocks of town beyond the south fence, and GenAnywhere returned terrain and buildings as one context model in a few minutes. It changed the plan. Two things came out of it. The forty-foot control tower shadows the first row of houses in the evening, and the nearest existing homes are a five-minute walk from the terminal. Neither fact shows up on a site plan. Both belong in the brief.

4. Test street networks in Cityweft

Cityweft got the site boundary and one hard rule: the runway stays. Then three schemes came back.
The grid pushed the last row of lots into the twelve-acre floodplain, the loop wasted the runway frontage, and the stepped scheme held the flood line and kept nine blocks.
I exported the chosen scheme as blocks and centerlines, with the 62-foot right-of-way intact through the chain.

5. Mass the buildings in Archshaper

Archshaper took field measurements and a phone photo of each hangar type and produced massing models. The market hall fits inside the maintenance hangar without touching structure, since that building is 90 by 70 feet and column-free. Every T-hangar is 44 by 40 feet and holds three bays comfortably, four if you give up the shared bench.
I tested three roof forms on the hall and picked the flat one with a clerestory, so the trusses stay visible.

6. Write the rules in CityEngine

CityEngine got the nine blocks and a set of rules I wanted to try: two floors, a fifteen-foot setback, lots at forty by a hundred. I wrote them as CGA, ran four scenarios, and compared unit counts and frontage.
The full two-story build produced 158 homes. One story on the west blocks produced 141. The adopted version is 150 homes, taller on the runway edge because that is where the tower shadow lands, so the two constraints helped each other. CityEngine also produced the 320-space parking count and the 1.6-mile trail.

Handoff notes

Layers: BND_SITE, RNWY, TAXI, HGR_T, HGR_MAINT, TERM, TOWER, FP_100, CNTR_2FT.
The runway crown is eight inches at the center. Do not flatten it in the grading model.
The apron drains west through two eighteen-inch culverts. Assume they are half full of silt until someone televises them.
The tower stays. Its footprint is fixed, and two house types are rotated around it. ## What broke My first GenAnywhere box was too tight: I drew it to the property line and got a model with no neighbors. Redrawing it four blocks wide took two minutes; the wrong first attempt cost an afternoon. Cityweft also assumed a flat site by default. The eleven-foot fall is small, but on forty-foot lots a two-foot contour matters. I had to set the terrain reference before generating, not after. What I would automate next The export naming. I ended up with four rounds of files called final, final2, final_use, and final_use_ok. A date and stage prefix would have saved me ten minutes every day and one very confusing review.

Modeling Hyperion from a Map Box: Tanks, Pipes, and the Process Graph Behind the Plant

Future Built AI — Wed, 28 Oct 2026 06:17:53 +0000

I spent a weekend trying to turn the Hyperion Water Reclamation Plant into something a computer could reason about. The first attempt was a mesh. The second was a diagram. The third, which finally worked, was a graph. The difference matters when you want the plant to answer a question, not just pose for a picture.

What the box gives you

I started with GenAnywhere, selecting the site, the shoreline, and a piece of the access road. The generated model came back quickly: circular tanks in rows, rectangular basins, buildings, and the coastal edge. As a site plan, it was useful. It gave me a boundary and a sense of the scale.
Then I tried to trace a drop of water. Every tank was a shape, every pipe was missing, and the ocean had no connection to the plant. A generated model is a shell. It is not a process model, and it is not a survey.

A plant is a directed graph

The useful abstraction is a directed graph with unit processes as nodes and flows as edges. Raw influent enters at the headworks, where screens and grit removal come first, then primary clarification. The primary effluent goes to aeration basins, then secondary clarifiers, then disinfection, then the outfall. A side stream leaves primary and secondary treatment as sludge and enters a separate solids train: thickening, digestion, dewatering, hauling.
Once the plant is a graph, questions become queries. What is the retention time in the aeration basins at 250 million gallons a day? Which units are bypassed during a storm? How much capacity is lost if one clarifier is drained for maintenance? A graph can answer these, as long as the nodes carry the right attributes.

Capacity is not one number

Hyperion is often described by a single figure, but the plant has several. The design average is around 450 million gallons per day. Peak wet-weather capacity reaches much higher, near 800 million. Actual dry-weather flow is usually closer to 250 million. Those numbers belong to different operating states. A model that stores one will often be wrong.
Each unit has its own limit. A clarifier is limited by surface overflow rate and solids loading. An aeration basin is limited by oxygen transfer and mixed liquor concentration. A digester is limited by volatile solids loading and detention time. The plant's capacity is the minimum constraint along the path, not the nameplate on the gate.

The second network: solids

Most treatment models focus on water and forget the sludge. At Hyperion, the solids train is a network of its own: primary sludge, waste activated sludge, thickened feed, digested biosolids, and dewatered cake. Gas from digestion can be burned for heat or power. If your model does not represent solids, you cannot explain why a storm changes the plant's energy balance or why a digester upset shows up days later.
I treat each solids stream as an edge with a solids concentration, a volatile fraction, and a flow. The nodes are thickeners, digesters, and dewatering units. The mass balance has to close at every node. When it does not, either a sensor is wrong or a valve is open that should not be.

The outfall boundary

Treated effluent exits by a five-mile outfall that reaches Santa Monica Bay. A smaller stream, roughly one-tenth of the total, is diverted to West Basin for further treatment and reuse. The outfall and the reuse plant are two different boundaries, and they need separate accounting. If you lump them together, you cannot answer the question a water manager asks first: how much is available for reuse?

Three checks before you trust the model

First, check the flow balance. Influent minus effluent minus solids withdrawal should match storage change within a small tolerance. If it does not, stop and find out why.
Second, check the unit count. If your model has three secondary clarifiers and the plant has more, the capacity calculation is already wrong. Generated geometry is a start, but the count must come from an asset register or a site visit.
Third, check the time constants. A clarifier responds in hours. A digester responds in weeks. A model with one time step for both will produce confident nonsense.

Where the box stops

I still use GenAnywhere at the start of every model. It gives me the footprint, the tank layout, and a quick way to explain the site to a newcomer.
But the box cannot see the pipes, the flow directions, the sensors, or the permits. Those come from drawings, operations data, and conversations with the people who run the plant. The generated model is the outline. The graph is the plant.

From Halfmaps Exports to Unreal and a 3D-Printed Site Model

Future Built AI — Tue, 27 Oct 2026 03:15:00 +0000

The site is a general aviation airfield on the edge of Wichita, surrounded by hangars, a drainage channel, and an industrial park with more apron than building. The design team wanted a walkable Unreal scene for a review and a printed relief model for the wall. I had the airfield boundary and one week.

The Deliverables

Three things had to come out of the same source: a GLB for Unreal, an OBJ for Rhino sections, and a 3MF for a 1:1500 print. Same boundary, same origin, same units. If those three drift apart, the review turns into a conversation about file management instead of the site.

Step 1: Frame and Export

I drew a boundary wider than the airfield so the approach road and the drainage channel came along. Halfmaps built the scene from map data and kept buildings, roads, and terrain on separate layers. I adjusted hangar heights to match the tallest roof I could see in the imagery, then exported GLB, OBJ, and 3MF without changing the boundary or the origin.
Each format left with a different job. GLB carried materials and worked as the Unreal import. OBJ carried clean geometry into Rhino. 3MF went to the slicer. The scene was not a survey, and I noted that in the manifest before anything else.

Step 2: Clean the Mesh

The GLB opened in Blender with a few non-manifold shells and some doubled vertices along the apron edges. Merge by distance and a recalculate normals pass fixed most of it. I did not decimate the buildings, because the Unreal target was a workstation, not a phone. I did decimate the tree geometry, which arrived heavier than the site deserved.
The 3MF needed a different pass. Thin canopies and open-bottomed hangars are fine on screen and fatal in a slicer. I checked for holes, thickened two roof shells, and exported again. The print file is its own artifact; it is not the render file with a different extension.

Step 3: Build the Unreal Scene

Terrain came in as a landscape, buildings as static meshes, roads and water as separate actors. I kept the layer logic from the export, because a reviewer who can hide the hangars can see the drainage channel. The first build ran at 28 frames per second. Halving the texture size and cutting the tree instances by a third got it above 50.
The apron material needed one fix. The default road surface read as fresh asphalt, which made the whole airfield look newer than it is. I darkened it and added a roughness variation. None of that changed the geometry.

Step 4: Print the Relief

I scaled the 3MF to 1:1500, checked the bounding box against the known runway length, and split the model into two tiles that fit the bed. The print took six hours. The drainage channel is the best part of it, a thin dark line running the length of the board, and it started an argument about where the new taxiway should go.

Step 5: Test GenAnywhere Against the Same Base

I handed GenAnywhere the identical boundary and asked for one model. It came back in about a minute with a plausible airfield: hangars, a tower, a row of trees. It also moved two hangars, widened the runway, and turned the drainage channel into a pleasant creek.
I generated it a second time and the tower moved. That settled the question. The images went into a reference folder for mood, and none of the geometry entered the Unreal scene or the print.

Failure Log

My second 3MF came out with different units than the OBJ, because I changed a setting while re-exporting after the mesh cleanup. The apron edge produced a non-manifold seam. The first Unreal build was texture-bound. And the generated model changed between runs, which is acceptable for a reference and disqualifying for a base.

What I Would Script Next

A small script that opens each export, checks the bounding box against the runway length, counts layers, and writes a manifest with the source date and units. I do not need it to repair geometry. I need it to stop me before I import the wrong file into a review scene.
The review went well. The drainage question was answered by the printed model, and the character question was answered by two GenAnywhere images. The base did the measuring. The images did the arguing.

A Civil 3D and InfraWorks Pipeline for a Mill Town Reuse Plan

Future Built AI — Mon, 26 Oct 2026 05:37:31 +0000

A planning-level site package for a 310-acre paper mill property, assembled from a town survey DGN, an exported terrain mesh, Civil 3D grading, an InfraWorks scene, and a generated context patch for an unsurveyed parcel. The technical risks were coordinate registration, vertical faces in the terrain, and generative geometry leaking into schedules.

Inputs and scope

Winslow Falls needed existing conditions, a ground surface, a context model, and three housing options for a town meeting. The property includes a 41-acre industrial yard with 18 buildings, a dam and canal, and 96 mill-era houses on the hill. The town supplied a survey DGN plus sixteen spot elevations; the northern 70 acres had no survey.
The stack: MicroStation for base mapping, TopoExport for terrain, Civil 3D for surfaces and grading, InfraWorks for context, and GenAnywhere for the unsurveyed area. Nine weeks, one model, five different kinds of truth.

Base mapping

The DGN came with boundary and deed lines. I added a 1994 aerial, the mill's plan set, and parcels as references, then traced footprints, canal edges, and the dam crest. Building and water features went onto separate levels, and the coordinate system went into both the file name and a drawing note.
Only the master file was edited. Everything else referenced it. This kept the layer tree predictable and made the survey the single authority for boundary questions.

Terrain

TopoExport accepts a drawn boundary and returns the ground inside it. I traced the property, enabled contours and waterways, and received an OBJ mesh with a separate DXF vector file.
Two things needed checking before use:
• Vertical match: the flat yard checked within eight inches of the survey shots, using two-foot contours.
• Vertical faces: the canal wall arrived as a slope, because a TIN cannot store an overhang. I retained the surveyed wall line for design at the water.
The export used local coordinates. I registered it to two survey monuments before bringing it into Civil 3D.

Surfaces and grading

Civil 3D rebuilt a TIN from the DXF vectors and the sixteen elevations. From there I created two street alignments, profiles, a storm network to the river outfall, and a terrace for housing.
The first mass haul came back with a cut surplus above twenty thousand cubic yards. That is a design warning: the terrace was higher than the ground could support without importing fill or building walls. At three feet lower, the cut and fill nearly matched, and the main road left the regulated floodplain. The yield settled at 130 lots.
Existing and proposed surfaces used different styles, and the floodplain was labeled on every exhibit. Anyone reviewing a plan sheet could see the change without opening the model.

Context

InfraWorks assembled the terrain, mill structures, proposed streets, and tree cover. Its job was the public meeting: park views from the bridge, the relationship between new streets and old houses, and the visual edge between the mill yard and the river.
I did not derive any quantity from it. The town engineer received Civil 3D outputs for numbers and InfraWorks imagery for communication, with the distinction stated in the meeting.

The generated patch

The northern parcel had no survey or recent aerial. In GenAnywhere I sketched a rectangle on the map; the service synthesized terrain and building massing inside it. The geometry went onto a layer named ai_context and was excluded from lot counts, earthwork, and cost.
The patch served its purpose in context views and failed in detail. One generated run placed driveways across wet ground. The layer name and a date in the file were the only things preventing that content from being mistaken for survey.

Failure modes

• Local origin: the terrain export did not share the town's coordinate system. Fixed by registering to two monuments.
• Vertical wall: the TIN could not represent it. Fixed by using the surveyed line near the canal.
• Generative leakage: AI buildings looked like real ones in a PDF. Fixed with a dedicated layer and a written exclusion.
• Visual authority: a good InfraWorks frame can silence a room. Fixed by stating the tool's role before showing it.

Handoff

Survey DGN with coordinate system and reference list.
Terrain export with registration points documented.
Civil 3D surface, alignments, and mass haul.
InfraWorks scene marked as communication only.
GenAnywhere patch as a dated context layer.
A one-page note describing what each layer is not. The board selected the 130-lot option and moved a road out of the floodplain. The pipeline did not invent that outcome; it forced the tradeoff into view early enough to change it.

Below Grade, Above the Grid: Georeferencing a Grand Central Madison Model

Future Built AI — Fri, 23 Oct 2026 07:51:10 +0000

The first model looked convincing and was wrong by about forty meters. The station sat under the right avenue at roughly the right depth, but when I laid a street map over it, the entrances landed on the wrong blocks. The mesh was fine. The reference frame was not.
That is the step map-to-3D work tends to skip. A generated scene can look correct alone and still be useless for measurement, sections, or overlays. Before adding an escalator, I had to decide where the model was, what zero meant, and which way was up.

What the source gives you

GenAnywhere turns a polygon I draw on a map into a massing model of the buildings and terrain. It is a scene, not a survey. There is no construction datum, no legal coordinate system, and no guarantee that the origin means anything. Those are my decisions.
The goal is not survey accuracy. The goal is a model that can answer simple questions without lying about scale.

Horizontal control

A web map is usually geographic, with coordinates in degrees. A 3D scene wants linear units. Converting between them changes the shape of the site slightly, and that difference matters when the model has to line up with a street grid.
For this site I used a projected coordinate system for New York State Plane, Long Island zone, and kept the scene in meters. I wrote down the projection and the local origin: the middle of the concourse, on the floor slab. The origin is arbitrary, but it is documented.

Vertical control

Vertical is harder. The street has one datum, the station another, and the drawings may use a third. The concourse is about 140 feet below Park Avenue, or 42.7 meters. That is a check, not a coordinate.
I set the concourse floor at zero and recorded the offset to the street. Then I checked the platform level against the known depth. When the massing came in too shallow, I adjusted the below-grade volume, not the whole scene. The street grid stayed fixed, because that is what a reader uses to orient the section.

Axis and bearing

Most 3D tools assume Y is up. Most GIS data assumes Z is up. A model imported without checking that convention will lie on its side. A model rotated to the wrong bearing will look almost right.
I tested the axis with a ventilation shaft that runs toward the street. If the shaft points sideways after import, the convention is wrong. I checked the bearing against the Manhattan grid and recorded the rotation. One degree is invisible in a screenshot and obvious in an overlay.

Three checks

Before adding detail, I verified three things: the doors fall between 44th and 48th Streets, the layout has eight tracks across four platforms, and the concourse sits about 140 feet down. If a model fails one, stop and fix the reference frame first. Detail makes a georeferencing error harder to see, not easier.
I also kept a short control-point list: a known street corner, the concourse center, and the top of the ventilation shaft. Each has a scene coordinate and a note. That list is worth more than a prettier mesh.

Keep the shell separate

The generated model is a shell: envelope and terrain, almost nothing underground. I put the platforms, escalators, tunnels, and equipment in separate collections and left the shell alone. If the shell is right and the fit-out is wrong, the error is local. If everything is merged, every fix becomes a rebuild.

What the tool cannot know

GenAnywhere does not know which door is open at night, which escalator is running, or how long a walk feels with a bag. It does not know construction sequence or the difference between passenger space and back-of-house. Those are survey, operations, and experience questions.
What it does give you is a credible massing in minutes. Georeferencing is what turns that massing into something you can measure and hand off.

The hour that saves the week

The fix took about an hour: projection, origin, axis, three checks, and notes. After that, every addition landed in the right place. The model stopped being a picture and became a reference. A section cut is only useful if the thing you cut is where you think it is.

Archshaper vs GenAnywhere: Geometry, Formats, and the Handoff to Revit or Rhino

Future Built AI — Thu, 22 Oct 2026 06:30:49 +0000

The project was a mid-block redevelopment in a city with a good GIS portal and a survey that would not arrive until the following week. My job that Thursday was not design. It was to make sure the site model we handed to the Revit team had the right origin, the right units, and enough context to survive coordination. I tested both tools against that job.

The Handoff Is the Real Test

A site model is only useful if the next person can open it without a phone call. That means predictable units, a sensible origin, geometry clean enough to snap to, and a format the receiving tool reads. It also means knowing which parts are measured and which are inferred. Most comparisons skip this and talk about the pictures.

Archshaper: A Map With an Export Contract

Archshaper starts by locating the project area, then lets you control layers: buildings, roads, water, green space. You can restyle those layers and choose from several visual styles. The 2D output is meant for boards, presentations, and project documents, and it stays at true scale. The 3D scene adds terrain and surrounding buildings, enough for early spatial study and massing without pretending to be a BIM authoring tool.
The export side is explicit. 2D goes out as PDF, SVG, or DXF; 3D as GLB, OBJ, or Rhino 3DM. PDF for review, SVG for layout, DXF for CAD, GLB for viewers, OBJ for mesh work, 3DM for Rhino. The preview is free and exports use credits, with no fixed subscription. The trade-offs are clear: browser-only, dependent on underlying map data, and unable to invent what the data never captured.

GenAnywhere: A Generative Face for the Block

GenAnywhere has a smaller interface idea: select a box on the map, let the AI generate a 3D model. It is quick, and the first result often reads well. Roofs have plausible pitches, the street edge feels occupied, and the massing has enough variation to start a conversation. For a review where the question is whether a block wants a tower here, that is a real contribution.
From a pipeline perspective, the output is a generated mesh, not a layered record. You cannot keep roads and hide buildings, and the file does not say which surfaces came from data and which were guessed. Run the same box twice and the geometry can change; small structures appear and disappear. The model also arrives without provenance, so scale and orientation have to be established first.

Units, Origin, and the Ten-Minute Sanity Check

I opened the Archshaper DXF in CAD and checked a curb-to-curb dimension against the survey. It matched. The GLB came into Rhino at a sane size, though I still set units before import because my template defaults to feet. The 3DM opened in Rhino cleanly, which saved time downstream.
The GenAnywhere mesh needed a different ritual. I picked a known building face, scaled the model to it, then checked two other dimensions. The first pass was off. After correction it was usable as a visual underlay, but I would not dimension from it. That is less a criticism than a property of generated geometry. The check is part of the job.

Where Each Belongs in the Pipeline

Archshaper belongs upstream of documentation. It produces the measured base, the layered context, and files that keep their scale when they move. It is where the site becomes an object with a known origin. GenAnywhere belongs beside the design conversation, before the team agrees on a massing. It produces options, not records, which is legitimate as long as nobody forwards it as a survey.
A workflow that worked for us: build the base in Archshaper, export DXF and GLB, then generate two or three massing studies in GenAnywhere. We never merged the AI mesh into the base. We rebuilt the chosen idea on the measured layers, using the generated model as a reference. The Revit team got a clean origin, the landscape team got separate layers, and the renderer got a GLB that did not need rescaling.

What I'd Tell the Next Person

Decide what the file is for before choosing the tool. If it must be measured, opened, and trusted by someone else, start with the layered map and its export formats. If it must be discussed, questioned, and thrown away by lunch, start with the generator. Neither replaces a survey or a designer; they remove two different kinds of waiting.

Five 3D Site Modeling Platforms, One Geo Data Pipeline: Halfmaps, CityEngine, OpenRoads, GenAnywhere, InfraWorks

Future Built AI — Wed, 21 Oct 2026 05:46:55 +0000

I pushed the same 300-acre district through five modeling platforms and measured what came out the other side. Not render quality — file hygiene. This is the comparison I wish I'd had before wiring imports at 11 p.m.

TL;DR

• Map-first tools (Halfmaps, GenAnywhere) deliver context in minutes, but the output is a starting mesh, not engineering data.
• CityEngine is the only one where the model is code, which is both its best and worst quality.
• OpenRoads owns alignments and terrain; everything else is a guest.
• InfraWorks aggregates; it doesn't author.
• Your real bug will be units, not geometry.

The harness

One bounding box, one State Plane zone in feet, one vertical datum. Inputs: parcel polygons, footprints with a height field, a coarse DEM, and road centerlines. Then I asked each platform for a context model and, where possible, a scripted rebuild from the same inputs. Two are built for scripted runs. Three assume a human at a viewport.

Input contracts

Halfmaps
Takes an extent and layer selection, returns vector and mesh exports. There is no project file, which is liberating until you need last Tuesday's export again. I encode extent and date in filenames because there is nothing else to diff.
CityEngine
Wants attributed polygons plus a rule file. Shapefiles, geodatabases and OSM extracts all work. If the height field is empty, CGA will invent one — useful and dangerous in equal measure.
GenAnywhere
Inverts the import step. Instead of loading data, you draw a box over a neighborhood and let the model generator fill it with buildings. Downstream it behaves like a mesh keyed to a bounding polygon, with no attribute schema, so floor counts have to be inferred.
OpenRoads
Expects terrain and civil features, not building meshes. LandXML, DGN and point data are the natural inputs. Hand it a conceptual mesh and the afternoon disappears into triangulation fixes.
InfraWorks
The most permissive importer here: FBX, OBJ, SHP, LandXML, IMX, point clouds. Permissive is not precise — disagree about units and it will rescale your site without complaining.

Output formats and downstream friction

Halfmaps' DXF was CAD-clean and its GLB viewer-friendly, but neither carried semantics, so building IDs vanished at the door.
CityEngine exports glTF, FBX, OBJ or USD depending on version. Attributes from the rules can ride along if you plan for it. Retrofitting metadata after export is miserable.
GenAnywhere returns one generated mesh set. Fine for massing, weak when per-building identity matters.

OpenRoads is the opposite extreme: rich civil semantics, but the route to a web viewer needs an exporter and usually decimation.
InfraWorks is built to hand off, and its exports are review-grade rather than design-grade.

Automation

CityEngine wins outright. CGA plus its Python console means a rule change can rebuild forty blocks without my hands on the mouse. On repetitive typologies that repays the learning curve.
OpenRoads has a real SDK, but it is civil automation: templates, corridors, plan production. Not a batch mesh pipeline. InfraWorks scripting leans toward visualization. Halfmaps and GenAnywhere are web flows, not API-first services.

The units and CRS bug that cost me a week

CityEngine's scene was in feet. glTF is unitless, and the importer assumed meters. The buildings arrived 3.28 times too tall and offset from the terrain. Nothing crashed. It just looked like bad design.
We caught it in a section, not in the viewer. Since then every pipeline gets a checklist: source CRS, vertical datum, export units, importer assumption, and a 100-foot test cube. That cube has saved me more time than any plugin.

A pipeline I would keep

Halfmaps or GenAnywhere for extents and massing, on their own layer, labeled conceptual. CityEngine where the district repeats and the rules are worth writing. OpenRoads for the corridor, with real survey. InfraWorks to assemble the room.
The handoffs are the work. Name files with extent, date, CRS and units, and keep a manifest. The moment generated geometry gets imported as truth, your sections start lying.

Takeaways

The platforms are compatible if you treat formats as contracts. The expensive part is not the license; it is the week lost to a silent conversion.

What the Bonneville Lock Actually Controls, System by System

Future Built AI — Tue, 20 Oct 2026 02:23:49 +0000

I first read about the Bonneville lock as a building: a long concrete box with two gates. The more I looked, the more it seemed like a control system, and a strict one. Almost everything interesting is sequence and interlock, not concrete.

Four things the lock has to hold at once

Water level
The chamber has to match the lower river before a vessel enters, and match the upper pool before it leaves. At Bonneville that means moving an enormous volume of water through valves and culverts, using nothing but the head difference between the two pools. There is no pump in the normal cycle. The upstream pool is the pressure source, and the control system decides when to open the connection and how fast.
Gate position
The gates are miter gates: two leaves that meet at an angle pointing upstream, so the water pressure pushes them closed and the seal does not depend on the motor. That is one of those designs where the load helps you. The machinery opens the leaves; the water holds them shut.
Vessel position
A ship in a filling chamber wants to move. The lock controls that with floating bollards that travel in slots as the water rises or falls, keeping mooring lines short and the vessel roughly in place. If the lines go slack, the tow drifts; if the water comes in too fast, the surge loads the lines. The fill rate is a vessel-safety parameter as much as a hydraulic one.
Sequence
The system must never have both ends open at once, and should never move a gate against a pressure it was not designed for. That is what interlocks are for: valve position, gate position, water level, and vessel presence all feed a controller that enables or blocks the next step. In a 1990s refit this logic lives in PLCs; before that it lived in relay logic and operator discipline.

What can go wrong, and what it costs

• A gate leaf that does not seat. The chamber leaks, the cycle slows, and the maintenance window shrinks. The seal is a wear item.
• A valve or culvert problem. Filling slows, and every delay propagates to the tows behind it. River traffic is a queue; the lock is the server.
• A bollard fault. A tow comes loose during a fill. It gets attention because it is visible.
• A sensor or controller fault. Operators fall back to manual indications. The lock still works; throughput drops.
None are exotic. They are why a 90-year-old machine needs a maintenance budget and a trained crew, not a monument sign.

The fish ladder is a second control problem

The ladder runs on the same river with an opposite objective. Instead of still water, it needs a continuous, predictable flow that fish will follow, stepped up through a series of pools. Each weir has an orifice and a spill crest, and the hydraulics must stay within a range the fish accept.
The metrics differ. A lock is judged on cycle time and availability. A ladder is judged on passage: how many fish get through, how quickly, with what delay. The counting station is the sensor, and the numbers are published. If the lock is a queue, the ladder is a funnel, and they are tuned by people who care about different numbers.

Power sits in the same river

Two powerhouses use the same drop. Every cubic metre through the turbines is a cubic metre that does not go over the spillway, through the lock, or down the ladder. The allocation is a daily decision, constrained by fish passage, navigation schedules, and load. One river, three customers, and a control room that has to satisfy all of them with the same water.

Seeing the layout before reading the numbers

I boxed the site in Shapezo, which generates a 3D model of a region selected on a map, and placed the lock, spillway, powerhouses, and ladders on one surface. Layout shapes the operating logic: which ladder sits nearest which powerhouse outfall, where the juvenile bypass returns, how a tow lines up with the guide walls.

What I would log first

Water level at each end, gate and valve positions, fill and drain duration per cycle, bollard load where instrumented, and the gap between commanded and achieved cycle time. Those five series would tell you more about the lock's health than any inspection report, and they are what the crew already watches.
The concrete is impressive. The sequence is the engineering.

Tripo3D vs Shapezo: Five Checks Before Shipping an AI 3D Scene

Future Built AI — Mon, 19 Oct 2026 07:39:12 +0000

The fastest way to find a problem in an AI 3D workflow is to hand the files to someone else. A model opens at the wrong scale, a texture disappears, or a context scene is treated as production geometry. I built a fictional American science museum environment to compare Tripo3D and Shapezo and organized the result around five checks I would run before a handoff.
Tripo3D creates individual models from text or image references. It also supports texture generation, segmentation, retopology, low-poly processing, rigging, animation, and common exports such as GLB, GLTF, FBX, OBJ, STL, USDZ, and 3MF. Shapezo creates a map-selected area as an AI-generated context model. Both can appear in one scene, but their files should not be managed as if they have the same status.

1. Freeze the context boundary

I selected the museum, a parking structure, a tram stop, a river walk, and three city blocks in Shapezo. I saved the selected rectangle, date, and source notes with the export. That makes it clear what the context model is supposed to show and gives the next person a way to identify a refresh.
I kept the museum context separate from the Tripo3D asset folder. The latter contained a planetarium dome, an exhibit case, a ticket kiosk, and a maintenance cart, each with its own prompt or reference record.

2. Verify scale, origin, and axes

Before importing anything, I check units, scene origin, vertical axis, and object scale. A small kiosk generated in Tripo3D can become enormous if the receiving application assumes a different unit. A Shapezo export can also shift if its geographic frame is converted without a clear origin.
I use one context block and one test asset as a calibration scene. If those two pieces line up, the larger import is much easier to troubleshoot.

3. Inspect textures and material paths

Tripo3D texture generation can save time, but it does not remove the need to inspect resolution, roughness, UV seams, and file paths. I test GLB for a self-contained preview and then test GLTF, FBX, or OBJ when the receiving tool needs separate material control.
Shapezo surfaces play a different role. I keep them simple and treat them as visual context. They should not dictate the art direction for a close-up exhibit model, and they should not be mistaken for a measured material specification.

4. Check mesh density and replacement options

I inspect polygon count, hidden faces, thin parts, and repeated geometry on every Tripo3D asset. The planetarium dome may need more detail than a repeated display stand. I use retopology or a low-poly pass when the model will appear many times, and I check the result from the intended camera distance.
The Shapezo model gets a scene-level performance decision. I might keep distant buildings, replace them with simple blocks, or load only the context near the camera. That choice depends on the application, not on how detailed the first generated view looks.

5. Record ownership and revision

My handoff manifest includes the map boundary, context version, prompts, reference images, export formats, unit notes, and cleanup decisions. A reviewer can replace one Tripo3D asset without regenerating the museum district. A new Shapezo context can be refreshed without silently changing the asset library.
The practical division is straightforward: Shapezo describes the world around the museum, while Tripo3D supplies objects that deserve individual attention. The handoff succeeds when both are labeled, tested, and replaceable.
One more check is useful when several artists share the scene. I open the package on a clean machine, without the source folders that existed on my workstation. If the context loads but a material is missing, the problem is in the handoff rather than the model itself. I then record the missing dependency, fix the relative path, and repeat the small validation import before sending the complete district.

A Five-Tool Handoff Checklist for a Riverfront Infrastructure Model

Future Built AI — Fri, 16 Oct 2026 02:42:20 +0000

I built a small but complicated test project to see whether five modeling platforms could hand work to one another without blurring their responsibilities. The scenario was an American riverfront district with a replacement bridge, a bus plaza, mixed-use blocks, a floodable park, and a market service yard. The tools were Halfmaps, OpenRoads, CityEngine, Shapezo, and Site3D.
The useful output was not a giant export. It was a short handoff checklist that told the next person what each model meant, what it did not mean, and which values still needed verification.

Check 1: freeze the study extent in Halfmaps

I started in Halfmaps by drawing the project boundary around both bridge landings, the river edge, the warehouse street, and the neighborhood connection. I saved the layer names and the date. This prevented the planning conversation from quietly expanding whenever someone noticed another interesting parcel.
The map became the reference for the other tools. Every export note included the same extent or explained why it was smaller.

Check 2: mark Shapezo as generated context

I selected the same area in Shapezo and generated a model. The map-selection workflow was helpful for a fast shared view of the bridge, blocks, streets, and river edge. It gave the team something spatial to discuss before detailed data was assembled.
My handoff note called it “AI-generated context.” That label matters. The model was not used to set a property line, road grade, flood elevation, or building footprint. I kept the selection boundary and generation date beside the file so a later refresh could be compared honestly.

Check 3: record the CityEngine rules

For the mixed-use blocks, I used CityEngine to generate several urban massing options. The handoff included building-height ranges, setback assumptions, frontage rhythm, and open-space rules. Without those inputs, a screenshot of the city model is hard to reproduce or review.
I also separated the procedural scene from the roadway file. A change to the block rules should not silently rewrite the bridge approach geometry.

Check 4: issue controlled OpenRoads geometry

The OpenRoads package carried the bridge approach alignment, profile, typical sections, corridor surface, and design criteria. I checked the bus-plaza transition, the sidewalk slope, and the tie-in to the existing street. The package also named the terrain source and coordinate reference.
I did not export the whole project first. I sent a small corridor containing the bridge landing, one intersection, and the plaza edge. The receiving team could verify scale, direction, units, and surface interpretation before a larger exchange.

Check 5: keep Site3D grading tied to a source

Site3D handled the market yard and the low river-side ground. I recorded the pad elevation, cut-and-fill assumptions, swales, inlets, pipe route, and outfall. When the service road moved, the grading and drainage changed, so the version note had to travel with the model.
At the public connection, I compared the Site3D surface with the OpenRoads corridor. A small mismatch at the curb was enough to stop the handoff until the responsible model was clear.

The review note I would actually send

My final handoff sheet had five lines: Halfmaps for study extent, Shapezo for generated context, CityEngine for procedural urban form, OpenRoads for roadway geometry, and Site3D for site grading and drainage. It also listed coordinate system, units, source date, version owner, and open questions.
The main lesson was simple. A model is easier to trust when its job is visible. The riverfront project moved faster once reviewers knew which file to use for location, massing, road geometry, or water movement. That clarity is more valuable than making every platform show the same scene.