DEV Community: GenAnywhere

From Footprints to Massing: Engineering a Citywide 3D Model of New York

GenAnywhere — Fri, 13 Nov 2026 06:56:12 +0000

My first attempt at extruding a city took an afternoon. Building polygons in, heights in, solids out, and it looked fine in the viewer. Then I tried to use it. The heights had three different sources, the ground was flat, and a bridge had been rendered as an office tower. New York's citywide massing model, built for the Department of Information Technology and Telecommunications with AppGeo, is a useful reference for the gap between that first demo and a dataset someone can actually work with.

The inputs, and what they really contain

Building footprints come from planimetric mapping: closed polygons with a source date and an identifier. Heights usually arrive in a separate table or raster, joined by an ID that may or may not be stable. Terrain comes from a digital elevation model. In New York, the horizontal units are US survey feet in the state plane coordinate system, and vertical units are feet as well, which is convenient until someone hands you a file in meters.

Extrusion and its assumptions

The operation is simple. Take the polygon, sample the ground elevation, lift the top by the height value, and close the sides. Then decide what height means. Above ground? Above sea level? Roof line or top of the mechanical penthouse? For massing, roof height is the usual answer, but the choice needs to be written down, because two datasets that disagree by ten feet will produce different shadows at 5 p.m. in December.

Height is not one number

Some heights come from a surface model, which includes parapets, bulkheads, and sometimes antennas. Some come from an attribute that reflects the roof deck. A single tower can have three plausible heights and no obvious way to pick one. My rule is to document the source per building where possible, and to treat the resulting error as a range, not a fact. At low sun angles, a height error of a few feet moves a shadow by many feet.

Tiling a million buildings

One citywide mesh is unusable, both for file size and for rendering. Tile the model on a grid, keep a stable ID for every footprint, and build lower levels of detail for distant tiles. Formats matter: 3D Tiles or glTF for streaming viewers, a spatial database for analysis, and a simplified solid for shadow runs. The same building should carry the same ID in all of them, or every downstream join becomes a guess.

Shadows at city scale

Shadow is where the model earns its keep. Pick a date, a time step, and a sun vector, then intersect each building with the ground and with its neighbors. Terrain matters more than people expect near slopes and waterfronts. Compute on the GPU when you can, cache the results for common dates, and publish the method alongside the output, because a shadow map without a stated time and datum is not evidence.

Keys, joins, and silent failures

Most errors in a model this size are join errors. A footprint without a height becomes a zero-height building that still renders as a flat plate. A duplicate ID attaches a tower's height to a shed. A demolished building keeps its geometry for a year. None of these throw an exception. They just make the result wrong in a way that looks normal, which is the worst kind of wrong.

Filling one missing parcel

Proposed buildings are not in the footprint file yet, which is a problem when the question is about a project that has not been built. I sketched the site boundary and asked GenAnywhere for a rough volume at the district's allowed height. It returned a clean box, which I kept in a separate layer. Generated massing is fine for a screening question. It should never be mistaken for a survey of what will stand there.

QA rules that catch the weird ones

A few automated checks catch most of the damage: heights outside a plausible range for the borough, footprint area against height, buildings that intersect terrain, duplicate identifiers, and anything taller than the tallest recorded tower. Then sample a few blocks on foot. The automated checks find the absurd; the walk finds the merely wrong.

What I would change next time

I would store height provenance per building from day one, publish a confidence flag with the geometry, version the height table separately from the footprints, and keep a change log that names what moved and when. Those are boring features, and they are the difference between a model that gets trusted and one that gets screenshotted.

Cityweft vs GenAnywhere: Georeferenced GLB in a Three.js Site Viewer

GenAnywhere — Thu, 12 Nov 2026 07:05:46 +0000

Our campus master plan had a viewer problem. The architects worked in Revit, the landscape team in Rhino, and the board wanted a browser link that opened on a laptop without plugins. I inherited two site context meshes: one generated from a map selection with GenAnywhere, one exported from Cityweft with coordinates and layers. Only one of them could survive a round trip through Three.js without someone nudging it into place.

GenAnywhere was useful for the concept phase. Select the campus on a map, get a mesh, drop it into a scene. It looks right at a glance, and for a slide it is right enough. The mesh is a single object with baked colors, no real coordinate system, and no separation between ground, buildings, and trees. That last part is what broke the viewer.

What arrives in the GLB

Cityweft exports a 3D site model in GLB that keeps its georeferencing. In our case the model was projected in a State Plane zone, and the exporter wrote a local origin plus enough metadata for us to recover the placement. The file also kept scene layers: ground, buildings, vegetation, and a category for the point cloud we uploaded through My Data. That structure is the difference between a model you can query and a pretty mesh.

Checking coordinates before rendering

The first thing I do with any site export is verify the origin. If the numbers are wrong, the viewer will still render something, and the error will show up three weeks later in a shadow study. This script reads the GLB, pulls the transform, and prints the latitude and longitude of the model origin. The transform uses pyproj and the EPSG code for our county's State Plane zone:
The numbers matched the survey control point within two centimeters. The mesh itself is not survey grade, but the placement is, and that is what matters for overlaying GIS layers. With the GenAnywhere mesh we measured a drift of about 4.2 meters against the same control point, which is visible when you put a walkway on top of it. That number also settled an argument with the board: four meters is a corridor, so the viewer is for orientation and route questions go back to the facilities drawings.

Hooking layers into the UI

Layer names in the GLB follow a prefix convention, so the viewer can build toggles without a config file. The loader runs once, tags each mesh, and the UI filters by tag:
Toggling vegetation off cut the draw calls by a third and made the building edges readable. That is not a rendering trick; it is a data structure decision made upstream. A baked mesh forces you to re-export to hide a tree.

Performance notes

The full campus arrived at 1.4 million triangles. We decimated the terrain to 180,000, kept the buildings at full resolution, and left the trees alone because they were already low poly. Decimation also fixed a z-fighting flicker at the plaza, where two surfaces sat within a centimeter. Textures were 2K and mostly diffuse; the PBR maps from Cityweft were heavier than the scene needed. After cleanup the WebGL viewer held 60 fps on a 2019 laptop with integrated graphics, which was the actual target.

IFC for the architects

The architects did not want a GLB. They wanted the site in Revit, so we exported IFC and handed it over. The building splits survived, the coordinate system survived, and the materials needed a pass. That is normal for IFC and not a reason to skip it. The point of the pipeline is that each team gets a format it can use without a conversion ritual.

What I would change

I would ask for the layers before the first export instead of discovering the naming after the fact. I would pin the exporter version too, because a metadata key changed between releases and broke our parser for an afternoon. I would also keep the GenAnywhere mesh in the repo as a concept artifact, clearly labeled, because it is genuinely useful for early screenshots. The next viewer can start from this export instead of rebuilding the site, which is the practical payoff of a model that knows where it is. Spatial data is only as good as its metadata, and a mesh without an origin is a picture with extra steps.

Rebuilding a 1970s Industrial Park as a Logistics Site: A Five-Stage Model Pipeline

GenAnywhere — Wed, 11 Nov 2026 05:47:25 +0000

The park is 26 acres outside Indianapolis, built in 1974 for light manufacturing. Three metal buildings, a shared truck court, and a lot of cracked concrete. The new owner wants last-mile logistics: more dock doors, a bigger truck court, and a detention pond that the original site never needed. I rebuilt the site model from almost nothing, and it turned into a useful example of where each tool earns its place.

Stage 0: What I actually had

• A 1979 site plan, scanned, with a coordinate grid that does not match anything current.
• County aerial imagery from 2023.
• A survey of the front 300 feet, done for a road widening.
• No utility drawings worth the paper.
That is a normal starting point. The goal was not a perfect model. It was a model good enough to test trucks, drainage, and building size without waiting for a full survey.

Stage 1: Base map from OpenStreetMap

I pulled the area through CADMapper and got the street grid, building footprints, and property lines into a drawing within a minute. The footprints matched the aerial closely enough to use for area calculations. The property lines did not match the 1979 plan, which was the first useful thing the model told me: the shared truck court is probably not on the parcel the owner thinks it is.
What broke: OpenStreetMap had no fences, no dock positions, and no rear lot line behind the north building. I added those by hand from the aerial before going further. If you skip this, every setback calculation is fiction.

Stage 2: Ground and water in Civil 3D

I built a surface from the road-widening survey, the aerial contours, and about 80 spot shots I took with a hand level. The result showed the site draining to a ditch on the east side that disappears under a neighbor's gravel yard. The new detention requirement meant I had to prove where that water goes now, not where the 1979 plan said it went.
What broke: the scanned plan's spot elevations were in a different datum. I caught it because the building floor came out 3 feet above the road, which was wrong by exactly the amount of a known benchmark error. I shifted the points and rebuilt the surface. Always check one known elevation before you trust a whole scan.

Stage 3: Massing the addition

The owner wanted to know how much warehouse could fit on the north side without moving the shared truck court. I selected the open area in GenAnywhere and generated building volumes inside it, then moved the box until the truck court stayed clear. The tool filled the selection edge to edge, so I redrew the boundary 15 feet inside the fence and reran it. A 60,000-square-foot box fit with room for a fire lane. At 75,000 it did not.
That comparison took about 20 minutes. Drawing both options by hand would have taken a day and would have been less accurate.

Stage 4: Trucks and fire access in Site3D

A 53-foot trailer needs a 60-foot radius and a dock approach that does not cross a pedestrian path. I built the truck court geometry in Site3D and ran sweeps for a trailer, a fire engine, and a garbage truck. The trailer could enter but could not leave the far dock without backing across the lot. Moving the dock doors 8 feet north fixed it. The fire engine needed a wider gate at the east entrance, which also fixed a sight-distance problem at the street.
What broke: my first court had a 12 percent cross slope at the dock apron. The sweep did not care, but the drainage model did. I flattened the apron and added a trench drain.

Stage 5: Context with PlaceMaker

The last question was whether the expanded building would block the neighbor's loading area. PlaceMaker gave me the surrounding industrial buildings as massing, which was enough to see the shadow and the sight lines from the shared drive. It also showed that the park's only other exit is through a residential street, which is why the fire access fix mattered more than the owner thought.

What I took away

Five stages, five different failure modes. The base map lied about the property line, the scan lied about the datum, the massing filled the fence line, the truck swept fine but drained wrong, and the context showed an exit that nobody had mentioned. None of these were design problems. They were information problems, and the pipeline surfaced them in the right order.

Scanning an Airport While It Keeps Operating: A Five Year Matterport Workflow

GenAnywhere — Fri, 06 Nov 2026 10:01:56 +0000

Airports are hostile places for surveying. Half the space sits behind security, the other half is full of passengers, and the building never closes. When Corgan set out to document a roughly 1.6 billion dollar aviation program at LAX, the tool they chose was the Matterport Pro2, a 360 degree camera that captures a room as a set of overlapping panoramas. Five years later the archive still works. Here is the workflow that made that possible, at least the parts I would copy.

Why a 360 camera instead of a lidar rig

A terrestrial laser scanner is more accurate, and it is also slower, heavier, and awkward to move through a live terminal at two in the morning. The Pro2 shoots fast, fits in a bag, and produces a walkable model without a specialist on every trip. The tradeoff is precision. You are not getting millimeter accuracy on a curtain wall. You are getting a room you can recognize and measure well enough to confirm a door location. Battery life and cards matter more than specs. A night shift is six hours, and the camera has to survive all of it.

The scan plan comes before the camera

The usual failure is scanning everything and organizing nothing. Before a single capture, define the zones that matter: areas that change on the construction schedule, interfaces between new and existing work, equipment rooms that get sealed early. Give each zone a naming rule and a revisit cadence. A scan you cannot find later is not a record. It is a file.

Registration and drift

Every panorama has to be tied to its neighbors. Indoors, that means overlapping sightlines and enough feature texture for the software to solve the alignment. Long corridors are the hard case, because they look identical for a hundred feet. The fix is boring: more overlap, a few temporary targets, and a control measurement every so often. When a scan set drifts, the symptom is a wall that bends, and by then the cause is usually three rooms back. I keep a short written log per zone: what was captured, what was blocked, what needs a return trip. The log has saved more time than any software feature.

Coordinates that match the drawings

A scan lives in its own local space until you tie it to the project. Establish control points that exist in both the scan and the design model, transform once, and record the parameters. Keep the transform version with the dataset. The drawings change. The control network should not. If a scan lands two feet off, you want to check the transform, not re scan a concourse.

Volume, storage, and delivery

Five years of scans is a lot of data, and most of it does not need to be hot. I split storage into three tiers: raw captures, processed models, and the lightweight views people actually open in a browser. Only the third tier needs to be fast. The raw data needs to be findable, documented, and backed up, which is a different problem from performance. Name files by zone and date, never by camera serial or a person's initials. In five years nobody will know who those initials belong to.

The verification loop

The scan is only useful if someone compares it to the design on a schedule. Pick a small set of checkpoints, such as door locations, ceiling heights, and equipment clearances, then run them after each revisit. Record the result, not just the image. A photo is nice. A number is a decision. A pass or fail against a specific dimension is what turns a model into a construction record.

Massing before the heavy work

Not every question deserves a scan. When a proposed addition needed a quick read against the existing concourse, I drew a rectangle on a map and let GenAnywhere generate a 3D model of the area. It returned massing in minutes. That is enough to test height, bulk, and how the new piece sits against the old one, and it keeps the scan crew focused on geometry that will actually be built.

What I would automate

Registration reports, revisit reminders, and a dashboard that flags scans older than their zone cadence. None of that is glamorous. All of it is the difference between an archive and a pile of files. The camera gets the credit. The boring logistics keep the record alive.

Five Checks Before You Import an AI Site Model into OpenRoads

GenAnywhere — Thu, 05 Nov 2026 05:44:11 +0000

Last month a colleague dropped a folder on our server with a GenAnywhere export and a note that said site context, ready to use. I opened the mesh, looked at it for a minute, and did not touch it again for three days. Not because it was bad. Because I had not checked it yet.

This is the list I run before any AI-generated site model goes into an OpenRoads file. It takes about an hour. It has caught a wrong vertical datum twice this year and a units problem once.

1. Coordinate system and units

Start with the file format and the coordinate system. The viewer does not care where the model sits. OpenRoads does. Ask which coordinate system the export uses, and whether the numbers are feet or meters. A model in state plane feet imported as meters will look plausible and be wrong by a factor of 3.28.

A quick way to tell

Measure a road width you can see on imagery. A two-lane road with shoulders is roughly 30 to 40 feet. If the model says 120, you have a units problem, not a wide road. If the file arrives as LandXML, open the header before you open the surface.

2. Vertical datum and elevation range

AI models often sit on a smooth global terrain, and the elevation may be relative, ellipsoidal, or simply offset. Check the minimum and maximum against a benchmark you trust. A site at 620 feet NAVD88 should not import at 1,840.

The one-number test

Pick a spot with a known elevation, usually a manhole rim or a surveyed benchmark. Compare. If the difference is constant, you can shift the model. If it changes across the site, the surface is not usable for design.

3. Surface topology and breaklines

A mesh is not a TIN surface. It has triangles, but it does not know which edges matter. Walls, curbs, ditch bottoms, and top of bank are all inferred. Sometimes the inference is fine. Sometimes it cuts a corner through a retaining wall and nobody notices until the cross sections look strange. OpenRoads wants a breakline wherever the ground changes direction sharply, and the generated model rarely has one.

Triangles that lie

Turn on triangle edges and look for long skinny triangles crossing a road or a wall. Those are the places the surface is guessing. On a bridge job last winter, the mesh ran a single triangle from the deck edge to the creek bed. The deck looked fine in 3D and the profile was wrong by two feet at the abutment.

4. Scale and control

Check scale with two points you can measure on the ground, not with the viewer zoom. If the model is off by one percent over a mile, that is 52 feet. GIS data is often close enough for context and not close enough for design. If the source was a point cloud, ask how it was decimated, because decimation can move a curb.

5. What the model leaves out

The list is short and expensive: utilities, walls, culverts, inlets, guardrail, and anything underground. On a warehouse project, the generated model had the building and the parking but not the dock heights. We design to the dock, so the model was context, not a base. The same thing happens with drainage. A low spot in a parking lot is easy to see in a render and easy to miss in a mesh.

A short check script

I keep a small script that reads an exported point file and prints the elevation range and a count of impossible values. It is not validation. It is a smoke test that catches the obvious failures before they reach a design file. The automation is deliberately dumb, because dumb checks are easy to trust.

When I skip the checks

For a public meeting or a quick visual, I skip all of this. The model goes into a viewer, not a design file. The checks exist for the moment someone says ready to use. That phrase is the trigger. A quality check is cheaper than a redesign, and a file format note in the project log is cheaper still. If the model fails two checks, I stop and ask for the source. There is no point patching a surface that was never measured.

A Repeatable Five-Tool Pipeline for County Fairground Models

GenAnywhere — Wed, 04 Nov 2026 05:40:41 +0000

Every August I walk the same county fairgrounds: a half-mile dirt track, a white grandstand, and fourteen livestock barns that all look alike until you need to tell them apart. This spring the county asked whether two barns could be replaced and a new exhibition hall added without moving the track.
I built the model as a pipeline instead of a one-off scene. The goal was simple: change one input, rebuild the whole thing, and get the same result twice.

What the model has to answer

Three questions drove the work:
• Can a new exhibition hall fit without blocking the grandstand sightlines?
• Which barns are worth keeping, and which are past repair?
• How does a new hall change drainage and truck access on the gravel lanes?
Every step exists to answer one of those.

Ground and lanes first

OpenRoads handled the existing conditions. I traced the track centerline, the gravel lanes, and the parking edges from aerial imagery, then built a terrain surface from the county contours. The site is flatter than it looks, but the infield drains toward the south gate.
I exported the surface and lane alignments in feet. That became the fixed base; no other tool invented its own ground.

Rules for buildings that repeat

CityEngine did the repetitive work. The fourteen barns fall into three types: a long open-front shed, a smaller enclosed barn, and a two-story show barn. I measured each type from photos and wrote a CGA rule for it, with parameters for length, bay count, and roof pitch.
The payoff was speed: once the rules existed, I could place all fourteen barns in an afternoon and regenerate the row when a dimension changed. The grandstand got its own rule because its stepped concrete cannot be approximated with a box.

Fill the gap with a box

The exhibition hall was the unknown. I used GenAnywhere and drew a box over the overflow parking east of the track, set a height of 28 feet, and let the tool generate massing inside the box. The principle is straightforward: outline an area on the map, and the AI fills it with building volumes. You are testing occupancy, not designing a facade.
The first box crossed the track fence by 12 feet. The second pulled the west edge back and produced a long hall with a service yard.

Compare the hall options

Archshaper generated three massing schemes from the box: a long gable, a T-shaped plan, and a two-story block. I cared about two things: the view from the top of the grandstand, and whether a truck could turn around at the loading door.
The long gable won. It kept the sightline, gave the service yard a straight pull-through, and left room for a future second phase. The two-story block looked efficient on paper but threw a shadow across the warm-up ring in the late afternoon.

Props from the barn row

Meshy handled the small assets. I took photos of a cupola, a sliding barn door, and a section of grandstand railing, and converted each into a textured mesh. The originals were too heavy for a site model, so I decimated them and kept one material per asset.
The cupolas matter more than they should. Fourteen identical roofs look like a diagram. Fourteen roofs with slightly different cupola positions look like a place.

The manifest

Every export is listed in a small manifest: file name, units, coordinate reference, level of detail, rule version, and a hash. The manifest is boring, and that is the point. When a rule changes, the hash changes, and I know which views need a second look.
The rebuild test deletes the generated scene, reruns the pipeline from the manifest, and compares object counts and bounding boxes. The last run took six minutes and matched exactly. That is the only proof a pipeline is repeatable.

What broke

The first failure was units. CityEngine was set to meters while OpenRoads exported feet, so every barn came in at a third of its real length. The manifest now records units for each step.
The second was weight. The first Meshy assets were beautiful and unusable at site scale. Decimation fixed it.

Why this site works as a test

Fairgrounds are repetitive, which makes them a good stress test. They also have one irreplaceable thing, the track, which forces every new building to prove it belongs. The pipeline narrowed the conversation to two schemes and showed which one the site could absorb.
That is enough for a county meeting.

How I Built a Boston Common Shadow Study From a Single Map Selection

GenAnywhere — Tue, 03 Nov 2026 05:37:13 +0000

The setup

Last month I wanted a shadow study of Boston Common without downloading LiDAR, learning a full GIS stack, or asking anyone for a license. I ended up with a rough but useful model built from one rectangle on a map. This is the workflow I used, including the parts that broke.

Step 1: Write the question first

My first instinct was to make a model of the park. That is not a question. The useful version was narrower: which surrounding blocks put shade on the southwest lawn at 3 pm in December? Once I wrote that down, the bounding box, the level of detail, and the output all became obvious. A vague question produces a model nobody can check.

Step 2: Choose a box with context

I framed the Common plus two blocks in every direction. Too tight, and the buildings that cast the shadow fall outside the model. Too wide, and the model spends its detail on streets that do not matter. GenAnywhere takes the rectangle and builds a textured 3D model of what is inside. The selection is the scope statement, so draw it carefully.
The box also sets the scale. A rectangle that covers half the city will produce a model that looks like a diagram, not a place. Mine covered about eight blocks, which was enough to see the shadow and still recognize the park.

Step 3: Get the massing right, then stop

The first pass had the tall towers and the street wall, but the park was a flat green rectangle. That was fine for a massing test. I compared it with a satellite image, added screenshots of the park edge, and regenerated. The second pass picked up the pond, the paths, and most of the tree line. I stopped there. Chasing window frames would not change a shadow at 3 pm.
Scale is the quiet failure. I checked the length of the park boundary against a map before trusting anything. When the model was 10 percent off, a shadow that looked harmless landed on a path. The error was invisible ## ## until I measured something I knew.

Step 4: Fix the camera and the sun

A shadow study is useless if the viewpoint moves. I kept one elevated camera for every scenario and compared 9 am, noon, and 3 pm on three dates: June 21, September 21, and December 21. The tool does not give me a solar calculator, so I checked the light in the model against a real photo of the park at the same hour and kept only the runs that matched. Close enough for a sketch, not for a permit.

Step 5: Score the shadow, not the render

I divided the park into rough zones: open lawn, path, playground, pond edge. For each scenario I marked sun or shade at each time. That is all. The result was a small grid of observations, not a beautiful image. It also made the comparison honest, because I was reading the same zones every time instead of admiring a new camera angle.
The zones are crude on purpose. A finer mesh would look more scientific and would not change the decision I was trying to support: whether a mass belongs on that corner at all.
My grid had five zones and three hours. The result was fifteen marks per date. In December, four of the five zones were shaded by late afternoon. In June, none were. That is a crude result, but it is easy to explain and hard to misread.

Where the workflow fails

Trees, terrain, reflections, and rules. The model turns a canopy into a block or deletes it. It treats the ground as flat. It cannot show light bouncing off glass. And it knows nothing about the city's shadow standards. If the question is legal or financial, this workflow is the wrong tool.

What I would change next time

I would annotate the site before generating anything, so the first rectangle already includes the streets I care about. I would also keep every version, because the second model was better in some places and worse in others. And I would write the date and hour in the file name, not ## in my head.
Total time was about ninety minutes. The model is rough, but it answered the question I actually asked, which is more than most renders do. If I needed more, I would move to a real GIS shadow tool and a survey. For a first pass, the rectangle was enough.

MicroStation's Python API vs GenAnywhere's Map-to-Model AI: A Builder's Comparison

GenAnywhere — Mon, 02 Nov 2026 06:15:54 +0000

I build internal tools for a small AEC team, which means I spend a lot of time deciding where automation belongs. Last month I ran the same twelve-acre campus through two very different pipelines: a MicroStation model driven by its Python API, and a GenAnywhere scene generated from a map selection. This is a comparison from the implementation side, not the marketing side.

Two Different Automation Stories

MicroStation automation is deterministic. You write a script, it touches elements, and the same input produces the same output. GenAnywhere automation is statistical. You select an area, a model service infers geometry from imagery, and the result varies with the source data. Both are automation, but only one gives you a stack trace when something goes wrong.

What the MicroStation API Gives You

The Python API exposes the model as objects: elements, levels, references, models, properties. That means you can batch-rename levels, extract quantities, validate elevations, generate sheets, or tag elements by discipline. The important part is identity. A wall is a wall, and it keeps its ID across edits. Your script can reason about it.
That loop is boring, and boring is the point. It runs the same way every night, writes a report, and fails loudly when a model breaks a rule. I can hand it to a junior engineer without a training session.

Where the API Shines

We use it for three things: bulk property updates, drawing production, and pre-flight checks before a model goes out. A typical run renames 400 levels, exports a CSV of room areas, and flags every element outside the project boundary. None of this is glamorous. All of it used to eat a day a week.
The other advantage is reviewability. Every change my script makes can be diffed, logged and rolled back. When an auditor asks why a level was renamed or why a property changed, I can point to a commit. An AI-generated scene cannot offer that trail. It gives you a result, not a record of how the result was produced.

GenAnywhere: Automation Without a Script

GenAnywhere has no equivalent scripting surface in my workflow. The interface is the automation: draw a boundary, choose a level of detail, generate. The output arrives as a scene you can orbit and export. For context work, that is a good trade. I did not write a line of code, and I had a twelve-acre site in under ten minutes.

The Data Problem

The generated scene is a mesh, not a semantic model. There are no floors, no wall types, no property sets, no stable IDs. Units and georeferencing need checking before import. If your pipeline expects structured data, you are now writing a converter for geometry that was never structured in the first place. That is the hidden cost.

Cleaning Up the Output

My import steps are now predictable: verify units, align to the survey origin, decimate the mesh, separate merged buildings, and snap the ground to the terrain surface. I keep the result on a dedicated reference level and never mix it with design geometry. The cleanup script is about 120 lines, and I rewrite a third of it every time the source imagery changes.

A Small Integration Pattern

The pattern that works for us is a one-way handoff. GenAnywhere produces the context scene. A small script in MicroStation imports it, tags it as context, and freezes it as a read-only layer. Design elements are modeled natively. Every downstream tool reads only native elements, so the AI mesh can be replaced without breaking anything. When a newer scene arrives, we swap the reference and rerun the checks.

When I'd Pick Each

If the deliverable is context, massing or a visual check, GenAnywhere is the faster path. If the deliverable is data, drawings or anything that another system will consume, MicroStation plus a script is the only option I trust. The mistake I see most often is treating the AI output as a model when it is really a visual approximation with geometry attached.

What I Want Next

I want the generated scene to arrive with metadata: building footprints, heights, source date and a confidence value. That would turn a pretty mesh into something a pipeline can use. Until then, I treat every generated building as a sketch that needs a human signature.
I still use both. One gives me a scene, the other gives me a system. The trick is not confusing the two.

Five-Tool 3D Pipeline for a Rail Yard Reuse: Steps and Handoffs

GenAnywhere — Fri, 30 Oct 2026 07:55:09 +0000

I ran the site modeling for a 68-acre freight yard in Indiana with five tools and a six-week clock. The site has fourteen tracks, a twelve-stall roundhouse, a 94-foot coaling tower, a 240-by-62-foot freight house, and a concrete viaduct. The program is seven blocks, 118 homes, 36 maker studios, a food hall, and a 1.3-mile trail. This post is the pipeline, in the order I actually ran it.

GenAnywhere built the site plus four surrounding blocks from one map rectangle.
Halfmaps filled the wider town for shadow and skyline checks.
CityEngine turned the block layout into 118 homes with rules, not hand modeling.
Tripo3D covered four hero structures from photographs; Meshy covered the repeated street kit.
Everything merged into one scene in feet, with a 24-inch soil cap as a hard constraint.

1. Lock the units before anything else

The whole model is in NAD83 Indiana East, US survey feet. I set the project origin at the southwest corner of the yard so the coordinates stay small and the exports stay stable. The plan set is 1 inch equals 80 feet.

2. Box the site in GenAnywhere

GenAnywhere works from a rectangle on a map: you drag it, hit generate, and it returns terrain and buildings for that area as a model. I included the yard and four blocks west of it, which is where the town touches the fence. The output took a few minutes and gave me the viaduct in context. The deck is 26 feet above the tracks, and the model showed which back yards it overlooks.

3. Fill the town with Halfmaps

The GenAnywhere context is close but not survey grade, so I used Halfmaps to generate the town fabric out to the river, roughly 40 more blocks. It is a procedural city generator: fast, believable at distance, generic up close. I kept it outside the boundary and used it for shadows and skyline checks.

4. Write the block rules in CityEngine

CityEngine took seven blocks, a 60-foot right of way, and a rule file. Key attributes: two to four stories, 11-foot residential floor heights, 15-foot ground floor on the square, a twelve-foot front setback, lots 32 feet wide by 95 deep. The first run split some lots to 24 feet, which produced unusable rear yards. I set a minimum lot width of 28 feet and the count settled at 118 homes: 70 rowhouses and 48 flats.

5. Build the hero structures in Tripo3D

Four objects were worth custom geometry: the coaling tower, the water tower, the roundhouse, and the freight house shell. Tripo3D takes images and returns a mesh, so I used photos I shot on site. The coaling tower came back at about 60,000 triangles, which I decimated to 18,000 for view studies. Scale was wrong on the first pass: the model read the tower as 101 feet, not 94. I fixed it by importing with a known reference height and checking against the survey.

6. Assemble the kit in Meshy

The repeated objects are the ones that kill a schedule: bollards, planters, bike racks, light poles, benches, trash bins, and the rail fence. Meshy generated those from text prompts with PBR materials, which kept the rust and the concrete consistent across 200 instances. The texture scale drifted between objects, so I normalized every material to a two-meter tile before merging.

7. Merge, clean, and check

Everything came into Blender as separate collections. I merged by material, not by object, then checked four things: total triangle count under 1.2 million, no geometry below the soil cap, clearances under the viaduct, and the trail ramp at eight percent maximum.

8. What broke

Halfmaps roads ran straight through the yard until I masked the site polygon.
GenAnywhere rooflines flattened at the box edge, so I extended the box two blocks past the area I needed.
Tripo3D flipped normals on the water tower legs; recalculating outside fixed it.
Meshy benches arrived at three different scales, all plausible in isolation. ## 9. What I would automate next Two checks deserve a script: a unit-and-scale assertion on every import, and a nightly triangle budget report per block. I also want a naming contract that survives export. The pipeline is not clever. It is five tools doing narrow jobs, with a fixed order and a short list of checks. That was enough to keep a complicated site moving for six weeks without losing track of what was real.

Data Modeling Ivanpah: 173,500 Heliostats, One Sun, and a Lot of Missing State

GenAnywhere — Thu, 29 Oct 2026 06:45:07 +0000

I spent a week trying to represent Ivanpah as data. Not the whole plant, just the part you can see from a car: three towers, three mirror fields, and a boundary fence. It turned out to be a good exercise in knowing what a model can hold and what it quietly drops.

The Only Thing the Map Gives You

I started with GenAnywhere, because it was the fastest way to get a spatial sketch. I selected a rectangle around the Ivanpah Valley site and asked it to build a model from the map. The result was a recognizable blockout: three clusters of panels, three vertical markers, a road along one edge, and the shape of the dry lakebed. For a first pass, that was useful.
The model had no idea what a heliostat is. It had shapes that looked like mirrors and towers, but no identity, no orientation, no state. That is less a flaw in the tool than a boundary. A map-based generator reproduces geometry, and geometry is the smallest part of this system.

Three Entities, One Sun

Once I stopped expecting the model to know anything, I wrote down the entities I actually needed:
• A heliostat: a mirror assembly with a position, an aim point, and a status.
• A receiver: the target on top of a tower, with a flux limit.
• A reading: a measurement at a point in time, from a sensor or a meter.
The sun is not an entity. It is an input that changes every second, and it is the reason the other three exist. The plant has 173,500 heliostats across three units, and each one is aimed independently. If you store only the field boundary, you have stored almost nothing.

A Small Model

Here is a sketch of the Python side. It is deliberately plain, because the interesting decisions are about fields, not frameworks.
The first thing this model forces you to admit is that a position is not enough. Two heliostats at the same coordinates would behave differently if one is tracking and the other is parked for maintenance. The second thing it forces is a time dimension. A reading without a timestamp is just a number.

Coordinates Are Not State

The map model gave me an x and a y on a plane. The real field sits on uneven ground, and each pedestal has its own elevation. The mirrors also have limits: they cannot tilt past a certain angle, and they stow flat when wind gets too high. None of that is visible in a generated blockout.
I also had to pick a coordinate system. Latitude and longitude are fine for a map, but a field controller works in meters from a local origin. Mixing the two is a quiet source of bugs, and a plant this size makes the error obvious: a few feet of offset at the boundary becomes a missed aim point at the tower.

I ended up treating the generated mesh as a base layer and adding attributes on top of it. That was the only way to keep the model honest. The mesh answered "where does the field start and end." The attributes answered "what is each unit doing right now." Mixing those two questions in one object is how you get a model that looks correct and answers nothing.

Flux Is the Part You Cannot Query

The receiver at each tower has a flux limit. Mirrors are assigned aim points to spread the concentrated light, and the control system adjusts those assignments as the sun moves. There is no public feed for this. I could not query it, and I would not trust a generated scene to show it.
So I left flux out of the first version and wrote down why. A data model with a documented hole is more useful than one with a guessed value. If I ever get real readings, the Reading class is already waiting for them.

What I Took Away

A map-box 3D generator is a good way to get the outline of an industrial site in a few minutes. It is a bad way to understand timing, control, or heat. Ivanpah is a plant where the interesting behavior happens between frames: mirrors move, aim points shift, and output follows the weather.
The model I built has three towers and 173,500 rows in theory. In practice I filled in a few dozen and spent the rest of the time on the schema. That felt like the right ratio. The picture is the easy part.

CityEngine CGA to Unreal: The Files GenAnywhere Never Hands You

GenAnywhere — Wed, 28 Oct 2026 05:58:01 +0000

The district was 4,100 buildings on the east side of Tempe, Arizona. The deliverables were a walkable Unreal scene for a public meeting and a rule set the planning office could keep using after we left. I had ten days, one shapefile from the county, and a laptop that hated the shapefile. Here is the pipeline, the numbers I measured, and the exact point where a generated scene stops being a pipeline node.

Two Kinds of Output, One of Them Is a Dead End

CityEngine hands you geometry, attributes, and the rule that made both. GenAnywhere hands you a finished scene. For a mood board, the second one wins on time. For a project that will be revised four times, the second one is a dead end, because there is nothing inside it that you can change by name.

The Rule File

The rule was 180 lines of CGA, which is not a lot once you get the block structure. Lot becomes Building, Building splits into a ground floor and an upper stack, the upper stack repeats by floor height, the facade subdivides into bays and windows, the roof gets either a parapet or a mechanical screen. The attributes that mattered: floor height 3.2, ground floor 4.2, maximum floors by zone, lot coverage, facade variant, and a binary for rooftop units.

Every attribute has a unit and a range. heightMax is meters, not stories. Stories are derived. That one decision saved us from the classic mistake of a zoning table in feet feeding a model in meters.

Python for the Parts You Repeat

The county has 2,300 parcels in the boundary, grouped into six export tiles. Clicking through that by hand is how you introduce errors, so a small Python script does the assignment: read the parcel table, map zoning to attribute sets, apply the rule, export per tile, and write a log line with the triangle count and the building count. The whole batch runs in six minutes on the office machine, which is fast enough to run twice a day without thinking about it.

Export Settings That Actually Matter

glTF 2.0 out, meters, shared origin at the county grid intersection. Everything in one coordinate frame was the single biggest time saver later, because six tiles imported into Unreal land exactly where they belong with no manual nudging. Materials stay separate per rule material, with no texture atlas, so an override in the engine is a two-click job. Pivot at the world origin, not at the object center. If you get that wrong, every block rotates around a point in the river.

Import and the First Night

1.9 million triangles across 4,100 buildings. First import took fourteen minutes and the scene ran at 34 frames per second with everything visible. Merging static meshes per block brought it to 58 frames per second, with no visible difference at street level. Facade UVs survived because we exported them instead of letting the engine regenerate them. Collision is simple boxes generated in the engine, not the render mesh, because nobody needs window reveals to block a player.

What GenAnywhere Gave Us, Honestly

A single mesh, no names, no attributes, no hierarchy. In our test it produced 61 fewer buildings than the parcel table and invented three towers on lots capped at five floors, and the materials were baked into one image. When the zoning cap changed on day six, everything downstream would have had to be rebuilt. We used the image on a slide, credited it as an illustration, and moved on.

Iteration Cost, Measured

Parking ratio from 1.2 to 0.8: six minutes to regenerate, fourteen to reimport, zero minutes to remap materials because the material names did not change. GenAnywhere: ninety seconds to regenerate, then every arrow, light, and material group gone. Over ten days the rule path cost more per change and paid for itself by Wednesday.

What I Would Automate Next

Three checks in CI: a triangle budget per tile, a building count compared against the parcel table, and a checksum of the rule file written into the export name. The count check would have caught our one bad export before it reached the meeting, and the checksum tells you which version of the rules made the scene in front of you.

A Dead-Mall Site Pipeline: Five Tools, Four Handoffs

GenAnywhere — Tue, 27 Oct 2026 02:55:57 +0000

I built a planning-level site model for a 64-acre closed mall in Pennsylvania in seven weeks. OpenRoads handled ground and corridors, Archshaper handled building massing, Cityweft generated block schemes, InfraWorks assembled the public-facing scene, and GenAnywhere filled one unsurveyed parcel. The hard parts were coordinate registration, exclusion polygons, and keeping generated geometry out of the counts.
The site is Northgate Galleria: 480,000 square feet of enclosed mall, three anchors, about 2,300 parking spaces, and a ring road tied to a US-30 access permit. The town owns it with the county authority. The deliverable was three redevelopment schemes for a June hearing, not construction documents. That scope decided everything about the pipeline.

1. OpenRoads: establish one ground surface

The only survey was from 1998. It came as a DGN in Pennsylvania South State Plane, NAD83, and it had contours plus a few hundred spot shots but no surface. I built the existing ground in OpenRoads from those inputs and checked it against the creek invert from a 2021 orthographic image. Flat lot areas agreed within 0.1 foot; the banks were off by up to two feet, which is expected for contours drawn for drainage.
The corridor tools answered the access question. I tested a new street meeting US-30 at a signal and ran the queue check. The stop bar pushed back far enough that the old loop had to survive as a service drive along its first 300 feet. That constraint shaped all three schemes.
Outputs were a LandXML surface for the other tools, a corridor solid for visualization, and a grading plan showing the lower lot draining to a new basin instead of the creek outfall.

2. Archshaper: test the buildings before the blocks

The anchors are roughly 120 feet deep. Archshaper let me test three block types against that depth without modeling every wall. I fed in footprints, target unit sizes, and a height limit of four stories from the zoning code, then compared a solid block against one with a central light well.
The solid version produced a dark core and units with very little exterior wall. The light-well version lost floor area but produced rentable units around a courtyard. I exported both as OBJ meshes with level lines.
Archshaper is a massing tool, not a site tool. It knows nothing about the floodplain, the easement, or the ring road, so its output went into the scheme generator as building types rather than as a plan.

3. Cityweft: generate schemes, then subtract what it cannot see

Cityweft took the street network and block rules and produced three schemes with unit, parking, and open-space totals. The first run reported 610 units. That number was wrong for the site because 80 units landed in the 100-year floodplain.
The fix is not a setting. I had to draw exclusion polygons for the floodplain, the utility easement, and the creek buffer, then rerun. The second pass gave three schemes of 500 to 540 dwellings; parking settled near 1,100 stalls in each. Every scheme carried a CSV of counts and a GeoJSON of parcels.

Two issues matter with any similar generator:

• Stable IDs are not guaranteed. Editing the street graph renumbered blocks, which broke my schedule mapping. Export IDs after the final run, not during iteration.
• Parking counts assume the whole site is available. If a phase leaves the ring road in service, subtract those spaces manually or the total will be optimistic.

4. InfraWorks: build the scene, not the evidence

InfraWorks assembled the surface, the mall shell, the proposed streets, the floodplain, and the massing into one scene for the public meeting. I used it for sight lines, shadows, and scale. I did not pull quantities from it.
The rule I stated at the start of the presentation: numbers come from OpenRoads and Cityweft, the picture comes from InfraWorks. Mixing the two is how a planning model gets mistaken for an engineered one.

5. GenAnywhere: fill the gap, label the gap

A 12-acre patch on the far side of the creek came with neither a survey nor current imagery. I drew a rectangle around it in GenAnywhere and let the AI generate terrain and buildings inside. The result included houses, sheds, driveways, and tree cover, which was enough to judge how the new streets would feel at the property edge.
It also produced a driveway crossing the creek in one version. I kept the output on a layer named AI-CONTEXT, stamped the generation date in the layer metadata, and excluded it from every count and every area calculation. It exists to give the scene a background, nothing more.

What I would change

I would draw the exclusion polygons before the first Cityweft run and freeze the street graph a week earlier. Both would have saved a day. The coordinate setup, the ground surface, and the layer naming were worth the time they took; those three things kept five tools from becoming five versions of the truth.