Digital Twin

A digital twin here means a captured, photoreal environment you can move through in a browser — the site as it actually stands, not as it was drawn. It is produced from a capture of the real place rather than modelled from a drawing set.

The most common use is showing existing context honestly. A proposal presented against a modelled approximation of its surroundings invites the objection that the surroundings are wrong; presented against a capture of the real street, that objection disappears and the discussion moves to the building.

The second use is record. A site captured before work starts, at milestones during construction, and at completion gives a navigable record that photographs do not — you can return to a position rather than hoping someone stood there.

Captures run in-browser with nothing installed, which is what makes them useful in a review meeting where not everyone has the same software or the patience to install any.

Capture conditions set the ceiling on quality. Even light, no rain, and a site that is not mid-delivery all matter, and a capture taken in poor conditions cannot be fixed afterwards. We plan capture days around this and will move a date rather than deliver a poor scan.

Delivery is a hosted, navigable scene embeddable in your own pages, with the capture data available where you want to retain it.

Captures pair well with rendered work rather than replacing it. The proposal is rendered because it does not exist yet; the context is captured because it does. Combining them in one presentation is more convincing than either alone, and it removes the argument about whether the surroundings have been drawn favourably.

Scale sets the approach. A single building frontage, a street, and a whole district are three different capture problems with different day counts and different processing loads, and we scope each rather than quoting a rate per square metre. Restricted or operational sites add planning time for access, which we would rather build into the schedule than discover on the day.

Where a capture is intended as a record rather than a sales tool, we agree the milestone schedule up front — typically pre-construction, one or two points during, and completion — so the set is consistent and comparable rather than a collection of one-off visits.

Hosting and retention are agreed rather than assumed. Some clients want the scene hosted and embedded and nothing else; others need the underlying capture data retained in-house for their own records or for a facilities team to use later. Both are fine, but they are different deliverables and it is cheaper to decide at the outset than to reconstruct a set afterwards.

We will say when a capture is the wrong tool. A site that does not exist yet cannot be captured, and a scheme whose context is about to be demolished may be better served by rendered work that shows the intended future state. The honest answer is sometimes that the budget is better spent elsewhere.