Point Cloud Deliverables Guide for BIM Managers

# Point Cloud Deliverables Guide for BIM Managers

TL;DR

• A point cloud deliverable is a menu, not a single file — RCP/RCS, E57, LAS/LAZ, PTS, panoramas, a hosted viewer, 2D plans, and a Revit model at LOD 200–350 each serve different downstream uses.
• BIM-readiness is judged on unified coordinate systems, cleaned and classified data, appropriate decimation, and file sizes that a workstation can actually load through Revit's RCP link workflow.
• Registration residuals and independent check measurements belong in the deliverable package, not just in a vendor's internal QA log.
• Density should be specified as point spacing at a stated range (e.g., 4mm at 10m), never as an adjective like "high-resolution."
• A short receiving checklist run on day one — before a model kicks off — catches most failure modes before they become coordination problems downstream.

Jump to: Deliverable Menu · BIM-Readiness · Registration & Density · Acceptance Criteria · Receiving Checklist · Failure Modes

What deliverables should a BIM manager expect from a point cloud project?

A scan-to-BIM engagement should never end with a single mystery file dropped in a shared folder. The point cloud deliverables menu typically includes several formats, each aligned to a specific downstream task:

Not every project needs every item on this list. A quick renovation feasibility study may only need panoramas and a 2D plan; a full MEP retrofit needs the classified point cloud and a modeled Revit file at a defined LOD. Matching the deliverable to the use case is covered in more depth in Point Cloud vs. BIM Model: Which Deliverable and in the format comparison in Point Cloud File Formats: E57, RCP, LAS, PTS. The LOD tier itself should be defined before the model starts — see LOD 200 vs. 300 vs. 400 for how that decision changes both cost and deliverable content.

What makes a point cloud BIM-ready?

"BIM-ready" is a specific, checkable condition, not a marketing phrase. Four elements determine whether a point cloud can actually be linked into Revit and modeled efficiently:

Unified coordinate system. Every scan setup on a project — and every building or floor if phased — needs to resolve into one shared coordinate system tied to a stated reference (project north, a survey control point, or an assumed origin). Mixed or undocumented coordinate systems are one of the most common causes of misaligned RCP links.

Cleaned and classified data. Raw registered clouds contain noise: reflections off glass, moving people, temporary equipment, scanner artifacts at edges. A BIM-ready deliverable has that noise filtered and, ideally, points classified by category (floor, ceiling, structure, MEP) so the modeling team isn't wading through clutter.

Appropriate decimation. Full-resolution point clouds can run into hundreds of millions of points per floor. Decimating to a modeling-appropriate density — while preserving the original full-resolution file as an archive — keeps the working file usable without sacrificing the source data.

File size and workstation impact. An RCP file that chokes a modeling workstation isn't BIM-ready no matter how accurate the underlying scan is. The provider should state expected file sizes per floor or per RCP link and confirm they fall within a range the BIM team's hardware can handle. For background on how these files interact with the Revit link workflow specifically, see How to Write a 3D Scan Deliverable Spec and Organize Point Cloud Data for Scan-to-BIM.

How should registration and density be reported?

Two numbers separate a defensible deliverable from a vague one: registration residual and point spacing.

Registration residual is the measured error remaining after overlapping scan setups are aligned into a single dataset. It should be reported per scan pair (or at minimum, as a distribution across the project), not collapsed into one average that hides outliers. A provider who can't produce residual data on request likely isn't tracking it internally.

Independent check measurements validate the registered cloud against reality — a handful of field-taped or total-station-verified dimensions compared against the point cloud model. This is the same principle behind What Does ±5mm Accuracy Mean: accuracy claims are only meaningful when tied to a stated method of verification, referencing frameworks like USIBD LOA C120/C220 or ASTM E3125-17 rather than an unsupported number on a spec sheet.

Density should always be expressed as spacing at a range — for example, "4mm point spacing at 10m range" — never as "high-density" or "survey-grade." Spacing at range is a testable, contract-enforceable figure; adjectives are not. Related failure patterns around vague accuracy and density language are broken down in Point Cloud Accuracy in BIM Coordination and Vet Point Cloud Accuracy Before You Hire.

Occlusion allowance deserves its own line item. Every building has areas a scanner can't fully see — behind stacked furniture, inside locked mechanical rooms, above dropped ceilings without access panels. Agreeing on an occlusion allowance up front, and having the provider document where it was applied, prevents disputes later about whether a gap in the model reflects bad scanning or an inaccessible space.

What acceptance criteria belong in the purchase order?

Acceptance criteria written into the purchase order — not negotiated after delivery — give both sides a shared standard. At minimum, the PO should specify:

• Point spacing at a stated range, by zone if density needs vary across the building
• Maximum registration residual, with per-setup reporting required
• Coordinate system and datum, including how it ties to existing site control or GIS data
• Required file formats and per-floor size limits
• Occlusion allowance, with documentation of where it was applied
• LOD target for any modeled elements, referencing the BIMForum LOD Specification
• Classification scheme for the cleaned point cloud (if classification is included)
• Independent check measurement count and locations

Projects that skip this step tend to discover the gap only during coordination, when clashes or misalignments trace back to a cloud nobody actually vetted. A structured scope document helps close that gap — see Scope of Work Template for Scan-to-BIM and 3D Laser Scanning Scope of Work for templates that convert these criteria into contract language.

What should a BIM manager check on day one?

A short, repeatable receiving checklist — run the day the deliverable arrives, before any modeling begins — surfaces problems while there's still time to send the file back:

1. Open the RCP in a lightweight Revit test file. Confirm it links without errors and loads within a reasonable time on standard project hardware.
2. Verify the coordinate system against the stated project datum or survey control, checking at least two known reference points.
3. Spot-check density in three or four areas — a large open room, a tight corridor, an MEP-dense zone — against the spacing spec.
4. Review registration residual documentation and confirm no setup pair exceeds the agreed threshold.
5. Scan for obvious noise — ghosting, doubled surfaces, floating artifacts — in a handful of representative views.
6. Cross-reference occlusion areas against the documented allowance; confirm nothing marked "complete" actually has unexplained gaps.
7. Confirm file inventory matches the PO: every promised format, every floor, panoramas if included.

This routine mirrors the broader QA process outlined in Point Cloud QA for Scan-to-BIM and the pre-hire diligence in Revit Checks Before Hiring Scan-to-BIM Services, just applied at the receiving end instead of the vendor-selection stage.

What are the most common point cloud failure modes?

Most rejected deliverables fall into a small set of recurring patterns:

Misregistration drift. Small residuals compound across a large floor plate, producing walls that don't close or floors that step between scans. This is often invisible in a quick preview and only shows up once a BIM manager checks distant points against each other.

Unclassified noise left in the cloud. Reflective surfaces, moving people, and temporary site clutter get scanned along with the building, and if not filtered, they clutter the RCP link and slow modeling.

Density inconsistent with the spec. A provider may hit the stated spacing in easy, open areas while falling short in tight or obstructed zones — exactly the areas where accurate modeling matters most.

Undocumented occlusion. Gaps presented as complete coverage, with no note that a mechanical room was locked or a wall was blocked by shelving, erode trust in the rest of the dataset.

Oversized, unusable files. A cloud technically meeting the accuracy spec but delivered without decimation can be functionally useless if it crashes every workstation that tries to open it.

The consequences of these failure modes rarely stay contained to the point cloud itself — they propagate into clash detection, RFIs, and rework once modeling starts, as detailed in Poor Point Clouds Disrupt BIM Coordination and Point Cloud Quality and Scan-to-BIM Errors. Rejecting a deliverable against pre-agreed criteria — rather than after the fact — is the difference between a fast remediation cycle and a project-wide schedule slip.

Point cloud deliverables are a specification problem before they are a modeling problem. BIM managers who define the deliverable menu, set contract-ready acceptance criteria, and run a disciplined receiving check protect every hour of Revit time that follows.