A dense three-day stretch across billing, the Revit plug-in, Morpheon chat, the XR viewer, and two app-store submissions. Here’s what’s live.
Stripe webhooks are now receiving production events on the primary ScanBIM account. Subscription upgrades, downgrades, and seat changes flow into the dashboard without a manual step.
The 1.1 release adds a signed MSI installer, an OAuth device-flow sign-in, and a seven-button ScanBIM ribbon inside Revit. The Morpheon WPF panel docks alongside the model, backed by an embedded MCP WebSocket bridge so the assistant can read and act on model context locally. 20+ Revit-side tools are exposed, from family audits to parameter sync.
Morpheon chat now runs on Cloudflare Workers AI with a Vectorize-backed RAG layer. Each project gets an Observer Durable Object that tracks conversation state and model context. Five agent personas are seeded out of the box — project coordinator, QA/QC reviewer, clash resolver, submittal tracker, and estimator.
Potree (for classic LAS/LAZ point clouds) and a Gaussian Splatting viewer are both live in the web app. The XR viewer streams to headsets over WebRTC, and the submittal tracker UI now renders inline on the web.
The PWA shell ships with a site-walk mobile agent — capture notes, photos, and observations from the field and they sync into the project’s Observer.
More to come as review milestones land. Watch this space.
The scope of work document is where most scan-to-BIM project problems originate. Vague descriptions of deliverables, unstated assumptions about LOD, and missing definitions of project boundaries create disputes that consume time and budget long after the scanning is complete.
A well-written scan-to-BIM scope of work protects both the client and the provider by establishing clear expectations before work begins. Every dollar spent on scope definition saves multiples during execution.
The physical scope defines exactly what gets scanned and what gets modeled. Floor plans with highlighted zones, not just area descriptions, eliminate ambiguity about boundaries. Vertical scope from slab to slab, from slab to deck, or from finish floor to a specific elevation above ceiling must be stated explicitly.
Exclusions are as important as inclusions. If certain rooms, floors, or areas are not part of the scope, list them. If exterior scanning is excluded, state it. Assumptions that seem obvious during proposal development become disputes when they are not documented.
Access constraints should be addressed in the scope. Are there areas that require escorts, off-hours access, or special safety training? Will the scanning crew have continuous access or limited time windows? These constraints affect scheduling, pricing, and coverage completeness.
Every deliverable should be described with enough specificity that both parties understand what will be produced. A point cloud deliverable specification should include format, coordinate system, density, and noise tolerance. A BIM model specification should include software version, LOD by discipline, file structure, and naming conventions.
LOD specifications need to go beyond citing a number. Include descriptions of what each LOD level means for each discipline in the project. Structural LOD 300 looks different from mechanical LOD 300 and plumbing LOD 300. Reference images or example models reduce interpretation differences.
Intermediate deliverables and review milestones should be specified if they are expected. Will the client review registration reports? Is there a model review at 50% completion? Are there hold points where approval is required before proceeding? Define these checkpoints in the scope to prevent surprises.
Numeric accuracy requirements remove subjectivity from quality discussions. Registration accuracy, model-to-cloud deviation tolerances, and dimensional accuracy targets should all be stated with specific values. Generic language like high accuracy or tight tolerances invites disagreement.
Quality control procedures should be outlined in the scope. Who performs QC, what metrics are checked, and what happens when deliverables do not meet accuracy requirements should all be defined before work begins. Rework provisions protect the client. Clear acceptance criteria protect the provider.
Realistic timelines account for access scheduling, processing time, modeling effort, and review cycles. A scope that promises a 100,000 square foot scan-to-BIM deliverable in two weeks is setting up both parties for disappointment.
Schedule dependencies should be explicit. The scanning schedule depends on site access. Processing depends on scanning completion. Modeling depends on processed data delivery. Client review periods add time between milestones. Each dependency should be stated with a duration estimate.
The scope should include a change management process for the inevitable adjustments that occur during project execution. Additional areas, LOD upgrades, and schedule changes all require a defined process for requesting, approving, and pricing changes. Without this process, scope creep becomes a source of conflict rather than a managed reality of project work.
Most construction companies that own drones use them primarily for progress photos and marketing content. That is a fraction of the value that drone-based reality capture can deliver. When integrated into project workflows with proper planning and processing, drones become a measurement and monitoring tool that competes with traditional survey methods on speed and cost.
Moving drones from a marketing toy to a production tool requires understanding the workflows, accuracy capabilities, and deliverable types that support real project decisions.
RTK-enabled drones like the DJI Mavic 3E achieve absolute positional accuracy of 2-3cm without ground control points. With properly placed GCPs and careful flight planning, sub-centimeter relative accuracy is achievable. That precision supports earthwork volume calculations, site grading verification, and layout confirmation.
Orthomosaic maps provide planimetric site documentation at resolutions of 1-2cm per pixel. These georeferenced images serve as current-condition basemaps for coordination, logistics planning, and progress documentation. Updated weekly or monthly, they create a visual record of site evolution that supports schedule analysis and dispute resolution.
Digital surface models capture terrain and structure elevations across the entire site. Cut-fill analysis against design grades produces volume calculations that verify earthwork quantities. Comparison between successive flights quantifies material movement and progress rates.
Point clouds generated from drone photogrammetry provide 3D site documentation for design coordination. While less precise than terrestrial laser scanning for detailed building documentation, drone point clouds excel at capturing site context, building exteriors, and areas that are impractical to reach with ground-based equipment.
Effective drone operations on construction sites require more planning than pointing the drone up and pressing go. Airspace considerations, including proximity to airports and temporary flight restrictions, must be checked before every flight. Active construction zones create safety considerations that the pilot must manage around crane operations, concrete pours, and material deliveries.
Flight planning software automates the systematic capture pattern needed for photogrammetric processing. Parallel flight lines with appropriate overlap, consistent altitude, and proper camera settings produce datasets that process cleanly. Ad hoc flying produces photos but not measurement-quality data.
Weather constraints limit drone operations more than most project teams anticipate. Wind above 20 mph degrades data quality. Rain prevents flying entirely. Winter conditions reduce battery performance. Building weather windows into the project schedule prevents missed capture dates.
Raw drone imagery requires processing to produce usable deliverables. Photogrammetric software reconstructs 3D geometry from overlapping images, a process that takes hours to days depending on site size and output resolution. Cloud-based processing services reduce local computing requirements but add subscription costs.
Integration with existing project workflows determines whether drone data drives decisions or sits on a server. Orthomosaics that feed into site logistics plans, point clouds that load into coordination models, and volume reports that update earthwork trackers all connect drone capture to project outcomes. Without this integration, drone flights are just expensive photography sessions.
Drone reality capture ROI comes from three sources: replacing more expensive traditional methods, catching problems earlier through frequent monitoring, and providing documentation that prevents disputes. A single drone flight that identifies a grading error before concrete placement justifies the entire program cost. Weekly flights that document progress create schedule evidence that resolves delay claims.
The investment required to launch a production drone program includes the aircraft, RTK capability, processing software, pilot training, and Part 107 certification. Total startup costs typically range from $5,000 to $15,000 depending on equipment choices. Ongoing costs are primarily pilot time and software subscriptions.
Navisworks has been the standard clash detection and coordination tool in construction for over a decade. It works. Teams know it. Workflows are established. But the limitations of a desktop-based coordination platform are becoming harder to ignore as project teams become more distributed and expectations for real-time collaboration increase.
Cloud-based coordination platforms are not replacing Navisworks overnight, but the shift is accelerating. Understanding the trade-offs helps VDC teams plan their technology strategy rather than being forced into reactive decisions.
Navisworks handles large, complex models with a level of performance that cloud platforms have not fully matched. Federated models with millions of elements, complex clash detection rules with custom tolerances, and 4D simulation with detailed construction sequencing all run reliably in the desktop environment.
Custom clash rules and search sets that teams have refined over years represent significant institutional knowledge. Migrating that logic to a new platform requires effort, and the result may not replicate every capability that experienced coordinators depend on.
For projects where all coordination team members work from the same network or can exchange files efficiently, Navisworks delivers everything needed without the subscription costs and learning curve of a new platform.
Access is the single biggest advantage of cloud coordination platforms. Any stakeholder with a web browser can view the coordinated model, review clashes, and contribute to resolution. No software installation. No file downloads. No version confusion about who has the latest model.
Real-time collaboration means that when one team resolves a clash, every other team sees the update immediately. The sequential workflow of export, upload, distribute, and wait for review compresses into continuous, parallel coordination. On fast-track projects, this acceleration directly impacts schedule.
Issue tracking and accountability improve when coordination happens in a platform that logs every action. Who raised the clash, who was assigned to resolve it, when was it addressed, and what was the resolution are all captured automatically. That audit trail improves accountability and provides documentation for disputes.
Field access to coordination models through mobile devices means that the people installing systems can view clash resolutions in context. A foreman standing at the point of installation can pull up the coordinated model and see exactly how the conflict was resolved. That direct access reduces RFIs and interpretation errors.
Most VDC teams in 2026 are running hybrid workflows. Navisworks handles heavy clash detection and complex coordination sessions. Cloud platforms handle distribution, review, and field access. The desktop tool does the computational heavy lifting. The cloud platform extends access to the broader project team.
This hybrid approach leverages the strengths of both environments. The risk is maintaining synchronization between them. When the Navisworks model and the cloud model diverge, confusion follows. Clear update protocols and version management procedures prevent this disconnect.
VDC teams considering increased cloud adoption should start with the use cases where cloud platforms clearly outperform desktop tools: broad stakeholder access, field coordination, and issue tracking. Keep complex clash detection in Navisworks until cloud platform performance catches up on computational intensity.
Evaluate platforms based on your actual workflow, not feature lists. Can the platform handle your typical model sizes? Does the clash detection logic support your coordination standards? Can your trade partners access the platform without specialized training? These practical questions matter more than theoretical capability comparisons.
Digital twin has become one of the most overused terms in construction technology. Software vendors attach the label to everything from basic BIM models to real-time sensor dashboards. The result is a concept so broadly defined that it has lost much of its practical meaning.
For construction and facility management professionals, cutting through the marketing to understand what digital twins actually require and what they actually deliver is essential for making smart technology investments.
A digital twin is a dynamic digital representation of a physical asset that maintains a live connection to the real-world condition of that asset. The key word is dynamic. A static BIM model is not a digital twin. A 3D model that was accurate at the time of scanning but has not been updated since is not a digital twin.
True digital twins incorporate ongoing data feeds that keep the digital representation synchronized with physical reality. Sensor data, maintenance records, operational parameters, and periodic reality capture updates all contribute to maintaining the connection between the digital model and the physical asset.
This distinction matters because the cost and complexity of maintaining a live digital twin far exceeds the cost of creating an initial 3D model. Organizations that plan for model creation but not for ongoing updates end up with expensive static models, not digital twins.
Construction phase digital twins are most valuable on complex, long-duration projects where tracking as-built conditions against design intent creates measurable schedule and cost benefits. Progress monitoring through periodic reality capture, automated deviation detection, and predictive scheduling based on actual installation rates all leverage the digital twin concept effectively.
Facility operations is where digital twins show their strongest ROI. Buildings with complex mechanical systems, data centers with high-density equipment, and industrial facilities with continuous operations all benefit from digital representations that reflect current conditions rather than original design.
Predictive maintenance enabled by sensor-connected digital twins reduces unplanned downtime. Energy optimization based on real-time system performance data reduces operating costs. Space management informed by occupancy sensing maximizes utilization. These applications generate ongoing returns that justify the investment in maintaining the twin.
Every digital twin starts with an accurate geometric foundation, and that foundation comes from reality capture. The quality of the initial scan-to-BIM model directly determines the utility of the digital twin. A twin built on inaccurate geometry produces unreliable results regardless of how sophisticated the sensor integration or analytics platform might be.
Periodic reality capture updates maintain geometric accuracy as the physical asset changes. Construction progress, tenant improvements, equipment replacements, and system modifications all alter the physical space. Scheduled rescanning and model updates keep the twin synchronized with reality.
The most successful digital twin implementations start with specific, measurable use cases rather than attempting comprehensive digital representation. Pick one system or one operational problem. Build the twin to address that specific need. Demonstrate value. Then expand.
A mechanical system digital twin that monitors HVAC performance and flags maintenance needs is more valuable than a full-building twin that tries to do everything but lacks the data integration to do anything well. Focused implementation with clear success metrics beats ambitious implementations that stall under their own complexity.
Starting a practical digital twin requires three things: an accurate geometric model from reality capture, a data source that provides ongoing information about the physical asset, and a platform that connects the model to the data in a way that produces actionable insights. Many organizations already have two of these three components and can launch a pilot with modest additional investment.
Scan-to-BIM pricing is one of the least standardized costs in construction technology. Quotes from different providers for the same project can vary by 300% or more. Some of that variation reflects genuine differences in quality and scope. Much of it reflects inconsistent assumptions about what the deliverable includes.
Building an accurate scan-to-BIM budget requires understanding the cost drivers at each phase and knowing which variables have the biggest impact on total project cost.
Scanning costs are driven by site size, complexity, and access constraints. A straightforward open office floor scans faster than a congested mechanical room of the same square footage. Multi-story buildings with limited elevator access take longer than single-story facilities. Occupied spaces that require off-hours scanning add premium time.
Typical scanning day rates range from $1,500 to $2,500 depending on equipment, operator experience, and geographic market. A skilled operator with a high-speed scanner covers more ground per day than a less experienced operator, making the higher day rate often more cost-effective on a per-square-foot basis.
Drone capture for exteriors and large sites typically runs $2,000 to $3,000 per day including mobilization, flight operations, and initial data processing. RTK-enabled drones reduce the need for ground control points, which can save a half-day of survey work on large sites.
Raw scan data requires processing before modeling can begin. Registration, cleaning, and formatting typically add 1-2 days of processing time per day of field capture. Processing rates range from $1,000 to $1,500 per day depending on the software platform and the level of cleanup required.
Projects with many scan stations or complex multi-floor registration take longer to process. Targets versus targetless registration affects processing time. The quality of field capture directly impacts processing effort. Clean, well-planned scans process quickly. Poorly captured data requires extensive manual intervention.
Modeling is typically 50-70% of total scan-to-BIM project cost, and it is the phase with the most variability. LOD requirements, building system complexity, and modeler skill level all drive significant cost differences.
LOD 200 modeling for basic spatial reference might cost $0.05-0.10 per square foot. LOD 300 for MEP coordination typically runs $0.15-0.35 per square foot. LOD 350 for complex mechanical spaces can reach $0.50 or more per square foot. These ranges vary significantly based on system density and building type.
Offshore modeling resources at $30-40 per hour reduce cost but require strong QC processes to maintain quality. Domestic modelers at $80-120 per hour deliver faster turnaround and easier communication but at higher rates. The best approach depends on project timeline, quality requirements, and available management oversight.
Scope changes are the most common budget buster. Additional areas requested after scanning begins require remobilization. LOD upgrades mid-project require rework. Adding disciplines that were not in the original scope means new modeling passes through existing data.
Rework from quality issues adds cost that should have been prevented. Inaccurate registration discovered during coordination, modeling errors found during field installation, and missing coverage identified after the scanning crew has left all generate unplanned expenses.
Technology costs including scanner maintenance, software licenses, data storage, and computing resources are ongoing operational expenses that should be amortized across projects rather than ignored until they appear as surprise line items.
A well-structured scan-to-BIM budget breaks cost into four components: field capture, processing, modeling, and project management. Add a 5-10% contingency for scope adjustments and unforeseen complexity. Include QC time as a line item, not an afterthought. The projects that budget explicitly for quality control deliver better results than those that treat it as overhead.
Automated scan-to-BIM has been a conference talking point for years. The promise is compelling: feed a point cloud into software and receive a finished BIM model without manual intervention. The reality in 2026 is more nuanced. AI-driven tools have made meaningful progress on specific tasks, but fully automated scan-to-BIM remains out of reach for production-quality deliverables.
Understanding where automation works and where it fails helps VDC teams make smart investment decisions about their scan-to-BIM workflows. The goal is not to eliminate modelers. It is to amplify their productivity by automating the tasks that machines handle well.
Automated classification has reached production-ready maturity for common building elements. AI can reliably identify walls, floors, ceilings, columns, and major MEP runs in well-captured point clouds. This classification step saves modelers significant time by organizing the point cloud before they begin working.
Pipe and duct extraction algorithms perform well on exposed systems with clear geometry. Straight runs, standard fittings, and consistent diameters are detected accurately. These automated extractions give modelers a starting framework that they refine rather than building from scratch.
Noise removal and point cloud cleaning have benefited substantially from machine learning. Automated identification of moving objects, scanner artifacts, and irrelevant data reduces processing time and delivers cleaner source data to the modeling team.
Complex intersections remain a challenge. Where multiple systems converge, overlap, or change direction, automated tools produce unreliable results. Mechanical rooms, ceiling plenums with congested routing, and areas with insulated systems consistently require manual modeling intervention.
Partially occluded elements expose the fundamental limitation of scan-to-BIM automation. AI can only model what the scanner captured. When pipes run behind other pipes, when ducts are partially hidden by structure, and when insulation obscures actual dimensions, automated tools either skip the element or guess incorrectly. Human judgment is still required to interpret incomplete data.
System identification, meaning understanding what a pipe carries or what system a duct serves, remains beyond current AI capabilities. A modeler who understands building systems can infer that a 4-inch pipe at ceiling height near a bathroom is likely a waste line. Automated tools see a cylinder and assign a diameter. The intelligence gap matters for coordination.
The most productive scan-to-BIM teams use AI as a first pass and human expertise as the finishing layer. Automated tools process the point cloud, classify elements, and extract preliminary geometry. Skilled modelers then verify, correct, and complete the model with the judgment and system knowledge that automation lacks.
This hybrid approach typically reduces modeling time by 25-40% compared to fully manual workflows. The savings come not from eliminating modelers but from eliminating the most repetitive portions of their work. Modelers spend less time tracing straight pipe runs and more time solving the complex spatial problems that require expertise.
When evaluating AI-driven scan-to-BIM tools, test them on your actual project data, not vendor demo datasets. Demo scans are clean, well-captured, and feature simple geometry. Real project scans include noise, occlusion, insulation, and the complexity that separates conference presentations from production work.
Measure accuracy and completeness independently. A tool might achieve 95% accuracy on detected elements while only detecting 60% of the total elements in the space. Both metrics matter for understanding the real productivity impact.
Most companies that invest in reality capture technology treat it as a project-level tool. Individual project teams decide when to scan, who does the work, and how the data gets used. The result is inconsistent quality, duplicated equipment purchases, and scan data that sits on hard drives without driving any downstream value.
Centralizing reality capture under VDC leadership transforms it from a fragmented expense into a strategic capability. The VDC team brings the technical knowledge, workflow integration, and quality standards that turn raw scan data into actionable project intelligence.
VDC teams already own the BIM environment that reality capture data feeds into. They understand coordinate systems, model standards, and the downstream workflows that consume scan-to-BIM deliverables. Adding reality capture to VDC ownership creates a continuous pipeline from physical capture through digital modeling to project coordination.
When reality capture lives outside VDC, a handoff gap exists between the scanning team and the modeling team. Data arrives in formats the modelers did not expect. Registration standards do not match project requirements. Coordinate systems need adjustment. Every handoff introduces delay and potential error.
VDC ownership eliminates that gap. The same team that will process, model, and coordinate the data also controls how it gets captured. Scan planning considers modeling requirements from the start. Coverage decisions reflect coordination needs. Quality standards are consistent because one team defines and enforces them.
Standing up a VDC-owned reality capture program requires investment in three areas: equipment, personnel, and process. Equipment decisions should match your project portfolio. Personnel development should create depth so the program does not depend on a single operator. Process documentation should standardize everything from scan planning through deliverable handoff.
Start with a core equipment package that covers your most common project types. A terrestrial scanner and a survey-grade drone handle the majority of construction reality capture needs. Add handheld scanners and specialty equipment as the program matures and demand increases.
Train multiple team members on each technology. Cross-training prevents bottlenecks and builds organizational resilience. The VDC coordinator who understands scanning makes better modeling decisions. The scanner operator who understands BIM captures better data.
Centralized ownership enables standardization that project-level ownership cannot achieve. Scan specifications, registration tolerances, processing workflows, deliverable formats, and quality checkpoints become consistent across every project. New team members learn one set of standards. Clients receive predictable quality regardless of which project team they work with.
Standard operating procedures should cover every phase of the reality capture workflow. Field protocols define scan density, overlap requirements, and control point placement. Processing standards specify noise removal, classification, and output formats. Modeling standards match the organizations existing BIM standards. Each procedure should be documented, trained, and audited.
Reality capture program ROI extends beyond the direct savings on individual projects. Reduced RFI counts, fewer field conflicts, shortened coordination cycles, and improved schedule predictability all contribute to portfolio-level value that exceeds the programs operating cost.
Track metrics that connect reality capture to project outcomes. Compare RFI rates on projects with and without scan-to-BIM deliverables. Measure coordination cycle times before and after reality capture integration. Document avoided conflicts and estimate their cost impact. These metrics justify continued investment and guide program expansion.
Companies with mature, VDC-owned reality capture programs win work that competitors cannot execute. Owners and architects increasingly expect reality capture as a standard service. Design-build and IPD project teams require it for existing conditions documentation. The firms that can deliver this capability internally, with consistent quality and predictable cost, hold a significant competitive advantage in pursuit and preconstruction.
A point cloud is raw dimensional data. Turning it into something useful requires choosing a conversion path, and that choice shapes every downstream deliverable. Point cloud to mesh creates lightweight 3D surfaces. Point cloud to BIM creates intelligent parametric objects. Both start from the same scan data but serve fundamentally different purposes.
Choosing the wrong path wastes time and budget. Converting to BIM when a mesh would suffice adds weeks of modeling time. Converting to mesh when BIM is needed leaves you without the intelligence required for coordination, quantity extraction, or fabrication support.
Mesh conversion uses automated algorithms to wrap surfaces around point cloud geometry. Tools like Pointfuse generate clean triangulated surfaces directly from scan data with minimal manual intervention. The output is a lightweight 3D model that looks like the scanned environment and can be measured, sectioned, and shared.
Mesh workflows excel when the primary need is spatial context rather than intelligent objects. Facility walkthroughs, owner presentations, spatial planning, and visual documentation all work effectively with mesh models. Processing time is hours rather than days, and the output is immediately usable without specialized BIM software.
Mesh models also serve as excellent reference geometry within BIM environments. Loading a mesh into Navisworks or Revit gives modelers and coordinators 3D context without the file size and performance impact of working directly with dense point clouds.
The limitation is intelligence. A mesh surface representing a pipe looks like a pipe, but the software does not know it is a pipe. You cannot extract a bill of materials, run clash detection against system assignments, or generate fabrication drawings from mesh geometry.
BIM modeling creates parametric objects with embedded information. A pipe in a BIM model has a diameter, material, system assignment, and connection logic. That intelligence enables automated clash detection, quantity takeoff, fabrication support, and lifecycle facility management.
The trade-off is time and cost. Manual BIM modeling from point cloud data requires skilled modelers who understand both the software and the building systems they are representing. A complex mechanical room might take a modeler several days to complete at LOD 300, where mesh conversion would finish in hours.
BIM workflows are essential when the deliverable must support coordination, construction, or operations. If the model feeds into clash detection, if quantities will be extracted for procurement, or if the facility team will use the model for ongoing maintenance planning, BIM is the only path that delivers the required intelligence.
Many projects benefit from combining both approaches. Mesh conversion provides rapid spatial context for the full project. BIM modeling covers the specific systems and zones where intelligence is needed. The mesh becomes reference geometry while the BIM model carries the coordinated, intelligent content.
This hybrid approach is particularly effective on large existing facilities where full BIM modeling of every element would be cost-prohibitive. Model the systems you need to coordinate. Mesh everything else for context. The result is a practical, affordable deliverable that serves real project needs without over-investing in detail that nobody uses.
The decision framework is straightforward. If downstream users need to query, coordinate, or extract data from the model, choose BIM. If they need to see, measure, or navigate the space, mesh may be sufficient. If both needs exist, use a hybrid workflow that allocates modeling effort where it generates the most value.
The typical scan-to-BIM QA checklist verifies that files are named correctly, views are set up properly, and the model opens without errors. Those are file management checks, not quality checks. They tell you nothing about whether the model accurately represents the physical conditions captured in the point cloud.
An effective QA/QC process validates the accuracy chain from raw scan data through registration, processing, modeling, and final delivery. Each stage introduces potential errors, and each requires specific validation steps.
Quality control starts at the scanner. Before leaving the site, verify scan completeness by reviewing coverage in the field software. Identify gaps where additional stations are needed and capture them while the site is still accessible. Returning to a construction site for supplemental scans adds cost and schedule delay that proper field QC prevents.
Check scan quality metrics including point density at critical areas, noise levels, and target acquisition quality. Scans captured during active construction may contain excessive moving objects that create ghost geometry in the point cloud. Flag these stations for cleaning during processing.
Registration is the foundation of everything downstream. A poorly registered dataset produces a model that looks correct in isolation but does not match real-world coordinates. The consequences show up in the field when prefabricated assemblies do not fit or new systems collide with existing conditions.
Verify registration accuracy against known control points. Compare registered scan positions against survey coordinates. Check bundle adjustment reports for outlier stations that may have shifted during optimization. Any station with residuals exceeding your project tolerance should be investigated and potentially re-registered.
For multi-day scan projects, verify alignment between acquisition sessions. Thermal expansion, settlement, and coordinate system inconsistencies between sessions create systematic errors that propagate through the entire model.
Processed point clouds should be free of noise, moving objects, and artifacts that could mislead modelers. Verify that cleaning operations removed scaffolding, temporary equipment, and personnel without deleting legitimate building geometry.
Check classification accuracy if automated classification was used. Misclassified elements, such as pipes labeled as structural members, create errors that cascade through the modeling process. Spot-check classified data against the raw point cloud to verify algorithmic accuracy.
This is where most QA processes fail. Verifying that a model looks correct on screen is not quality control. Effective model QC requires systematic comparison between the modeled geometry and the source point cloud.
Section cuts through the model overlaid on the point cloud reveal deviations. Check at regular intervals, not just at locations the modeler chose for their own reference. Random sampling catches errors that targeted checks miss because modelers naturally verify their own work at the locations they found challenging.
Measure critical dimensions in the model and compare them against the point cloud. Pipe diameters, duct cross-sections, structural member depths, and clearance dimensions should all fall within project tolerances. Document any deviations and track them through resolution.
The final QC stage verifies that the deliverable package is complete and usable. Model files should open cleanly in the target software version. Linked files should resolve correctly. Coordinate systems should match the project standards. Exported formats should maintain geometric fidelity.
This is also where you verify that scope boundaries were respected. Elements that were explicitly excluded from the modeling scope should not appear in the model. Elements that were required should all be present and at the specified LOD.
An effective scan-to-BIM QA checklist is not a single document. It is a series of stage-gates, each with specific pass/fail criteria tied to project tolerances. Teams that treat QA as a final-step activity miss the compounding effect of early-stage errors. Teams that embed QC at every stage catch problems when they are cheap to fix.