A scan tells you where surfaces are. A digital twin is supposed to tell you what things are. Everything between those two sentences is the work, and most of it is still done by a person deciding that this plane and that plane are one wall.
Two different things called a twin
The word covers two artefacts with different lifecycles, and conflating them produces projects that disappoint everyone.
A geometric twin is an as-built record: what exists, where, to a stated accuracy, on a stated date. Its value is that it replaces a drawing that was never updated after construction. It does not change on its own and it does not need to, because the building did not change either — until it does, at which point the twin is wrong and nothing tells you.
A behavioural twin is a simulation fed by live telemetry: sensor readings, control states, a physics or data-driven model that predicts what happens next. Its value is in the time dimension. It frequently uses scan-derived geometry as its substrate — you need to know where the pipes are before you can model flow through them — but the geometry is an input, not the product.
This page is about producing the first, which is the prerequisite and the part that fails on geometry rather than on integration. Be explicit about which one a stakeholder is asking for; “a digital twin of the plant” means a survey deliverable to one department and a real-time dashboard to another.
Capture, and the occlusion you plan for
Three capture methods, with different geometry.
- Terrestrial laser scanning from a tripod: highest accuracy, millimetre range noise, but one viewpoint per setup and a hard shadow behind everything. Setup count is the cost driver.
- Mobile and handheld scanning: a SLAM-based unit carried through the space, trading accuracy for speed. Positional accuracy is bounded by the drift and loop closure discussed on the SLAM page, which is why mobile scans are usually constrained afterwards to surveyed control points rather than trusted on their own.
- Photogrammetry, from a drone or a handheld camera, which is cheapest and produces texture as well as geometry, at the cost of everything on the structure-from-motion page — no geometry on textureless or reflective surfaces, and scale that must be fixed externally.
Occlusion is the dominant planning constraint and it is entirely predictable. Every scanner sees line-of-sight only, so the space behind a duct, above a suspended ceiling, or inside a cabinet is not in the cloud and never will be. A scan plan is really an occlusion plan: the question is not “where do I put the scanner” but “which surfaces must appear in the deliverable, and from where are they visible”. Discovering a missing surface after demobilisation costs a return visit, which is the single largest avoidable cost in this work.
Registration and the control network
Individual setups must be brought into one coordinate frame, which is the problem on the registration page. The distinction that matters for a twin is between chained and controlled registration.
Chained registration aligns setup 2 to setup 1, setup 3 to setup 2, and so on. Each alignment has an error and the errors accumulate as a random walk along the chain, so a long corridor of setups ends up systematically displaced from where it should be — a building that is internally consistent and externally wrong, which is the worst kind of wrong because nothing in the data looks suspicious.
Controlled registration ties every setup to a surveyed control network: targets whose coordinates were established independently with a total station or GNSS. Each setup is then constrained to absolute truth rather than to its neighbour, so error does not accumulate and the residual on the targets is a direct measurement of quality rather than an inferred one. For anything that will be compared against a design model, tied to a site grid, or revisited in a later campaign, controlled registration is not optional.
Worked: the accuracy budget
assumptions (replace with your instrument's figures)
range noise, single point 2 mm
registration residual per setup 3 mm
control network coordinate accuracy 5 mm
modelling tolerance, plane fit 4 mm
chained registration, 10 setups
errors accumulate as a random walk:
3 mm x sqrt(10) = 9.5 mm of drift at the far end
total, combining independent terms in quadrature:
sqrt(2^2 + 9.5^2 + 4^2) = sqrt(4 + 90 + 16)
= sqrt(110) = 10.5 mm
controlled registration, same 10 setups
each setup tied to control; no accumulation
sqrt(2^2 + 3^2 + 5^2 + 4^2) = sqrt(4 + 9 + 25 + 16)
= sqrt(54) = 7.3 mm
and, unlike the chained case, it does not get worse
as the project grows
The chained figure is optimistic, because registration errors are not fully independent — a systematic bias in the alignment method accumulates linearly rather than as a square root, which is how a corridor of setups ends up bent. The controlled figure is stable regardless of setup count, which is the actual argument for the extra survey effort.
When you state the accuracy of a deliverable, state which one you mean. The US Institute of Building Documentation’s Level of Accuracy specification makes this separation explicitly: measured accuracy is how well the point cloud represents the real object, and represented accuracy is how well the modelled geometry represents the point cloud. They are different numbers and a model can be excellent on one and poor on the other.
From surfaces to objects
A cleaned, registered cloud is still a set of coordinates. Turning it into a twin means fitting parametric objects to it, and automation covers only part of the range.
- Planes — walls, floors, slabs, ceilings — are fitted reliably by the same RANSAC used for ground removal, with region growing to separate coplanar surfaces that are not the same wall. This is largely a solved step.
- Cylinders — pipes, columns, conduit — are the second reliable primitive, and pipe-run extraction from industrial scans is mature enough to trust with a review pass.
- Everything else is not. Deciding that two parallel planes 200 mm apart are one wall with a thickness, rather than two walls with a void, requires knowing what a wall is. Deciding which wall is structural requires knowing what the building is. This is where scan-to-BIM stops being automatic, and the honest position is that a significant fraction of the modelling effort on a real project is still manual, with automated fitting used to accelerate a human rather than replace one.
If the deliverable is a surface for visualisation rather than an object model, meshing rather than fitting is the right route and the mesh reconstruction page covers it. The two are frequently confused in scoping: a beautiful mesh is not a model you can attach an asset record to, and an object model is not something you can walk through photorealistically.
Staleness is the real failure mode
A scan is a measurement of one moment. The day after the survey a contractor moves a valve, and the twin is wrong in a way that is invisible until somebody relies on it. This is the failure that actually retires these projects, and it is organisational rather than technical.
Three things make it manageable, and none is a software feature. Attach a survey date to every object so a consumer can see how old the claim is. Define which changes trigger a rescan, and of what — a rescan of one room is cheap, and a policy that only permits full-site rescans guarantees they never happen. And keep the point cloud alongside the model permanently, because a future question the model cannot answer can often be answered from the cloud it was built from, and because the cloud is the only artefact that records what was actually there rather than what somebody decided it was.
Top comments (0)