How Poor Point Clouds Disrupt BIM Coordination

# How Poor Point Clouds Disrupt BIM Coordination

A 3 mm registration bias is not a 3 mm problem. Across a 20-station registration network on a long floor plate, that bias compounds station to station until it produces a floor-plate error large enough to fail a curtain-wall-to-slab-edge clash check — a coordination failure that traces back to a single, small, unmonitored number.

Most writing on point cloud quality stops at naming the defect. This page traces what happens next: which modeling decision each defect forces, which model error that decision produces, and where the error surfaces in coordination — the mechanism chain that connects a scan-day problem to an RFI three months later.

In this article:

• What "poor" means in a point cloud, defect by defect
• The mechanism table: defect → forced modeling decision → model error → coordination failure
• How this shows up in tolerance analysis, with the arithmetic
• Why point clouds get disorganized across disciplines
• What a control-tied, residual-reported cloud looks like

For the accuracy fundamentals behind these numbers, see point cloud accuracy and BIM coordination. For a catalogue of the resulting error types, see point cloud quality and Scan to BIM errors. This page sits between them: it is the causal chain, not the glossary or the catalogue.

What does "poor" mean in a point cloud, specifically?

"Poor" is not one condition — it is six distinct defect classes, each introduced by a different cause during capture or registration. Naming the specific defect is the first step to tracing what it does downstream, because each one forces a different modeling workaround.

Mixed pixels / edge noise. At an edge — a window mullion, a pipe against a wall — a single laser return can average two surfaces at once, producing a scatter of points that belongs to neither. It's introduced by beam divergence at range, worst at grazing angles.

Occlusion and coverage gaps. Anything the scanner can't see — above a dropped ceiling, behind stored equipment, inside a chase — leaves a hole in the cloud. It's introduced by access restrictions and single-pass capture plans that don't account for obstruction.

Registration bias. A small, systematic offset between overlapping scans that doesn't average out with more data. It's introduced by weak overlap geometry, poor target distribution, or an under-constrained bundle adjustment.

Insufficient density at range. Point spacing widens with distance from the scanner, so a wall 30+ meters away is represented by far fewer points than one 5 meters away. It's introduced by scan-station spacing chosen for coverage speed rather than fidelity at the far wall.

Reflective and glazed surface dropout. Glass, polished metal, and mirrors return weak or false signals, leaving gaps or phantom points behind the true surface. It's introduced by the physics of the material, not by operator error, and has to be planned around rather than corrected after the fact.

Motion and drift in mobile capture. Handheld and mobile LiDAR (like a NavVis VLX3 system, which captures at up to 2.56 million points per second) builds its own trajectory as it moves; a lost SLAM lock or a fast turn introduces drift that isn't visible until the data is registered against a fixed control network. It's introduced by capture speed and control-network density, which is why control ties matter more for mobile capture, not less.

How does each point cloud defect become a specific model error?

This is the mechanism the rest of this article exists to document: each cloud defect forces a specific modeling decision, and that decision produces a specific, nameable error that surfaces at a specific point in coordination — not a vague loss of "quality."

Read these left to right and the pattern is the same each time: a physical limitation at capture becomes a judgment call during modeling, and the judgment call becomes a coordination failure that looks — until traced back — like an unrelated design problem. For a longer catalogue of the coordination-stage symptoms these produce, see the Scan to BIM tolerance analysis guide.

How does this show up in tolerance analysis for engineers?

Tolerance analysis fails silently when an engineer checks a represented model against measured reality without knowing what error the cloud itself already carries. USIBD's Measured Accuracy (cloud to reality) and Represented Accuracy (model to cloud) are two separate numbers, and a project that states only one has left half its tolerance budget unaccounted for.

The arithmetic matters here. If a cloud carries ±5 mm Measured Accuracy against surveyed control, and the model is built to Zealot's committed ±10 mm Represented Accuracy at LOD 300, the two do not simply add: a stated combined uncertainty needs the error sources summed appropriately (root-sum-square for independent random errors, worst-case addition where errors are systematic, per the reasoning behind JCGM 100/GUM). A registration bias — not random noise, but a systematic offset — behaves like a worst-case addition, which is exactly why bias is more dangerous to a tolerance stack than random point scatter of the same magnitude.

Practical thresholds: architectural coordination generally works against ±10 mm Represented Accuracy to the registered cloud at LOD 300; steel connections and fabrication work need tighter tolerances than that, because a clash check with no margin left in the budget is not really a check. State the target LOA band and the LOD tier together — never one without the other — because they answer different questions.

Why do building scanning point clouds get disorganized?

Point clouds get disorganized when file formats, naming conventions, and coordinate systems are handled differently by each discipline touching the data, and no one owns the master file. This is a workflow failure, not a capture failure, but it produces the same coordination symptoms.

Format sprawl is the most common cause. E57 is the open, vendor-neutral master format — the one to archive and hand off regardless of software. RCP and RCS are Autodesk's working formats for Revit and Navisworks. LAS is the common format for GIS and civil/survey platforms. PTS is a plain, minimal point-list format some legacy or lightweight tools still expect.

Inside Revit specifically, RCP Unified versus RCP Setups changes whether disciplines see one linked cloud or several scan-station subsets — choosing wrong duplicates coordination work across teams. Add coordinate-system drift between an architecture team working in project coordinates and a survey team working in state plane, plus a second cloud from a re-scan that isn't clearly versioned against the first, and the organizational failure compounds the same way a registration bias does: quietly, until someone downstream builds on the wrong file. See the point cloud file format comparison and the point cloud organization guide for the full naming and ownership conventions.

What does a well-managed point cloud look like?

A well-managed cloud is constrained to surveyed control, has its loop closures verified rather than assumed, reports residuals instead of hiding them, and is confirmed against physical reality with independent check measurements taken after registration, not derived from the same data.

On a multi-building campus project, this method produced a control network that closed at ±6 mm campus-wide, with per-building residuals documented and available for review — not a single averaged number standing in for the whole site. That documentation is what lets a downstream engineer or BIM manager check the tolerance budget directly instead of trusting an unstated one.

Before committing to a provider, verify this method is in place rather than assumed: ask for the residual report, the control-network closure figure, and the independent check-measurement results as deliverables, not as claims. The point cloud QA guide sets out the full pass/fail procedure, and the pre-hire Revit checks cover what to verify before a model is built on someone else's cloud.

How do you catch these defects before modeling starts?

Catch them at cloud acceptance, in the window between delivery of the registered scan data and the first modeled element. Acceptance is a short, repeatable review — control tie, residuals, coverage, density, check measurements — and every defect class above is visible in it if the review asks for evidence rather than a summary sentence.

The review that works is documentary, not visual. Open the registration report and confirm the cloud is constrained to surveyed control rather than only to itself. Read the per-station residuals instead of the project average, because a systematic bias hides comfortably inside a good-looking mean. Walk the coverage: above ceilings, inside chases, behind stored equipment, and at every glazed elevation, since those are the four places gaps concentrate. Sample point spacing at the far wall of the largest space, not near a scan station. Then compare a handful of independent check measurements — taken on site, after registration, with a tape or total station — against the same dimensions pulled from the cloud.

Two acceptance habits prevent most downstream surprises. First, require that gaps be marked in the delivered data rather than silently interpolated, so the modeler knows where geometry was measured and where it was inferred. Second, require the Measured Accuracy figure and the method behind it in writing before modeling begins, because the tolerance budget cannot be checked retroactively once elements are placed. The full itemized procedure, with pass and fail criteria for each item, is published in the point cloud QA guide for Scan to BIM.

Who owns the fix when a defect reaches the model?

Ownership belongs to whoever wrote the scope. When the scope names the accuracy target, the control method, the coverage requirement, and the deliverable format, a defect is a contract question with a clear answer; when it does not, the defect becomes an argument that the modeling team usually absorbs in unbilled hours.

Practically, that means three assignments made before scan day. The capture provider owns Measured Accuracy, the control tie, coverage against the agreed scope, and the residual documentation. The modeling team owns Represented Accuracy — how faithfully elements follow the cloud they were given — and owns flagging inferred geometry rather than quietly modeling through a gap. The project's BIM lead owns the master file, its coordinate system, and versioning, which is what keeps a re-scan from being coordinated against by half the team while the other half stays on the original data. Written this way, each of the six defect classes above has a named owner and a stated threshold, which is the difference between a coordination problem someone can resolve and one that surfaces as an RFI months later.

Related reading

• Point cloud accuracy and BIM coordination — the accuracy fundamentals this page assumes
• Point cloud quality and Scan to BIM errors — the fuller error catalogue
• Benefits of 3D laser scanning for as-builts
• How to evaluate 3D laser scanning services
• Point cloud QA guide
• Revit checks before hiring a Scan to BIM provider
• Point cloud services
• Scan to BIM services