DEV Community: Generate Build

A Practical Workflow for Turning a Map Selection Into a 3D City Model

Generate Build — Wed, 04 Nov 2026 07:23:15 +0000

I build site scale models often enough that I have settled on a repeatable sequence. Nothing here requires a GIS team. It does require knowing what you are modeling for before you start, because the requirements change the workflow more than the tool does.
Step 0: Decide what good enough means
Before I open anything, I write down the tolerance. For a shade question, a half meter height error is fine. For a street wall study, the footprint matters more than the roof. Writing the tolerance down keeps me from chasing detail that will never change the answer, which is the most common way these afternoons turn into weeks.

Step 1: Define the question, then the extent

A rectangle is a scope decision. If the question is shade on one sidewalk, four blocks is plenty. If it is how a new tower changes a corridor, you need the corridor plus a buffer. I write the question down first. It stops the extent from creeping every time I see something interesting at the edge.

Step 2: Collect the reference layer

Before any geometry, I grab what is authoritative: parcel boundaries, building footprints, street centerlines, transit alignments. In Phoenix the light rail line is a hard constraint, and so is the one way grid. Having those as vectors means I can check the generated model against something real instead of trusting how it looks. If a layer is missing, I note it rather than invent it, because an absent vector is easier to explain later than a guessed one.

Step 3: Generate massing from the selection

This is where a tool like GenAnywhere fits. You draw a rectangle on the map, and the system generates a 3D model for that region using AI. The output is massing, not architecture. Roofs are flat, facades are simple, and heights are estimated from imagery. That is fine for site analysis. It is not fine for a rendering you would show a client without a disclaimer.

Step 4: Snap, scale, and sanity check

The first check is always scale. I measure a known block face against the parcel data. If the model is off by more than a few percent, something in the projection is wrong. The second check is height against known buildings. Downtown Phoenix has enough landmarks that a systematic error shows up in about ten minutes.
A quick word on polygon budget
Generated massing is heavier than it looks. Four blocks of low rise with parking structures can still run into millions of triangles once roofs and canopies are included. I merge coplanar faces and drop interior geometry I will never see. If the scene starts stuttering while I orbit, the model is telling me something about how I will use it later.

Step 5: Add the layers you actually need

A model with no data is a sculpture. I add three layers in this order: ground cover, because asphalt and shade drive the heat story; the transit alignment, because it explains traffic; and land use, because it explains why the blocks look the way they do. Air quality goes on top once I have a source I trust.

Step 6: Test one scenario, not ten

The temptation is to run a dozen scenarios. I run one: the change I am actually evaluating. In Phoenix that is usually a height increase or a shade structure. One scenario, compared against the baseline, from the same camera position. Anything more and I stop being able to read the result. The fixed camera is the whole trick, since a new viewpoint can make a change look bigger than it is.

Step 7: Export with the metadata attached

When the scene is right, I export images from fixed camera positions and write down the extent, the imagery date, and the tool version. This sounds like busywork until you come back in six months and cannot remember whether the trees were modeled or invented. The note takes two minutes.
Where this workflow breaks down
Detail. Interior courtyards, facade articulation, and real tree species are all beyond it. It is also bad at change over time, since every model is one snapshot. If those matter, you need survey grade data and a much longer schedule than an afternoon.

What you get for the effort

For block level questions, the workflow gets you to a defensible answer fast. For everything else, it tells you which questions are worth paying a survey team to answer. That is usually the more valuable output.
One more habit: keep the raw selection. When a colleague asks why the model looks a certain way, the rectangle and the generation date are the whole audit trail. Without them you are defending a picture instead of a process.

Survey Data vs Generated Mesh: Wiring Site3D and GenAnywhere Into One Pipeline

Generate Build — Tue, 03 Nov 2026 06:30:12 +0000

The first time I piped a GenAnywhere scene into a Site3D project, the import looked fine and the quantities were wrong. Nothing crashed. Nothing turned red. The earthwork number was simply off by a margin I could not explain until I checked the vertical datum. That was the day generated geometry stopped being a model to me and became a separate data type.
TL;DR: GenAnywhere gives you a fast mesh of a place. Site3D gives you a structured civil model. Validate the seam between them and the pipeline works. Treat them as interchangeable and you will spend a week explaining

why your numbers moved.

Two Very Different Outputs
GenAnywhere is an inference service. You submit a map selection, and it returns generated geometry, typically a textured mesh with buildings, ground and vegetation fused into one scene. There is no schema, no element IDs, and no separation between a wall and the roof beside it.
Site3D is a civil design environment. Its project holds a terrain surface, alignments, profiles, cross-sections, pipe networks, boreholes and strata. Elements have types and relationships. A profile belongs to an alignment. A cross-section samples a surface at a station.
Those are not the same kind of object, and no amount of cleanup makes them the same.

What Site3D Actually Emits

For handoff, the useful outputs are LandXML, IFC and DWG. LandXML carries surfaces, alignments, profiles and pipe data in a form other civil tools can read. IFC carries the model into BIM coordination. DWG covers the drawing side. LandXML is the one I reach for most, because other civil tools open it without a plugin. What matters is that all three preserve coordinates and design intent, not just pixels.

What GenAnywhere Actually Emits

A scene export. Depending on the version, you get a mesh or a set of meshes, sometimes with textures. There is no floor level, no wall type, no property set. If you need to query roof area, you are writing that logic yourself, and you are guessing.
The mesh is also dense. One city block can arrive with more triangles than an entire hand-modeled subdivision. That density looks good in a viewer and hurts in a design file.

The Integration Pattern

I use a one-way pipe. Generate context in GenAnywhere and export the scene. Import it into Site3D on a dedicated reference layer named with the source date. Verify units and georeferencing against a known survey point. Decimate the mesh and separate merged buildings before any design work. Freeze the layer. Design only on native Site3D elements. Replace the reference when a newer scene is available, and never edit it in place.
That order matters. Import before checking coordinates and every later comparison is suspect. Design on the mesh and you inherit its errors.
Validation Steps That Caught Real Bugs
These four checks run after every import. The coordinate check caught a scene that arrived in feet while the project was in meters. The elevation check caught a datum offset of about 1.2 meters. The watertight check caught holes where buildings met the ground. None of these were visible in a shaded viewport.
I also keep a manifest of which layers are measured and which are inferred. It is a plain text file, not a database, and it answers the first question in every review.

Where Each Belongs

Use GenAnywhere when the deliverable is context: a neighborhood shell, a massing study, a visual for a public meeting. Use Site3D when the deliverable is a design: grades, alignments, drainage, quantities, construction documents. The seam between them is a reference layer, not a merge. Direction matters too. Context flows into design, never the other way around. A finished design pushed back into a generated scene gains nothing and creates a second source of truth.

What I'd Ask For Next

I want generated scenes to arrive with metadata: source imagery date, a confidence value per building, and stable IDs. That would let a pipeline treat the output as data instead of decoration. Until then, every generated building is a sketch with a mesh attached.
The pipeline is boring now, which is how I know it works. Context comes in, gets checked, gets frozen, and the design stays separate. The day I stop doing that is the day the model starts lying.

A Repeatable Map to 3D Pipeline for Site Context (and Where Each Tool Fits)

Generate Build — Mon, 02 Nov 2026 07:05:47 +0000

I needed site context for a 220 acre warehouse district study, and I wanted a pipeline I could rerun on the next site without relearning five interfaces. The result is a five step flow: bounds, terrain, footprints, massing, detail. Each tool earns its place at one step, and none of them produces a final model.

The Brief

The study area sits along a rail spur, with about forty buildings, a six foot grade change, and a ring of residential streets. The deliverable was a massing model plus a walkthrough for a public meeting. No construction documents, no survey grade accuracy. That constraint matters, because it decides how much cleanup is worth doing.

Pipeline at a Glance

Define bounds and units.
Export terrain and footprints.
Generate a rough AI massing.
Add context detail where the camera will look.
Export engine ready tiles for review. The order is not accidental. Everything downstream inherits the errors of the step before it, so the cheap checks happen first. ## Step 1: Bounds and Units Draw the study area with a 10–15% margin. Context outside the red line is what makes the site legible. Pick meters or feet before exporting anything and write it in the file name. I lost an hour to a DWG that was in feet while the terrain was in meters; the buildings looked like dollhouses next to the rail corridor. ## Step 2: Terrain and Footprints TopoExport handled contours, roads and curbs. CADMapper gave me a clean footprint and street edge base at a consistent scale. I imported both into the same scene, aligned them at a known intersection, and deleted duplicate linework. The terrain mesh got decimated to about 60% before it was usable. Full resolution was noise at this scale, and it made the ## viewport crawl. ## Step 3: Rough Massing With GenAnywhere You select an area on the map and GenAnywhere's AI generates a 3D model of it, including buildings, roofs and ground. For this site it returned the warehouse sheds, the silos and most of the rail corridor in a few minutes. Treat it as a blockout: check scale, fix obvious extrusions, and do not expect clean topology. I used it to compare three development scenarios before committing to a footprint, then deleted two of them.

Step 4: Detail Pass

PlaceMaker supplied the surrounding streetscape — facades, trees, street furniture — for the two camera paths that mattered. Detail everywhere is wasted geometry. I kept the detailed context in its own layer and switched it off for plan views. The file stayed light, and the review stayed fast.

Step 5: Real Time Tiles

Halfmaps produced tiled city and terrain data that ran in a real time engine without a bake. That is the step that changed the review: people who do not read plans could walk the block and see the silos blocking the river view. The trade off is asset size, so I clipped the tiles to the study area and dropped two LOD levels outside it.

Failure Modes I Hit

• Scale drift. Every import needs one measured check against a known curb or building.
• Z up versus Y up. Terrain and engine exports disagreed; fix it at import, not in the final scene.
• Clean topology is rare. Budget time for merging, welding and deleting stray faces.
• AI confidence. GenAnywhere will happily invent a roof where there is a parking lot. Verify against imagery.
• Naming. site_final_v3_final is how pipelines die.

What I'd Keep

The sequence matters more than the tools. Ground, then footprints, then mass, then detail. Each stage should be disposable. If step 3 is wrong, I want to throw it away without losing step 2.
Two other habits paid off. I kept a text file with the source of every export and the date it was pulled. And I rendered a single plan view after each step, because a top down frame catches bad scale faster than any inspection tool.

Takeaways

A repeatable context pipeline is mostly bookkeeping: bounds, units, layers, names. The interesting tools save hours, but the boring checks save the project. A rough model that runs in real time also beats a beautiful one that nobody opens.
If I were starting again tomorrow, I would spend the first thirty minutes on the boundary and the unit note, not on the model. That is the part I keep getting wrong when I am in a hurry.

Modeling a Seawall From a Map Selection: Geometry, Elevation, and the Water You Can't See

Generate Build — Fri, 30 Oct 2026 08:45:15 +0000

I wanted a 3D model of the Galveston seawall for a small experiment: not a survey-grade deliverable, just something I could rotate and measure while reading about the structure. I picked a one-mile segment near the east end and used GenAnywhere to select the wall, the beach in front of it, and two blocks of streets behind it. A minute later I had a rough model. It was useful, and it was wrong in ways that taught me more than the useful part.

Start With an Extent, Not a Model

The first decision is what to include. A seawall is not a free-standing object; it is the edge of a system that includes the beach, the road on top, the drainage outfalls, and the ground behind it. If the extent stops at the wall, the model cannot show overtopping or ponding. If it runs too far inland, the mesh gets heavy and the wall becomes a thin line.
My box covered about a mile of shoreline and roughly 600 feet inland. That was enough to see the beach width change and to place the road correctly. The generated mesh came back with a terrain surface, a vertical wall, and simple blocks for the buildings. Good for orientation. Not good for anything that depends on the wall's actual profile.

The Coordinate Problem

A model without a coordinate system is a picture. I work in Texas South Central, EPSG:2278, which uses US survey feet, and I treat elevations as NAVD88. Mixing those with web-mercator meters is the fastest way to produce a model that looks fine and measures wrong.
I also keep a local origin near the segment and store offsets, because consumer mesh formats lose precision when coordinates are in the millions of feet. The metadata block I attach to each segment looks like this:
That block is the part a viewer will never see, and it is the part that makes the model usable.

What the Mesh Gets Wrong

The generated wall is a flat extruded ribbon. The real wall has a curved face, a thicker base, construction joints, and a toe that meets rock and sand at an angle. The mesh has none of that. It also has no sheet piles, no weep holes, and no bathymetry. The water in front of the wall is a plane at zero, which is only correct on a calm day.
For my purposes, the flat wall was acceptable as a stand-in, but I had to stop treating it as geometry and start treating it as a symbol. The measurements I trusted were the ones I sampled separately: crest elevation at twenty points, beach width at the same chainages, and the offset between the road centerline and the wall face.

Attributes Matter More Than Triangles

A wall segment is not just a shape. The attributes I care about are the ones that explain why one mile behaves differently from the next:
• Chainage range and length
• Crest elevation and toe elevation
• Wall type and construction era
• Beach width in front of the wall
• Number and location of outfalls
• Inspection rating and last repair date
• Adjacent groin or revetment
Joining those to the mesh by chainage turned the model from a visual into something I could query. "Show me segments where the beach is narrower than 50 feet and the crest is below 17 feet" is a useful question. A pretty render is not.

Putting Water Back In

The most valuable thing I did was add water as a scenario, not a surface. I set still-water levels at 5, 10, and 15 feet above NAVD88 and rendered each against the same wall profile. At 5 feet, the beach disappears. At 10, water reaches the road in the low sections. At 15, the wall is a speed bump.
That is not a prediction. It is a way to see the relationship between three numbers that are usually discussed separately: wall height, surge height, and ground elevation behind the wall. The model made the third number impossible to ignore.

What I Would Do Differently

I would start from LiDAR and surveyed cross-sections instead of a generated mesh, and I would keep the terrain model and the asset model in separate layers. I would also version the assumptions, because a wall model is mostly assumptions: where the toe is, what the beach does in a storm, and how much water arrives from the bay side.
The quick model was still worth the hour. It gave me a frame for the numbers, and it showed me where the frame breaks. A seawall is a simple shape with a complicated job, and any model of it should say which one it is representing.

Civil 3D Alignments to Machine Control: The Data GenAnywhere Can't Produce

Generate Build — Thu, 29 Oct 2026 05:46:21 +0000

Eleven miles of divided highway east of Austin, two new interchanges, 380,000 cubic yards of earthwork, and a contractor who wanted a grading file on a Friday so the dozers could start Monday. That project is where the difference between a design model and a generated scene stops being philosophical. One of them can drive an excavator. The other one can sell a bond package.

The Model With Names

Civil 3D objects are addressable. An alignment has a station and a name. A profile has a vertical curve and a K value. A corridor has a baseline, a region, and an assembly. A surface has a style, a boundary, and a definition. Every one of those can be referenced, queried, and versioned. That matters downstream, because every file format that contractors, reviewers, and other disciplines actually use asks for one of those named things.

Data Shortcuts Are the Real Architecture

The project had five people and one shared model. Existing ground lived in one file, alignments in another, corridors in a third, and sheets were pure reference. Data shortcuts mean I can open a sheet, see a surface at yesterday's state, and not care who has the corridor open. The rule we enforced: nobody edits a surface inside a sheet file. It sounds obvious until you inherit a project where three people each had their own copy.
The shortcut list is also a good index of the project. If a surface has no shortcut, it is a scratch surface and nobody should be building quantities on it. We learned that the hard way when a quantity report used a paste of the design surface that had been made before the last regrade.

What Goes Out the Door

Three exports matter on a job like this. LandXML for the alignments, profiles, and surfaces that the county and the contractor's machine control software can read. IFC 4.3 for the bridge and drainage structures handed to the structural team. And plain surfaces, either as a TIN file or a LandXML surface, for quantity checks by the estimator. Corridors themselves do not travel well, so what travels is the corridor's output surface plus the items that define it.
The grading file that went to the dozers was a surface, a boundary, and a coordinate system, and that is all it needed to be. The operator's screen shows a cut and fill number relative to that surface. If the surface is wrong by a foot, the blade is wrong by a foot, and nobody in the cab can tell.

Quantities Have to Be Auditable

The quantity takeoff used material lists attached to the corridor and volume surfaces between existing and design. 380,000 yards total, split by station range and by material. When the client asked why the north interchange moved 14,000 yards between revisions, I could show the two surfaces and the exact regrade that did it. A number that cannot be traced to two surfaces is a rumor.

Where a Generated Scene Lands

GenAnywhere on the same corridor returned a single mesh. It looked like a highway. It had no alignment, no stationing, no profile, no surface to cut against, and no structure that corresponds to a real culvert. If I sent it to a contractor, the best possible outcome is that it gets used as a pretty picture in the preconstruction meeting. The geometry is not machine control data, and it never will be, because the information that machine control needs was never in the picture.

Automating the Boring Parts

Dynamo for Civil 3D handled the repetitive work: placing culvert structures at fixed station offsets, naming alignments by route and direction, and writing a station-by-station earthwork table into a spreadsheet. The .NET API handled the sheet production, opening each layout, setting the viewport to a station range, exporting to PDF, and naming the file from the sheet set properties. 240 sheets went out in eleven minutes instead of a very long afternoon, and the naming was consistent because a script does not get tired.

Three Checks Before Any Export

A surface check that flags any design surface with a zero-elevation triangle. A station range check that compares the corridor regions against the alignment length. And a coordinate system check, which exists because I once shipped a grading file in state plane feet to a machine expecting meters. The dozer operator caught it in four minutes. I would rather a script caught it in four seconds.

Wiring Five Site Tools Together on a 24-Acre Drive-In Reuse

Generate Build — Wed, 28 Oct 2026 06:39:04 +0000

I modeled a closed Ohio drive-in for a nonprofit market project using MicroStation for the base file, site3d for grading, OpenRoads for the entrance corridor, Meshy for canopy meshes, and GenAnywhere for unsold context. The pipeline held because each tool had one job and one output label.

What the package had to contain

The Comet Drive-In closed in 2012. The buyer, Barlow Community Market, needed a planning package for a 4,800-square-foot market hall in the old concession building, 36 vendor bays, three workshop buildings, 180 parking stalls, a stormwater basin, and a trail spur.
No new topographic survey existed. I had the boundary, a handful of spot elevations, the county road record, and two days on site.

1. MicroStation: the base file

I built one DGN in Ohio South State Plane, units set to feet, and never edited anything else. The boundary, ditch, building footprint, gravel edge, berms, and the concrete screen base each got a level: SURVEY, DITCH, BLDG_EXIST, PAVE, BERM, SCREEN_BASE.
Everything external arrived as a reference: county road centerline, parcel polygons, orthoimagery, and a utility scan from 2009. References stay read-only, which is the only reason the base file still matches the deed after three weeks of edits.
The same file produced the plan sheets, with inferred levels off for existing conditions and on for the planning exhibit.

2. site3d: grading and the basin

site3d runs inside MicroStation, so the design surface started from the same base geometry. The pad for the market hall came up 1.5 feet to meet the road grade. The basin went to 0.8 acres at 4 feet deep. Between the parking rows I used shallow swales rather than inlets and pipe.
The interesting output was the balance: 3,400 cubic yards cut, 3,100 fill. The 300-yard surplus was moved to the pad instead of hauled off. That changed the project cost sheet, not just the drawing.
I also used site3d to set the parking field at 180 stalls. The old drive-in held 380 cars, and keeping those rows would have painted stalls the market cannot fill.

3. OpenRoads: corridor and culvert

The entrance is the part that touches the county, so it needed corridor-grade geometry. County Road 12 runs at 55 mph with a blind rise north of the site. The new drive is 900 feet, plus a 150-foot turn lane. Sight distance has to reach 425 feet.
OpenRoads built the drive, the taper, the culvert crossing at the west ditch, and the shoulder tie-ins as one corridor. Pavement quantities and pipe length came out of the same model, which is the main reason I used it instead of hand-drafting the section.

4. Meshy: assets you can look at

The board wanted to see the canopy before committing to it. There were no drawings, only photos of tensile structures from other markets. I ran three of those images through Meshy and got textured meshes at three spans.
Scaling was manual: I set each mesh against a known door height in the concession building. The results are visually useful and dimensionally wrong. The fabric sag reads deeper than a real tensioned membrane, and the connection details are suggestion-level. I labeled the meshes as reference geometry and kept them out of the quantity takeoff.

5. GenAnywhere: context for the missing parcel

Eleven acres across County Road 12 have no survey and no recent imagery. GenAnywhere works by drawing a polygon on a map and letting the AI generate terrain and buildings inside it. I outlined that parcel, ran it, and got a farmhouse, two outbuildings, a driveway, and tree cover.
The driveway is invented. A real one exists about 200 feet north. I kept the output anyway, because the point was to see the market against a built edge, not to inventory the neighbor's property. It lives on GEN_CTX with a date stamp and stays out of every area and parking count.

Handoff notes

• Keep a single writable DGN and attach everything else read-only.
• Name levels for what the geometry is, not who made it.
• Record the coordinate system in the file name and the sheet title block.
• Recheck any downloaded or generated surface against at least ten measured points.
• Export the corridor and the grading surface together, or the quantities will not match.

What broke

The downloaded terrain read flatter than the lot is, which I caught with the 11 rod readings. The Meshy canopy was 8 percent too tall until I rescaled it. GenAnywhere added a driveway that does not exist. The OpenRoads corridor had to be rerun when the drive moved.
None of these were surprises by the end. Each one showed up because the tool had a bounded job and a labeled output. The failure mode I worry about is the opposite: one model that looks finished everywhere and quietly mixes survey, inference, and imagination in the same layer.

Six Runways, One Footprint: Modeling Denver Airport from a Map Selection

Generate Build — Tue, 27 Oct 2026 03:23:53 +0000

I have been building a small 3D model of Denver International for a side project, mostly to test how much of a large facility you can reconstruct from a map selection. The first pass looked great. The second taught me that a footprint is not a model.

The selection box problem

I opened GenAnywhere, selected the whole airport, and let it generate a massing model. What came back was clean: a cluster of white peaks in the middle, six long runways laid out across a flat plain, and the concourse piers between them. At city scale, it reads exactly like the satellite view.
Then I tried to place the underground train. There was nowhere to put it. The apron was a solid surface, the terminal was a roof with no floor beneath it, and the deicing pads were just more gray pavement. The model was correct from above and empty from the side.
GenAnywhere generates geometry from an area you draw on the map. It is fast and a good first skeleton. It is not a survey, and it does not know what happens below the surface.

A runway number is a bearing

Denver has six runways. The longest, 16R/34L, runs 16,000 feet. The others carry identifiers like 17L/35R, 07/25, and 08/26. Those numbers are not names. They are magnetic headings divided by ten, rounded to the nearest ten degrees, with L, R, or C for position.
That matters in a data model. Magnetic north moves, slowly but measurably, and runway designations are occasionally changed to match. If you use the painted number as a primary key, a routine magnetic update becomes a migration. Store the true bearing, the magnetic variation, and the date range instead. Let the label be derived.

The airport is a graph, not a polygon

Once I stopped treating the airport as one surface, the structure became obvious. The terminal connects to the train. The train connects to three concourse stations. Each concourse connects to gates, each gate to a jet bridge, each bridge to an apron stand, and the apron connects to a taxiway network that feeds six runways.
The train is the part most surface models miss because it runs in a tunnel under the apron. You can have a beautiful terminal mesh and still be unable to answer a simple question: how long does it take to get from a gate in Concourse B to the threshold of 16R at eight in the morning?

Build it in layers

I ended up with three layers. The surface layer holds runways, taxiways, aprons, service roads, and parking. The vertical layer holds the terminal roof, the concourse buildings, the control tower, and the jet bridges. The below-grade layer holds the train tunnel, the stations, baggage handling, and utilities.
Each layer has its own level of detail. At city scale the roof is a silhouette with peaks; at gate scale it is fabric panels and cables. Mixing those levels in one mesh is how models become unusable.

Snow is a network problem

Denver's plow crews can bring a runway back to bare pavement in roughly a quarter of an hour, working in a staggered formation, but that only matters if aircraft can also reach a deicing pad, get sprayed, and rejoin the queue. Runway length is not the constraint on a storm day. Pad capacity and taxi routing are.
A model that stores only runway polygons cannot simulate that. A model with nodes, edges, and capacities can at least ask the question.

Three checks before you trust it

First, check runway geometry against the label. Compute the bearing of the centerline and compare it with the painted designation. If they disagree by more than a few degrees, something is wrong with your source data.
Second, check the terminal-to-concourse link. If your model has no train stations, it is a diorama, not an airport. Every gate should be reachable from the terminal through a known path.
Third, store elevation. Denver's field elevation is 5,434 feet, and altitude affects aircraft performance, runway length requirements, and even the way you interpret a published obstacle chart. A flat zero-elevation plane is a convenient lie.

What the selection box is good for

I still start with GenAnywhere. It gives me the site boundary, the roof silhouette, the runway layout, and enough context to see how the pieces sit on the plains. That saves a day of tracing footprints by hand.
After that, the model has to be rebuilt from better sources: airport diagrams, surveyed coordinates, and operational data. The selection box gets you the shape. The graph gets you the airport.

A PlaceMaker to Unreal Pipeline, With GenAnywhere as Reference Only

Generate Build — Mon, 26 Oct 2026 05:52:04 +0000

The scene was eleven acres along a river: a former lumber yard, a rail spur, a row of houses on the bluff above, and a road that floods once a year. The design team needed a walkable context model in Unreal for a review, not a survey. I had one week, a laptop, and no appetite for tracing roofs by hand. Here is the pipeline, including what did not work.

Scene Requirements

The scene had to run at a usable frame rate on a laptop, show the real grade from the road to the river, include the existing buildings and rail spur, and make the tree canopy legible in a walkthrough.

Step 1: Frame the Area and Pick Sources

I used PlaceMaker's web processing to frame an area larger than the site, so the bluff houses and road approach came along. I took aerial imagery, terrain, building footprints, roads, the rail line, water, and vegetation. I wrote the date and source list into a text file before exporting, because nobody remembers the imagery vintage two weeks later.

Step 2: Process and Export

The processed area came back as separate layers, which is why I prefer it to a single baked mesh. I exported a scene for Rhino and a version for Blender, in one folder with a shared origin. The naming convention was simple: site code, date, area, version, unit. For example, LY_2026-10-19_11ac_v01_m. If the unit is missing, someone will import it in feet and wonder about the doors.

Step 3: Check Units and Drape

In Rhino, I ran three checks. First, the width of the main road against a field measurement. Second, the distance between two building corners visible in both imagery and footprints. Third, the base elevation of every building against the terrain surface. Two buildings sat about a foot low where the terrain mesh crossed a retaining wall. I raised them and noted the edits in the layer file.
The rail line needed the same treatment. It followed the terrain, then floated where the mesh simplified a small cut. This is normal for imported terrain. The fix is a section check before assembly.

Step 4: Assemble the Unreal Scene

The terrain went in as a landscape, with the aerial imagery resampled. The buildings became static meshes with a single material per type. Where vegetation arrived as geometry, I kept the closest trees and instanced the rest. The rail, roads, and water stayed as separate actors so the team could hide them.
The first build looked right and ran badly. The aerial texture was too large for the target machine, and the tree count was optimistic. Halving the texture resolution and cutting the instanced trees by a third got the scene back to a usable frame rate. None of that changed the geometry.

Step 5: Run GenAnywhere as a Control

I ran the same boundary through GenAnywhere. It returned a convincing neighborhood in about a minute, with a plausible bluff, a river, and a rail line. It also moved two houses, widened the road, and flattened the grade near the spur. I ran it a second time and the roofline of the largest building changed again.
That made its role clear. I used two screenshots as art direction for mood and roof rhythm, and imported none of the geometry. The Unreal scene used PlaceMaker data plus my corrections. The generated images stayed in the reference folder, labeled "not to scale."

Failure Log

Units drifted between an export and a reimport. The rail floated over a simplified cut. The orthophoto was too heavy for the laptop. And the AI output changed between runs, which is fine for a reference and fatal for a base.

What I Would Automate Next

I want a small validation script that checks the imported bounds, compares a known dimension, and writes a manifest with units, source dates, and layer counts. I do not need it to fix anything. I need it to fail loudly before a reviewer opens the scene and finds a floating railway.
The review went fine. The floodplain conversation was settled by the terrain, not by a picture. The AI images helped the team argue about character. Neither tool did the other's job.

A Quarry Reuse Pipeline: MicroStation, TopoExport, Meshy, GenAnywhere, CityEngine

Generate Build — Fri, 23 Oct 2026 08:11:31 +0000

A 240-acre quarry reuse plan built with a DGN survey base, TopoExport terrain, Meshy photo-to-mesh assets, GenAnywhere generated context, and CityEngine scenarios. The hard parts were coordinate checks, layer discipline, and not mistaking generated geometry for survey data.

The deliverable and the site

Harlow Quarry is a former limestone quarry and cement plant in upstate New York. The county asked for a planning-level package: existing conditions, a terrain surface, a context model, and three housing scenarios for the east bench.
The site is 240 acres, with 22 acres of water. The plant stopped in 2001 and the county bought the land in 2023. The only new survey data was a boundary file and 12 spot elevations. Everything else came from existing records or had to be labeled as an estimate.

MicroStation: the survey base

The county supplied a DGN in EPSG:2260 with the boundary, deeds, and check points. I kept the survey as the only writable file and attached everything else as references: 1998 orthoimagery, plant record drawings, and parcel polygons.
I traced the rim, rail spur, and building footprints onto separate levels. The level names were plain: SURVEY, RIM, RAIL, BLDG_EXIST, BLDG_INTERP, CTX_GENERATED. Units were set to feet at the start.
This file became the coordinate authority for every later import.

TopoExport: terrain mesh and checks

I outlined the property boundary in TopoExport and enabled contours, waterways, and cadastral parcels. The export gave me an OBJ mesh, a DXF of vectors, and an SVG for a quick exhibit.
The mesh arrived in its own local frame. I scaled and georeferenced it against two survey control points, then compared it with the 12 spot elevations. Most benches were within a foot. The highwall was not. A height field cannot represent a vertical face, so the rock wall read as a steep slope.
I clipped the terrain at the rim and kept the surveyed rim line for safety setbacks. The mesh worked for drainage and trail grading, but not for the rim condition visitors will stand next to.

Meshy: photo-to-mesh, with a label

The crusher house was demolished in 2009. I had 14 archival photographs and no measured drawings. Meshy converted the photographs into a textured GLB mesh. I imported it, scaled it to a known door height, and placed it on BLDG_INTERP.
The result was plausible, not accurate. The roof pitch and conveyor connection were wrong. It worked for an exhibit and a context view, and it did not go into any area or cost calculation. Photo-to-mesh assets are useful for communication, never for dimensions.

GenAnywhere: generated context

The northeast 18 acres had no survey. In GenAnywhere I boxed that corner on the map, and the AI filled it with ground and buildings. The result came back as a separate context model.
I placed it on CTX_GENERATED and used it only for view renders: no quantities, no parcel counts, no grading. The output was fast and coherent, but it invented a few driveways. That is fine for context, not for design; the layer name is part of the deliverable.

CityEngine: rules and scenarios

I wrote a CGA rule file for the east bench: lot width, front setback, height, street width, and a simple roof rule. Three scenario attributes produced 160 large lots, 210 small lots, and a 180-unit cluster. CityEngine rebuilt the masses and street network on each change.
I tracked road length, lot count, tree canopy removed, and walk distance to the trailhead. The 210-lot case had the shortest road and the worst tree loss; the cluster kept a central green.
The rule file mattered more than any render. It let the planning office rerun the scenarios without rebuilding geometry by hand.

Handoff notes that mattered

• Keep one master DGN and never edit a reference file.
• Record the EPSG code in the file name and in the document.
• Put generated geometry on its own level and explain it in the legend.
• Check terrain against at least a dozen surveyed spot elevations.
• Export the scenario rule file with the model, not just the geometry.

What broke

TopoExport's mesh at the vertical wall, Meshy's roof, GenAnywhere's invented driveways, and CityEngine's tendency to produce tidy lots on ground that is not tidy. None of these were fatal, because each output had a label and a job.
The pipeline worked when I stopped expecting one tool to be authoritative everywhere. Survey, terrain, context, assets, and scenarios are five different kinds of data. Treating them as one thing is how a planning model turns into a very confident mistake.

A Map-to-3D Test on Grand Central Madison: What Survives a Cutaway

Generate Build — Thu, 22 Oct 2026 06:50:20 +0000

I had one afternoon to build a cutaway of Grand Central Madison for a short explainer about the LIRR terminal. I did not have CAD, survey data, or a modeling team. I had a browser and a rough question: can a map selection produce a base good enough to explain an underground station?
GenAnywhere turns a polygon drawn on a map into a generated 3D model. That is the workflow I tested.

The target

This was not an engineering model. I needed massing, levels, entrances, platforms, and track count. The station sits 140 feet below Park Avenue, with four platforms and eight tracks, and entrances spanning 44th to 48th Streets. For a cutaway, the relationships matter more than the details.

Step 1: pick the right selection

My first box was too tight: the terminal footprint only. The result had no street context, and the ground plane ended in midair. The second selection covered Grand Central Terminal, the street grid from 42nd to 50th, and a block on either side of Madison. That gave the model enough context to read as a place.

Step 2: audit everything the model claims

Generated models look confident. Check them anyway. I counted four platforms and eight tracks. I measured the depth from the street to the concourse against the known 140 feet. I checked that the entrances fell between 44th and 48th. One escalator bank was missing, and the terminal above was simplified into a single mass. I logged both.

Step 3: cut it open

A cutaway needs a clean section, not a hole. I clipped the model along a plane through the concourse, removed the near half of the city, and capped the exposed ground with a solid layer. The section wall got a darker material so the eye reads it as a cut. This is the step where a generated model starts to look intentional.

Step 4: rebuild the circulation

The escalators do most of the work in this station. There are 47 escalators and 22 elevators, and they connect street, concourse, and platforms. The generated base had a few ramps where the main banks should be. I replaced them with simplified escalator runs at the correct angles and added the major elevator cores. I did not model every unit; I modeled the paths a passenger would recognize.

Step 5: light it and place cameras

Three cameras did most of the work: one at street level looking into the entrance, one at the concourse floor looking across the hall, and one on a platform looking down the track. I lit for readability, not realism. The concourse is bright and even, so a soft overhead source plus bounce was enough. The tunnels needed a darker falloff to keep the cutaway from looking flat.

Step 6: add what generation cannot

The base model does not know how the station was built. For a second scene, I built a tunnel boring machine and a ventilation level separately. The TBM scene is a construction view; the equipment level is a service view. Both are useful for explaining the station, and both needed to be modeled by hand.

Where it holds up

The generated base is good at massing and context. It gave me the street grid, the terminal above, and a rough underground volume in a single pass. For a cutaway that has to read in five seconds, that is most of the battle.

Where it fails

The model is not suitable for clearance checks, structural analysis, or construction planning. Track alignment is approximate. Ventilation shafts and cross passages are missing or simplified. The ceiling and finishes are placeholders. If the deliverable needs to be measured, this is the wrong starting point.

What I would change

I would split the selection: one model for the station and immediate streets, one for the wider Midtown context. I would also do the cutaway before adding any detail, because clipping a detailed model wastes time on geometry that will be hidden.
The time split was lopsided. Selection and generation took under ten minutes. Cleanup took most of the afternoon, and most of that was deciding what to leave out rather than modeling. The cutaway reads better when you remove more than you add.

Verdict

For an explainer, a map-generated base plus an afternoon of cleanup got me a cutaway I could light and hand off. It is a blockout tool, not a survey tool. Treat it that way and it earns its place in the pipeline.

What Comparing TopoExport and GenAnywhere Taught Me About Trusting a Site Model

Generate Build — Wed, 21 Oct 2026 06:06:24 +0000

The fence on the bluff property sat about four feet off the deed line, and nobody could agree which one was right. I had two tabs open and a client meeting in the morning. One was TopoExport, the other GenAnywhere. Both take a box on a map and hand back a site model. By the end of the week I had a simple split in my head: one is for arguments, the other is for drawings.

The Same Box, Two Different Promises

The interface hardly matters. You find the site, drag a rectangle, and wait. What differs is the promise underneath. GenAnywhere promises an interpretation: an AI model looks at the area you selected and generates a 3D version of it. TopoExport promises a transcription: it pulls mapped layers — parcels, buildings, roads, water, trees, contours — and converts them into files you can open elsewhere.
An interpretation is wonderful when the question is open; a transcription is wonderful when it is closed. Most projects contain both kinds of questions, which is why I stopped looking for a winner.

GenAnywhere Is a Very Good First Draft

I framed the bluff lot and a block of neighbors, and the model came back quickly. Rooflines, garages, the way the street bent around the ravine — it read convincingly at a glance. I used it to show the client how much of her view came from the empty lot next door.
Then I looked closely. The back edge of the property had softened into the slope. A shed had become part of the main house. When I regenerated the same area, the geometry shifted a little, like a sketch redrawn from memory. Nothing was wildly wrong. Nothing was quite right either.

TopoExport Is a Pile of Records You Can Check

TopoExport gave me something I could argue with. The parcel polygon, the building footprint, the road centerline, and the contours all arrived as separate things, in formats I could use: DXF and DWG for CAD, PDF and SVG for exhibits, OBJ and IFC and STL for solid geometry. Native output for Revit and Rhino cut out a translation step. The 3D export included a terrain mesh and building volumes with roof forms, so the ravine behind the house was actually a ravine.
It was not perfect. The tree layer was a few years old and still showed a hedge that had been pulled out. The far side of the block had thinner data than the near side. That is the deal with public records: they are honest about what they know, and silent about what they do not.

The Deed Line Is a Warning for Both

Here is the part that took me a while to accept. Neither tool settles a boundary. A parcel layer is a mapped representation, not a legal survey, and an AI generated model is even further from the deed. When the fence question came up, I used the exports to frame the conversation and then told the client, plainly, that she needed a surveyor. The tools made the problem visible. They did not make it disappear.

Two Failures Worth Remembering

The first was drift. Two runs of the AI model on the same box produced two slightly different edge conditions, which is fine for a mood board and useless for a dimension string.
The second was age. Data layers have dates, and nobody reads them until something looks off. I now check the vintage of the tree and building layers before I trust either.

How I Use Them Now

I start with TopoExport and set the ground truth: property line, street, existing buildings, slope. Then I open GenAnywhere and make three or four rough futures, mostly to see what the site wants to become. The AI versions live in a folder called "options" and never get measured. When one option survives, I redraw it on the exported base.

What Accurate Means to Me Now

I used to think accuracy was a number, like being within six inches. Now I think it is traceability. Can I say where this line came from, who published it, and when? TopoExport mostly can. GenAnywhere mostly cannot, and it is not pretending to. That is why I keep both, and why I no longer get annoyed when one behaves exactly like the thing it is.

Batching Parcels Into Site Models: Notes From Building a Due-Diligence Tool

Generate Build — Tue, 20 Oct 2026 02:43:11 +0000

Small acquisition shops look at a lot of sites and can only afford to model a few. I built an internal tool that takes a list of addresses, produces a rough 3D site package for each, and spits out a one page PDF with enough context to decide whether the parcel deserves a real study. It has now run a few hundred parcels. These are the parts that mattered, in the order they bit me.

What the tool actually does

For each parcel it fetches the ground, builds a context model of the surroundings, drops in a massing option at the zoning envelope, checks that a standard truck can turn into the site, and exports a plan and a perspective. No design, no promise of accuracy. The output is a triage artifact, and every page says so.

The ground layer has to be the boring one

TopoExport handles terrain per parcel. I clip a buffer around the boundary, pull the mesh and contours, and cache the result keyed on the parcel geometry hash. Two lessons. The first is that a cache keyed on the address is wrong, because addresses get corrected and the cache slowly fills with duplicates. The second is that the export queue is slower than the rest of the pipeline, so terrain jobs run in the background while everything else proceeds; without that split, a hundred parcels take an afternoon instead of twenty minutes.

The context layer is where the tool lies

Shapezo gives me the surrounding buildings and trees from a polygon I generate from the parcel plus a buffer. It is the only step in the chain that produces geometry I did not verify, and it is disproportionately persuasive because it looks complete. So the PDF labels it as context, the QA step compares the generated footprint count against the county's building count, and anything more than a small delta gets rejected and flagged for a human. About one parcel in eleven fails that check, mostly rural sites where a barn or a shed throws the count off.

Massing is a rule, not a design

The envelope massing comes from zoning numbers in the county table plus the parcel boundary, generated in Archshaper. Setbacks, height limit, floor count, done. The temptation is to make it look nicer than it is. I stopped doing that: the massing is gray, untextured, and labeled maximum envelope, because a pretty massing invites people to treat a zoning exercise as a design proposal. If a parcel survives triage, a human models it properly.

The truck check is the highest value per line of code

A single swept path through the access point catches more bad parcels than anything else in the tool. Plenty of sites look fine on a plan and cannot take a delivery vehicle without backing into traffic. I run the turn in PlaceMaker against the generated massing and the street, then flag anything that needs more than one reverse movement. It is rough, and it is the reason the tool earns its keep.

The paperwork step is what people open

CADMapper produces the plan sheet: boundary, setbacks, the massing footprint, north arrow, scale, and the street context. I compose the PDF around it. The lesson from the first version was that a beautiful perspective gets ignored and a plan on a sheet with a scale gets marked up. Version two leads with the sheet and puts the render on page two.

Failure modes worth planning for

Rate limits are real and they arrive in bursts, so the queue needs backoff and a per-parcel retry budget. Coordinate frames are inconsistent across sources, so every job records the datum it used and refuses to compare across jobs if they differ. Generated geometry drifts between runs on the same parcel, so I store a geometry hash and treat a change as a signal, not noise. And naming matters more than I expected: a folder per parcel with a predictable slug is the difference between a supportable tool and a pile of files with timestamps.

What I would tell the next person

Build the QA gate before the second feature. Keep generated content visually distinct from verified content. Write the accuracy disclaimer in the tool, not on the website. And measure the cost per parcel before you promise a volume, because the terrain export, not the rendering, is what eats the budget.