Define the comparison before building the scene
I start a city-renewal comparison with a change list, not a render list. I write down which roads, parcels, buildings, utilities, and public spaces are expected to change. I also define the comparison camera positions and the date of the existing dataset. Without that baseline, it is easy to show a polished after scene without proving what was actually renewed.
The level brief sets accuracy by use. A planning review may need reliable massing and street edges. A traffic study needs lane geometry and collision surfaces. A drainage discussion needs terrain and water paths. I keep those requirements beside the source data so the before-and-after result can be checked rather than judged only by appearance.
Normalize both states into one coordinate frame
The existing and proposed datasets must share the same projected coordinate system, local origin, units, and vertical datum. I transform GIS and CAD inputs in an ETL step, preserve source IDs, and record the origin and rotation in a manifest. I test a bridge endpoint, a road intersection, and a known elevation before generating the full district.
This step matters because a small shift can look like a design change. If the old street is offset from the new street by a few meters, a comparison may falsely suggest a wider sidewalk or a moved building. I would rather stop at three test points than debug a misleading city model later.
Build a stable existing state
I generate the existing scene from separate layers: terrain, roads, buildings, parcels, vegetation, water, and utilities. Each layer keeps its source date and confidence. I simplify distant facades, but I preserve the geometry that controls the renewal question: curb returns, ramps, loading areas, retaining walls, drainage channels, and transit platforms.
The existing state becomes a frozen reference build. I give it a version tag and keep the imported assets read-only. That lets me compare the proposed state against the same baseline after scripts, materials, or Unreal settings change.
Apply changes as explicit operations
For the after state, I treat renewal actions as operations: remove a parcel, widen a sidewalk, replace a road segment, add a building, bury a utility, plant a tree row, or create a stormwater basin. Each operation points to the affected source IDs and writes a small change log. This is easier to review than editing a copy of the whole city by hand.
I keep manual overrides rare and documented. If a curb needs a surveyed correction, the override stores the reason and the source reference. On the next build, the script reapplies it or reports a conflict. That prevents a hidden hand edit from becoming an unexplained difference between the two states.
I also generate a small change summary for reviewers. It lists removed, added, and modified features, then links each group to the same camera views used for the comparison. That gives the team a quick way to connect a visible difference to the operation that produced it, rather than searching through a large scene for the cause.
Compare at geometry and runtime level
I validate the comparison twice. First I inspect geometry: building footprints, road widths, grades, crossings, utility corridors, and water edges. Then I inspect runtime behavior in Unreal with World Partition, HLODs, Nanite, and Lumen enabled. A correct renewal model still fails if the after scene streams the new plaza late or drops detail at a cell boundary.
I use the same cameras and a small route through both states. I record frame time, memory, and visible artifacts, then review the images side by side. This catches both design regressions and technical regressions without relying on a single hero view.
I keep a compact change report with the build. It lists which parcels, roads, and utilities moved, which assets were rebuilt, and which assumptions remain open. That report gives a reviewer a direct path from a visible difference back to the data or operation that created it.
Shapezo for the first context pass
Shapezo can help when the renewal boundary is known but the detailed inputs are not ready. I select the area on a map, and AI generates a rough model from that boundary. I use it to estimate district scale, identify likely road and terrain relationships, and decide which existing-state layers should be collected first.
The generated model stays in an exploration layer. I do not treat it as authoritative for lanes, grades, utilities, or parcel decisions. Once the comparison affects a real design question, verified geometry replaces it and the source manifest records the change.
Top comments (0)