What an AR Preview Needs Before Production

Augmented reality projects rarely stall on the technology. They stall waiting for something ordinary: a survey nobody ordered, a materials decision nobody made, or permission to stand on a piece of ground.

This guide is the list of what has to exist before production starts, why each item matters, and what a producer does when it is missing, because the workaround usually costs more than the original item would have.

Start with the decision that shapes everything else

Before any file is requested, one question has to be answered: where will the viewer be standing.

That single answer determines the level of detail, the amount of surrounding context required, whether terrain matters, whether surveyed positioning is needed, and how much of the building has to be modelled at all.

A viewer across a street needs mass, proportion, roofline and material read at distance. A viewer at the front door needs resolved entrance detail, glazing that behaves, and almost nothing about the far facade.

Projects that skip this question end up modelling everything to the same standard, which is the most expensive way to produce a result that is no better.

The drawing set

The baseline requirement is the same set that produces renderings, and most projects already have it.

Floor plans at each level, elevations on all sides that will be visible, sections enough to establish floor to floor heights, and a roof plan. Details matter only where the viewer will be close enough to see them.

What causes the most rework is version confusion. A model built from a superseded elevation is not a small correction, because the geometry cascades. Confirming which issue of which sheet is current, in writing, before modelling begins, is the cheapest quality control available.

If the set is incomplete, production can start on massing and defer detail, but somebody has to accept that the early version is provisional rather than a preview of the finished asset.

Site survey with elevations, not just boundaries

This is the item most often missing and the one that causes the most visible failure.

Augmented reality places a building relative to the ground. If the model assumes a flat plane and the site is graded, the building will sit wrong, and the symptom is a structure that appears to float or to sink into the earth. Visitors notice immediately even when they cannot name the problem.

What is needed is ground levels across the parcel, ideally as a surface rather than as spot heights, plus the position of anything that will remain: retaining walls, existing kerb lines, mature trees.

If no survey exists, the honest options are to commission one, to restrict the experience to a single viewing position where the ground can be verified locally, or to accept a massing level result and say so.

Geographic position and orientation

A coordinate for the building and a defensible north arrow, both of which sound trivial and both of which get supplied wrong.

Sun position in the experience is calculated from location, orientation and time. A facade lit from the wrong side reads as fake to anybody who lives on that street, and it undermines everything else in the presentation.

For anything using surveyed placement, the coordinate requirement becomes strict rather than approximate, and it has to come from the survey rather than from a map pin.

Surrounding context data

Neighbouring buildings have to be in the experience because the questions viewers ask are comparative, so the sources for that context have to be identified early.

The usable sources in order of reliability are survey data covering adjacent structures, municipal or open data building footprints with heights, and photographic reference measured against a known dimension.

What does not work is estimating neighbours by eye from the street. It is quick, it looks plausible in review, and it is precisely the thing a resident of the adjacent building will notice and object to.

Context does not need detail. It needs correct height and correct position, which is a data problem rather than a modelling problem.

Material and finish decisions

Augmented reality is unforgiving about undecided materials in a way renderings are not.

A rendering can be composed to flatter an unresolved facade. An augmented reality preview is viewed from wherever somebody happens to stand, in whatever light exists, so every surface has to hold up rather than just the ones facing the camera.

The minimum needed is a schedule of principal facade materials with enough specification to model behaviour: how reflective, how rough, what colour under daylight rather than under showroom lighting.

Glass needs its own decision, because it is the single hardest surface in this format and the default assumptions produce either a black mirror or an empty shell.

A decision about interior visibility

Somebody has to decide whether the interior is visible through the glazing, because the answer changes the model.

Fully modelled interiors visible through windows are expensive and heavy, and on a phone the cost is felt immediately in frame rate.

Blocked out interiors are cheap and can read as a solid mass, which flattens the building.

The usual answer is a suggestion of depth: simple interior planes, some variation, enough that the eye reads through the glass without the device rendering rooms nobody will look at. Deciding this early avoids rebuilding later.

Site access, and permission to be there

An augmented reality preview is used by people standing on or near a specific piece of ground, and that has practical prerequisites that have nothing to do with modelling.

Is the parcel accessible. Is it safe. Is it fenced, and who holds the key. If the viewing position is on a public sidewalk, is a group standing there going to obstruct it. If the site is an active construction zone, what does the contractor require before visitors walk on it.

These questions decide whether the experience can be used at all, and they are usually somebody else responsibility, which is exactly why they get discovered late.

A site visit before production, not after

One walk of the site early saves more money than any technical optimisation.

What the visit establishes: where a person can actually stand, what obstructs the view from each position, what the surface underfoot is and whether tracking will cope with it, where the sun comes from during the hours visitors will be present, and whether there is mobile signal for a browser based experience.

If nobody on the production side can visit, the substitute is a structured set of photographs from candidate positions with a known reference object in frame, taken at the time of day the audience will attend.

The reference device

Somebody has to name the phone or tablet the experience must run on, and it should be the worst one, not the best.

A model tuned to the newest device will stutter on a three year old phone, and a meaningful share of visitors carry one. If the experience is for a sales team using supplied hardware, the requirement is easy. If it is for the public, the requirement is broad and the geometry budget tightens accordingly.

Naming this before production begins avoids the worst outcome in this category, which is discovering the constraint after the model is finished.

Delivery method, decided early

Browser or application changes the production, not just the distribution, so it cannot be deferred to the end.

A browser experience must fit within what a mobile browser will download and hold in memory, which is a tighter budget than a native application enjoys. A native application can carry more but has to be installed, which for a public audience is usually fatal to adoption.

The decision follows the audience. Strangers get a link or a code. Staff using it daily can justify an install.

Ownership and reuse, agreed in writing

The model is the durable asset and the contract should say who owns it.

A model owned by the project produces renderings, animation, a tour and future phases, and it survives a change of vendor or a platform shutting down. A model licensed narrowly for one augmented reality experience means paying to rebuild the same geometry later.

This is not a theoretical risk. Augmented reality tooling changes fast, and Adobe Aero, a mainstream authoring tool from a major vendor, reached end of support on 6 November 2025. Ownership of the model is what makes that survivable.

Who will operate it on the day

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

So the production plan needs a named operator: who starts it, who explains where to stand, who resets it when the anchor slips, and who charges the tablet.

That person needs a short training session and a one page instruction sheet, and both are deliverables that belong in the scope rather than assumptions that somebody will work it out.

Timeline: what runs in parallel and what does not

Modelling can begin as soon as the drawing set is confirmed, and it is the longest task.

Survey and context data can be gathered in parallel, but terrain has to arrive before the building is placed, and late terrain means redoing placement work.

Material decisions are needed partway through rather than at the start, which gives some slack, but not much.

Staging and testing happen only once there is something to test, and they are the tasks compressed when everything else runs late, which is exactly backwards because staging is what visitors experience.

Who has to sign off, and when

An augmented reality preview crosses more desks than a rendering does, and knowing whose approval is required prevents the version churn that eats schedules.

The design side owns geometry and materials, and their sign off should land before optimisation starts, because optimising a facade that then changes wastes the most skilled hours in the process.

The marketing or sales side owns the audience, the viewing positions and the delivery method, and their input is needed at the beginning rather than at delivery, since it determines the memory budget and the level of detail.

The site side, whether that is a contractor or a property manager, owns access and safety, and their answer is binary rather than negotiable. Getting it early avoids producing something that cannot be used where it was intended.

A short pre production checklist

What a producer does when something is missing

No survey: restrict to one verified viewing position, or produce at massing level and label it as such.

No context data: model the immediate neighbours from photographic reference measured against a known dimension, and state the limitation rather than presenting it as accurate.

Undecided materials: produce a neutral version that reads as a building without claiming a finish, and plan a material pass later.

No site access: build to the drawings and defer staging, accepting that the first on site session will be a test rather than a presentation.

Every one of those workarounds costs more than the missing item would have, which is the entire argument for the checklist.

Frequently asked questions

What is the single most commonly missing item?

A site survey with ground levels. Boundaries are usually available and elevations often are not, and augmented reality places a building relative to the ground, so missing terrain produces a building that visibly floats or sinks.

Can production start before materials are decided?

Yes. Geometry comes first and materials are applied later, so modelling can proceed while finishes are still being resolved. The decision is needed partway through rather than at the start, but leaving it to the end forces rework on glazing in particular.

Do we need to visit the site before production?

Somebody does. A single walk establishes viewing positions, obstructions, ground surface, sun direction and mobile signal, all of which change the production. If a visit is impossible, structured photographs from candidate positions with a known reference object are the substitute.

Which device should the experience be built for?

The oldest one the audience is likely to carry, not the newest available. Public audiences bring a wide range of hardware and an experience that only performs on current devices has failed for a large share of visitors.

Why does ownership of the model matter so much?

Because the model outlives the experience. Platforms and authoring tools in this category disappear, and Adobe Aero reaching end of support in November 2025 is a recent example. A project that owns its model can rebuild on whatever exists next.