Point cloud registration is the step that determines whether everything downstream can be trusted. It is also the step most often treated as a technicality.
What registration actually is
A laser scanner captures what it can see from one position. To document a full building, multiple scans have to be taken from different locations, and each one lives in its own local coordinate system when first captured. On their own, they are a collection of disconnected datasets.
Registration is the process of aligning these individual scans into a single unified dataset with one consistent coordinate system. Done well, the result is a point cloud that behaves like a continuous record of the building. Done poorly, the result is a dataset with hidden inconsistencies that cause problems nobody traces back to their real source.
This is not a computational detail. It is the foundation for everything that happens afterward.
Why errors here matter more than they look
Registration errors are often small in any single location. A wall that is off by five millimeters does not look wrong in isolation. But these errors compound across the dataset, and they show up in ways that can be hard to diagnose during modeling.
The typical symptoms include:
- Walls that do not quite align where they intersect
- Ceiling heights that vary from one scan position to another
- Floor elevations that drift across the building
- Columns that appear bent or angled when the actual structure is plumb
- MEP systems that seem to have unexpected offsets at system transitions
To a modeler, these look like real conditions to be documented. They are not. They are artifacts of imperfect registration, and modeling them faithfully produces a model that is internally inconsistent in ways the original building is not.
The downstream impact is worse. A Revit model based on a poorly registered point cloud becomes unreliable as a coordination reference. Clash detection surfaces conflicts that do not exist. Design decisions get made against conditions that are not really there. By the time the errors show up in construction, the original cause is buried under weeks of design work.
Methods and their trade-offs
There are three primary approaches to registering point clouds. Each has specific strengths and failure modes.
Target-based
Physical targets are placed throughout the space during scanning. These are spheres, checkerboards, or adhesive markers whose centers can be identified precisely. During registration, the software matches target positions across scans to establish alignment.
Target-based registration is the most accurate method when done properly. It also requires disciplined fieldwork: targets must be visible from multiple scan positions, distributed throughout the space, and stable during the scanning session. For large projects or occupied sites, the logistics of placing and maintaining targets can be significant.
Cloud-to-cloud
Software aligns scans by finding overlapping geometry and iteratively matching surfaces. No physical targets are required; the building itself provides the alignment features.
This method is faster in the field and more flexible. It also relies on having enough distinctive geometry in the overlap zones to support accurate matching. Featureless spaces (long blank corridors, symmetrical rooms, repetitive ceiling grids) can cause the algorithm to produce solutions that look plausible but are actually drifting in one direction.
Hybrid
Most production workflows combine both methods. Targets are placed at strategic control locations to establish a reliable framework, and cloud-to-cloud alignment fills in the rest. This approach delivers most of the accuracy of pure target-based registration with most of the efficiency of cloud-to-cloud.
The hybrid approach is typically the right choice for commercial buildings at scale. Pure target-based is reserved for precision-critical work (historic documentation, deformation monitoring, some industrial applications). Pure cloud-to-cloud is acceptable for smaller or geometrically distinctive spaces.
The problem of cumulative drift
Registration errors that are small at any single scan-to-scan connection can compound into significant drift across a large building.
Imagine a building with fifty scans arranged in a sequence. If each scan-to-scan alignment has a small error, those errors accumulate as the alignment propagates from one end of the building to the other. By the time the registration reaches the far end, the cumulative error can be substantial.
This is particularly problematic in long linear buildings, multi-floor structures, and layouts with many sequential spaces. The errors are not visible locally; they only show up when someone tries to coordinate elements at opposite ends of the dataset.
The fix is to avoid relying on long chains of scan-to-scan connections. Control points, surveyed benchmarks, or distributed target networks create direct alignment references that prevent drift from accumulating. This adds field effort but produces a dataset that remains trustworthy across the full building.
How registration quality shows up in modeling
Revit modeling depends on consistent geometry. When a point cloud is internally consistent, modeling is fast and the results are reliable. When it is not, modelers are forced into one of three bad options.
They can model exactly what the point cloud shows, which captures the registration errors as if they were real conditions. They can average across the inconsistencies, which produces a cleaner model that no longer matches the data it was built from. Or they can repeatedly pause to investigate whether each discrepancy is real, which slows the work substantially.
None of these are good outcomes. All of them can be prevented by getting registration right before modeling begins.
Validation before modeling
Good practice treats registration as its own deliverable with its own QA process. Before a point cloud moves into modeling, it should be checked for:
- Cloud-to-cloud error statistics across the full dataset
- Target residuals if targets were used
- Visual inspection at scan-to-scan boundaries
- Comparison against known control dimensions
- Floor-to-floor alignment if the building has multiple levels
A dataset that passes these checks is defensible. One that skipped them is a risk that will surface later.
Best practices that actually matter
A few principles produce reliably good registration:
- Plan scan positions for overlap. Adjacent scans should share enough distinctive geometry to support alignment without forcing cloud-to-cloud to work at its limits.
- Use control where drift is a risk. Long or linear buildings need control points; small, feature-rich spaces may not.
- Validate before modeling. A registered point cloud that has not been QA'd is not really registered; it is just aligned.
- Document the process. Registration reports should travel with the dataset so downstream users can understand what they are working with.
Final thought
Registration is the quiet foundation of scan-to-BIM. Everything else depends on it, and when it goes wrong, everything else suffers in ways that are hard to trace back to the source.
Getting it right is not glamorous. It is just what separates a dataset you can trust from one that is slowly wasting the team's time.
Inheriting a point cloud from another vendor?
We'll assess registration quality before your team builds on it.