Cornerstone encyclopedia · reality capture → buildable model

Scan-to-BIM

Definitive guide by Scan to BIM Studios. Written for practitioners first — buyers second.

Scan-to-BIM is the disciplined process of converting reality-capture data — usually terrestrial laser scans or dense photogrammetry — into an accurate, purpose-built Building Information Model. It is not “drawing over a cloud.” It is registration, classification of what matters, modelling to an agreed Level of Development and tolerance, and documented QA against the source cloud so renovation, retrofit, and facility teams can trust the geometry.

What Scan-to-BIM actually produces

A finished Scan-to-BIM package usually contains:

• A federated or discipline-split as-built BIM (commonly Autodesk Revit), aligned to a defined coordinate system.
• An LOD matrix — what was modelled to what depth (walls vs secondary steel vs small-bore pipe).
• A deviation / QA report sampling critical elements against the point cloud.
• Optional sheets, schedules, or Navisworks/coordination views for clash-aware handover.

If a vendor delivers “pretty geometry” with no LOD rules and no cloud comparison, you bought visualisation — not Scan-to-BIM.

When you need Scan-to-BIM (and when you do not)

You need it when the existing condition is unreliable: missing drawings, renovations stacked over decades, heritage fabric, occupied hospitals/airports, industrial plants, or any retrofit where a wrong dimension becomes a field conflict.

You do not need full Scan-to-BIM when a simple 2D as-built, a mesh for visualisation only, or selective verification of a few grids would answer the decision. Over-modelling burns budget and creates false confidence.

Practitioner rule: model only what a decision requires. Everything else can stay as clipped cloud references inside the authoring tool.

End-to-end workflow

1. Capture — terrestrial laser scan, mobile mapping, or controlled photogrammetry. Density must match the smallest feature you intend to model.
2. Register — unify setups into one cloud with survey control. Bad registration makes every later millimetre meaningless.
3. Specify — write purpose, coordinate system, LOD by element, tolerances, inclusions/exclusions, and deliverable formats into a mini-BEP.
4. Model — author intelligent BIM objects (not generic meshes) in the agreed tool, typically Revit for buildings.
5. QA & deliver — section the cloud, measure deviations, fix systemic errors, package model + report.

See the expanded step guide: Scan-to-BIM workflow.

Point clouds, density, and what “resolution” really means

A point cloud is a measured set of XYZ points (often with intensity/RGB). Point spacing on critical surfaces should be fine enough that the modeller can resolve the feature: a 20 mm pipe needs denser data than a concrete core wall.

• Occlusion — furniture, ceilings, insulation: if the beam never saw it, the model will guess. Plan recapture or classify as “not verified.”
• Noise & reflectivity — glass, polished metal, and wet surfaces create ghosts. Experienced teams clean before modelling.
• Colourised clouds help interpretation but do not replace geometric QA.

LOD and tolerance — the contract that prevents disputes

LOD (Level of Development / Detail, depending on regional language) defines geometric and informational reliability. Tolerance defines acceptable deviation from the cloud.

Deep dive: LOD levels in BIM.

Software stack practitioners actually use

There is no single “Scan-to-BIM button.” Common stacks:

• Capture / register: Faro, Leica, Trimble ecosystems; Recap Pro; Cyclone; Register 360; open formats (E57, RCS/RCP).
• Authoring: Autodesk Revit remains the default for building Scan-to-BIM; Civil 3D / InfraWorks patterns differ for corridors.
• Assist tools: EdgeWise, Undet, Verity (QA), ClearEdge, various Revit point-cloud workflows and plugins.
• Coordination: Navisworks Manage, Solibri for rule-based checks after modelling.

More: Scan-to-BIM in Revit and BIM software.

QA methods that separate professionals from factories

• Section overlays — cut cloud and model together at grids and congested zones.
• Heatmap / automated deviation — tools like Verity or comparable workflows flag outliers.
• Spot measurements — tape/total-station checks on critical openings and embeds.
• Exclusion logs — explicitly list what was not modelled (hidden faces, below-ceiling soft systems).

Publish the QA method in the proposal. Buyers who skip this question get unfalsifiable models.

Cost drivers (so quotes become comparable)

Price moves with area, LOD, discipline count, MEP density, cloud cleanliness, site access for recapture, and turnaround. A cheap per-sq-ft number without an LOD matrix is not comparable to a rigorous one.

Full breakdown: How Scan-to-BIM pricing works.

Common failures (learn these before you buy)

1. Modelling from an unregistered or poorly controlled cloud.
2. No LOD matrix — everything “looks detailed,” nothing is reliable.
3. Tracing meshes instead of building intelligent BIM families.
4. Ignoring coordinate systems — model will not federate with design.
5. Promising fabrication-level MEP without scan density or access.
6. Zero deviation report — you cannot audit the deliverable.

How Scan-to-BIM connects to digital twins and project controls

A trustworthy as-built model is often the geometric backbone of a digital twin. It also feeds 4D renovation sequencing and 5D quantities for existing conditions. Garbage cloud → garbage twin.

Scan density, range, and modelling truth

Laser scanners report range noise that grows with distance and incidence angle. A wall scanned at 40 m with grazing beams will not support the same millimetre claims as a wall scanned at 8 m face-on. When you write a Scan-to-BIM specification, require the capture team to declare expected point spacing on critical surfaces at the object, not merely scanner “high density” presets.

Modellers should refuse fabrication-level promises on surfaces the beam never reliably saw. Hidden faces behind insulation, above hard lids, or inside shafts must be labelled not verified — or recaptured. Absence of points is information, not permission to invent geometry.

• Architectural envelopes: openings, reveals, and slab edges usually decide renovation feasibility.
• Structural: member sizes and camber visible in cloud may differ from drawings — record both.
• MEP: model trunks and congested crossings first; long flexible runs often do not deserve LOD 400.

Coordinate systems and federation

Scan-to-BIM fails quietly when coordinates are wrong. Establish:

1. Project shared coordinate system / site survey frame.
2. Survey control report used in registration.
3. Revit origin / survey point / project base point strategy.
4. How design models will link (origin-to-origin vs shared coordinates).

If the as-built is 180 mm off the architectural grid, clash detection becomes theatre. Serious studios publish the coordinate method in the BEP excerpt attached to the proposal.

Industrial vs occupied-building Scan-to-BIM

Industrial plants with repetitive pipe racks favour semi-automated cylinder extraction. Occupied offices, hospitals, and schools favour expert manual modelling because clutter and mixed vintages break automation. Heritage assets add deformation: walls are not true planes; forcing them into perfect Revit walls may look clean and be wrong.

Choose method by asset class. Publish samples from your asset class, not a glossy refinery demo, when you sell hospital work.

Acceptance criteria you can put in a contract

1. LOD matrix initialled by both parties.
2. Tolerance table by element class.
3. Minimum QA sampling rate (e.g. critical openings 100%; random structural sample 10%).
4. Deviation report format and software.
5. Revision rounds included.
6. Exclusions list (furniture, soft ceilings, below-diameter thresholds).
7. File formats and Revit version freeze.

Encyclopedic knowledge becomes commercial power when you teach the buyer to buy correctly — then you are the obvious vendor who already works that way.

Field-to-model roles and RACI

Security, privacy, and occupied assets

Point clouds of hospitals, defence, justice, and data centres are sensitive. Contracts should cover NDA, storage region, retention, face-blurring where required, and who may sub-process. A studio that treats clouds like casual Dropbox folders is not ready for serious owners — regardless of modelling skill.

Turn the guide into a delivery brief

A useful Scan-to-BIM brief lets two competent suppliers price the same job and lets the buyer compare their answers. Start with the decision the model must support: renovation design, clash coordination, quantities, safety planning, operations, or a record of an asset. That decision determines what is worth modelling. A model that looks detailed but cannot support the decision is expensive decoration.

Then define the asset boundary. List buildings, levels, rooms, plant areas, roofs, external works and inaccessible spaces. Identify whether scan capture is included, whether an existing cloud is supplied, and whether survey control is reliable. A quote should say how incomplete scans, occluded areas, active work zones and unsafe access are handled. “Existing conditions” is not a single, universal scope.

Specify each discipline separately. Architecture may require walls, doors, ceilings, finishes and openings; structure may require grids, slabs, columns and framing; MEP may require only major systems, or every visible branch and fitting. Pair each scope line with a level of development, information requirements, tolerance, exclusions and acceptance check. Do not use LOD 500 as a shortcut for “everything is perfect.” Field verification must be stated element by element.

Finally, agree the handover environment: Revit version, native and IFC deliverables, naming convention, shared coordinates, worksets, classification, model health checks, issue format and revision protocol. Ask for one sample view, a small QA report and an issue-resolution path before scaling. These are the controls that make a model usable months after the handover meeting.

Questions a serious buyer should ask

• What accuracy is being checked: cloud registration, model-to-cloud deviation, or survey control?
• Which elements are modelled, simplified, represented symbolically, or excluded?
• How are inaccessible, hidden and visually ambiguous conditions recorded?
• Who owns the source cloud, native files and families after payment?
• What is the acceptance sample, what is the correction period, and who signs off?

Good answers are specific enough to put into a purchase order. They are also a better predictor of delivery quality than a low headline price or an impressive software list.

Frequently asked questions