How an AR Preview Is Built and Staged on Site

Most explanations of augmented reality in real estate stop at what it is. This one is about how one gets made, because the production detail is where the money goes and where the failures come from.

The short version: half the work is a 3D model rebuilt to survive a phone, and half is staging a physical location so a visitor standing there actually sees what was intended. Teams routinely budget the first half and forget the second, and the second is what people remember.

The two halves of the job

The model half is screen work. It happens in a 3D application, it can be done anywhere, and its output is a file.

The staging half is site work. It involves deciding where a person stands, what they see from there, when the light is usable, and how they are handed the experience in the first place. Its output is a set of decisions and usually a few physical markers.

A project that buys only the first half ends up with a file that technically works and an experience nobody uses correctly. That outcome is common enough to be predictable.

What the drawings have to provide before anything starts

An augmented reality preview is built from the same documents that produce renderings, with two additions that are easy to overlook.

The first is a site survey with real elevations. Not a plan showing the property lines, but ground levels. Augmented reality places a building relative to the ground, and if the ground in the model is flat and the ground in reality is not, the building will sit wrong in a way every visitor can see even if none of them can explain it.

The second is a defensible north orientation and a location. Sun position in the experience is calculated from those, and a facade lit from the wrong side on a sunny afternoon reads as fake immediately, especially to anybody who lives on the street.

Everything else is standard: floor plans, elevations, sections, a materials schedule, and whatever exists of the landscape design.

Building the model for a phone rather than a render farm

This is the step that separates augmented reality production from rendering production, and it is not a minor adjustment.

A model built for still images can be extravagant. Rendering happens offline, a frame can take an hour, and nothing is harmed by geometry the camera never reaches. Augmented reality has no such luxury. The device renders the scene many times per second while simultaneously running the camera and tracking its own position in space.

So the model is rebuilt rather than exported. Interior geometry that is never visible comes out. Repeated elements are instanced. Detail that reads at two metres is removed because nobody will be at two metres. What stays is silhouette, proportion, opening positions, material behaviour and anything that reads at the distance a person will actually stand.

Done well, the result looks identical to the heavy version at viewing distance and runs at a fraction of the cost. Done badly, it looks like a simplified model, which is worse than no model at all.

The polygon budget, in practical terms

Numbers vary by device and by engine, so the useful framing is relative rather than absolute.

A documentation model of a mid rise building can carry millions of polygons and hundreds of megabytes of textures. A comfortable target for a phone experience is a small fraction of that, and the constraint tightens further if the building has to be viewed alongside surrounding context.

Textures usually cost more than geometry, which surprises people. A single oversized facade texture can consume more memory than the entire structural frame, and reducing texture resolution to what is actually visible at viewing distance is frequently the fastest large saving available.

The correct reference device is the oldest phone in the sales team, not the newest one in the studio.

Materials behave differently outdoors

A material tuned on a calibrated monitor in a controlled room is being tuned for conditions the experience will never encounter.

Outdoors the model competes with real sunlight, real sky and real reflections from real surroundings, and it is displayed on a screen fighting glare. Values that looked subtle indoors flatten out. Contrast that looked strong disappears.

The practical adjustment is to test on site, in the light the audience will have, and to accept that the settings which look best in review are not the settings that survive an afternoon.

Glass is the hardest surface in this format

Worth its own section because it causes more credibility failures than everything else combined.

In a rendering, glass is composed. The reflections are chosen, the interior visible through the glazing is designed, and the result is controlled. In augmented reality the glass has to react to a real environment that changes minute to minute, and the tricks that make rendered glass beautiful are unavailable.

The two failure modes are opposite and both common. Glass that is too reflective becomes a black mirror and the building reads as a monolith. Glass that is too transparent shows an empty interior and the building reads as a shell.

The answer is usually a middle setting with a simple suggestion of interior depth, tested outdoors, rather than either extreme tuned indoors.

The ground plane, and why it decides everything

Augmented reality has to know where the ground is before it can put a building on it, and there are two ways to establish that.

The device can estimate it, by looking at the surface through the camera and inferring a plane. This works acceptably on a level, textured surface. It works poorly on grass, on gravel, on a slope, and in flat light, which describes most undeveloped parcels.

Or the model can carry terrain derived from survey data, so the building sits on a described surface rather than a guessed one. This costs more to prepare and it is the only option that survives a sloped or irregular site.

The visible symptom of getting this wrong is a building that appears to float above the ground or sink into it, and once a visitor notices, nothing else in the experience is believed.

Surrounding buildings are not optional

A proposed building viewed in isolation answers almost nothing, because the question in almost every viewer mind is comparative.

How tall is it compared to that one. Does it block that view. Does it sit forward of the line the street already has. Those are all questions about relationship, and a model without neighbours cannot answer any of them.

Context does not need to be detailed. It needs to be correct in height and position, which is a different requirement and frequently a cheaper one. Simple massing at accurate dimensions serves better than beautiful massing placed by eye.

Where the surrounding buildings are the actual subject of the debate, and in established neighbourhoods they usually are, the accuracy of the context is the accuracy of the whole exercise.

Anchoring, and the drift nobody mentions

Once the model exists, it has to stay where it was put, and this is where phone based augmented reality shows its limits.

The device tracks its own movement by recognising features in the camera image and measuring how they shift. Every frame carries a small error, and the errors accumulate. Over a few paces the result is imperceptible. Over a walk around a site it is not, and the building can end up meaningfully displaced from where it started.

Three mitigations exist and they stack. Plan short viewing routes rather than long ones. Provide a visual marker at the starting position so the experience can be reset quickly. Or use a system that positions by surveyed coordinate, which removes the problem and adds cost.

The one thing not to do is ignore it, then discover it during a community meeting with forty people watching.

Designing the viewing positions

This is the staging work, and it is the half that gets skipped.

A site does not offer equally good views of a proposed building. Some positions are too close, so the phone has to tilt up and tracking suffers while the building leaves the frame. Some positions face into the sun. Some have a fence, a parked truck or a hedge in the way.

The right approach is to walk the site, find the two or three positions where the experience genuinely works, and design around those. Mark them physically. A painted spot, a sign, a small plinth. Anything that tells a visitor where to stand.

An augmented reality preview with three designed positions beats one with unlimited freedom, because unlimited freedom means most visitors find a bad one first and conclude the technology does not work.

What a real visitor actually does

Worth stating plainly because it differs sharply from how the experience gets tested internally.

A visitor holds the phone at chest height, not eye height. They walk while looking at the screen rather than at the ground. They rotate on the spot faster than tracking prefers. They start the experience while standing in the wrong place, and they do not read instructions.

Designing for that behaviour means the model has to look correct from a slightly low camera, the start position has to be forgiving, and recovery from a lost anchor has to be one obvious action rather than a menu.

Sun, weather and the hours the experience works

Augmented reality is an outdoor product on most real estate projects, which means it inherits the weather.

Direct sun on a phone screen reduces visibility to the point where a subtle facade becomes unreadable. Overcast light is far kinder and flattens the model less than expected. Rain ends the session entirely.

For a site with a fixed presentation schedule it is worth knowing which hours actually work and planning viewings accordingly, which is a scheduling decision rather than a technical one, and one that costs nothing to get right.

Browser or application

The delivery decision changes adoption more than any production decision.

A link or a QR code that opens in the phone browser removes the install barrier. For public sites, community meetings and walk up visitors, that removal is usually the difference between the experience being used and being ignored.

A dedicated application carries heavier models, richer interaction and works without a connection, which suits a sales team using it repeatedly on the same site and justifies the install for them specifically.

Many projects sensibly do both: a browser experience for the public and an application for staff.

The human step that never appears in the budget

The most reliable predictor of whether an augmented reality preview gets used is whether a person hands somebody a device.

Unattended codes on a construction hoarding get scanned rarely. A sales agent putting a tablet in a visitor hands, already loaded, already positioned, gets near universal engagement.

That means part of the deliverable is training. Somebody on site has to know how to start it, where to stand, what to say while it loads, and how to recover when the anchor slips. Fifteen minutes of that is worth more than a week of additional modelling.

Testing before the first visitor

The test list is short and almost nobody runs it.

Load it on the oldest phone available and confirm it holds a stable frame rate rather than merely opening.

Run it outdoors in direct sun at the time of day the audience will visit, and confirm the facade is still readable.

Walk fifty metres and look back, to see how far the building has moved. That is the drift test.

Hand it to somebody who has never seen it and say nothing. Whatever they do wrong in the first thirty seconds is what the staging has to fix.

What changes once construction starts

An augmented reality preview has a lifecycle, and it improves rather than expires as the building goes up.

Early on, the site is empty and the model carries everything, which is the hardest condition. Once a structure exists, the real building supplies context and scale reference, tracking improves because there are features to track, and the model only has to complete what is already there.

That suggests a sequencing worth planning: the version used at launch and the version used during construction are not the same asset, and the second is cheaper to produce because it can carry less.

The failures and what causes them

The building floats or sinks. The ground plane was estimated rather than surveyed.

The building drifts off its footprint. Visual tracking accumulated error over a walk that was too long, with no reset marker.

The facade looks like plastic. Materials were tuned indoors and never tested under real sky.

The phone gets hot and the frame rate collapses. The model was exported rather than rebuilt.

Nobody uses it. There was no person handing over a device, and no marked place to stand.

Frequently asked questions

How long does it take to produce an AR preview from drawings?

The model is the long pole. If a clean display model exists, preparation and staging can be quick. Starting from drawings, the effort is comparable to producing a set of renderings, because the same model is being built before it is optimised for a phone.

Why does the building look like it is floating?

Almost always the ground plane. The device estimated a flat surface from the camera feed and the real site is sloped or textured differently than assumed. Terrain derived from survey data in the model is the fix.

Can we use the same model for renderings and augmented reality?

The same base model, yes, and that is the efficient way to work. The augmented reality version is a rebuilt lighter derivative of it. Building the base model once and deriving both outputs is far cheaper than commissioning them separately.

How far can somebody walk before the model drifts?

It depends on the surface and the light, but on an open, flat, low texture site drift becomes noticeable within a short walk. Plan short routes with a marked reset position, or use a surveyed positioning system if longer movement is required.

Do visitors need instructions?

They need a person. Unattended experiences with printed instructions get low engagement. The reliable pattern is somebody on site handing over a loaded device and telling the visitor where to stand, which is a training deliverable rather than a technical one.