Interactive 3D Apps

Some projects are too large or too conditional to be shown as a fixed set of images. A masterplan with several phases, a tower with forty unit types, a scheme where the question is always "what about from over there" — these are better answered by an application the viewer drives themselves.

We build these in Unreal, delivered as desktop builds. Desktop rather than browser is a deliberate constraint: real-time quality at the fidelity these projects need is still a desktop proposition, and a sales gallery or design review room has a machine we can specify. Where a browser is the requirement, a digital sales gallery or a set of panoramas usually serves better.

The most common use is design review. A planning team that can move the camera themselves asks better questions than one shown six approved views, and objections surface earlier, when they are cheaper to resolve.

The second use is sales. A unit picker tied to live availability, a phase toggle showing what completes when, a sun study a buyer can scrub through — each answers a question that otherwise needs a person and a drawing.

Scope discipline decides whether these projects succeed. An application can always do one more thing, and the version that tries to do everything ships late and pleases nobody. We agree a feature set at the outset, build that, and treat additions as a second phase with its own schedule.

Builds are delivered signed and installable, with a short handover for the team operating them and a documented machine specification. Updates through the sales period are quoted separately, since availability and phasing change.

Real-time work rewards restraint in the model. Geometry that renders beautifully in an offline still will not hold a stable frame rate when a viewer swings the camera, and the rebuild for real-time is a genuine second discipline rather than an export. We budget for it explicitly rather than discovering it late.

These applications are usually one part of a larger set of collateral, not the whole of it. A launch that has an interactive build almost always also needs stills for print and film for social, and producing them from the same source keeps the tower the same colour in all three. We would rather be told about the whole programme than quoted on the application alone.

Handover is part of the deliverable, not a favour afterwards. The people running an application on a sales floor change, and a build that only one person knows how to launch stops being used. We document the machine, the launch process and the update path, and we run a short session with whoever will actually operate it.