Write the demo contract first
I start a bid demo with a short contract: target review questions, geographic boundary, required camera routes, delivery date, and acceptable accuracy for each layer. The contract prevents the team from turning a two-week proof into a six-month city model. It also gives technical and design contributors the same definition of done.
I separate decision-critical geometry from supporting context. Entrances, curb grades, transit platforms, water edges, and the proposed mass may need careful data. Distant roofs, private interiors, and blocks outside the review route can stay lightweight. That split is the first performance optimization and the first schedule control.
Normalize inputs before they reach Unreal
My extraction step converts GIS, CAD, survey, and image references into one projected coordinate system. I preserve source IDs and write origin, rotation, units, and vertical datum into a manifest. Before generating the district, I test three known points: a road intersection, a bridge endpoint, and a spot elevation.
This validation is essential for a fast demo. A shifted road or wrong height can make a proposal look better than it is, and fixing that after materials and lighting are added wastes the time the bid team does not have.
Generate layers in a useful order
I build terrain first, then road surfaces and edges, then existing buildings, then the proposed mass and landscape. Water and drainage arrive before final grading so the public route is tested against the real low points. Each layer has a predictable input and output folder, which makes a rebuild safer than manual scene edits.
For the proposal itself, I keep footprint, height, roof, materials, and temporary construction separate. That lets the design lead test a lower mass or a different entrance without touching the surrounding street network. It also means the change can be explained in a review instead of appearing as a mysterious new file.
Automate the camera route
A bid demo needs repeatable views. I create cameras from named route points and store their height, heading, and lens in data. The route covers arrival, public space, building threshold, and service edge. When the proposal changes, the same cameras render again, so the team can compare versions without arguing about framing.
I keep one daytime and one dusk lighting setup. The dusk setup checks legibility, reflections, and spill light, while the daytime setup keeps material and terrain decisions clear. Two controlled conditions are enough to expose many problems without turning the demo into a film production.
The route data also gives the presentation team a stable vocabulary. Instead of asking for a new angle, someone can request the arrival camera or the service-edge camera. That small naming habit reduces last-minute edits and keeps different exports aligned.
Profile before adding polish
World Partition, HLODs, Nanite, and instancing help, but I still profile the route after each major layer. I watch memory, frame time, and streaming artifacts at the ground and skyline views. Distant context stays simple; assets along the review route receive the detail budget.
I save a build report with source revisions, feature counts, and known placeholders. If a reviewer asks why a building moved or a road looks different, the team can trace the change to data or a deliberate design operation instead of guessing from screenshots.
I run one final clean-machine test before delivery. It opens the project from the handoff folder, follows the named route, and checks the three exported views. This catches missing textures, stale references, and local-only settings that do not appear on the machine where the demo was built.
Shapezo as a scoping layer
Shapezo can provide a fast context model at the beginning of the workflow. I select the bid area on a map, and AI generates a rough model from that boundary. I use it to estimate scope, find major connections, and decide which authoritative layers should be collected first.
The generated model remains outside the production source of truth. Once a road, grade, utility, or building affects a decision, I replace it with verified data and record the provenance. The result is a fast first pass that does not weaken the reproducibility of the Unreal demo.
I keep the selected boundary and the first assumptions in the build notes. That small record explains why the demo includes one block instead of five, and it gives the next contributor a clear place to restart if the bid scope changes.
Top comments (0)