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.
Top comments (0)