A coordination meeting ends with good news: the BIM model is clash-free. The team issues the package. Then construction begins and the new duct route hits a field-routed pipe that was not modeled. The clash did not exist in BIM because the existing condition was not in BIM. The software did not fail. The reference reality was incomplete.
Scan-based clash detection adds measured visible conditions to the coordination process. It compares new design against the actual environment captured by the scan, either directly through point cloud review or through a scan-derived model. This can expose conflicts that model-versus-model checks miss, especially in renovations, retrofits, and brownfield work.
Key Takeaway
Scan-based clash detection adds measured visible conditions to the coordination process. The right deliverable, accuracy language, scope boundary, and review responsibility should be defined before project teams rely on the data.
The Clash-Free Model That Still Fails On Site
This is why GDS treats scanning as a decision-support workflow, not just a technical field activity. The question is not simply, "Can we scan it?" The more useful question is, "What decision must the data support, and what evidence will make that decision safer?"
Why Model-vs-Model Coordination Is Not Enough
Traditional clash detection checks one modeled design element against another. It works only as well as the models loaded into the coordination environment. If existing structure, field-routed conduit, sagging ductwork, unmodeled supports, or shifted equipment are missing, the clash detector cannot find the conflict.
A scan layer makes existing conditions visible to the coordination process. It does not eliminate the need for review. It changes the question from “Do our models clash with each other?” to “Does the proposed work clash with the measured environment?”
The Five-Phase Model-vs-Reality Clash Workflow
Phase 1 - Capture the existing condition layer
Scan the visible structure, MEP, equipment, routes, clearances, and interfaces that the proposed design could conflict with.
Phase 2 - Build the coordination reference
Prepare the point cloud, mesh, or scan-derived model and document its capture date, coverage, status, and limitations.
Phase 3 - Federate existing and proposed geometry
Bring the scan layer and new design models into the same coordinate system with controlled units and origins.
Phase 4 - Run rules-based and visual checks
Review hard clashes, clearance conflicts, access conflicts, route conflicts, and installation-path risks using defined thresholds.
Phase 5 - Resolve, document, and re-check
Assign issues, revise design, record dispositions, and re-run checks in affected zones before construction release.
Direct Point Cloud vs. Scan-Derived Model
Direct point cloud checking preserves more measured detail and can be faster to prepare. It may also create more false positives from noise, density variation, or rough surfaces. Scan-derived models are cleaner for automated rule checks but include interpretation and may omit small features below the modeling threshold.
The safest workflow preserves the point cloud as source evidence while documenting whether each issue was found against points, mesh, or modeled geometry. Critical issues should be visually confirmed before release.
Clash Types to Review
Scan-based workflows can identify hard clashes, soft clearance conflicts, maintenance access issues, installation path conflicts, route congestion, and drawing-to-reality differences. Not every nearby element is a clash. Insulation, tolerance, thermal movement, access requirements, removal paths, future maintenance, and safety clearances all matter.
Rule settings should be agreed before analysis so the issue log does not become a collection of arbitrary software hits.
Closing Issues Responsibly
A closed software clash does not automatically mean the design is constructible. The responsible discipline should confirm the change, update the model, record the disposition, and re-check affected areas. Where an issue is accepted rather than revised, the concession or design decision should be documented.
Clash Review Priority Selector
Choose the condition creating the most concern. The tool identifies the evidence and review path that should receive early attention.
Quick Facts
Continue Reading
The next best article depends on where you are in the project. These suggested reads connect this topic to the next practical decision your team is likely to face.
Frequently Asked Questions
What is scan-based clash detection?
It is clash detection that includes measured existing conditions from a laser scan, not only proposed design models.
Do you need to model the point cloud first?
Not often. Some workflows check directly against the point cloud, while others use a scan-derived model. Each method has tradeoffs.
Can clash detection support constructability?
No. It can identify modeled or visible geometric conflicts, but constructability also depends on sequence, access, tolerances, labor methods, safety, and engineering judgment.
What should be included in the issue log?
Location, view, clash type, rule, measured clearance, responsible discipline, priority, status, and disposition should be included.
When should scan-based clash detection be run?
Run it when the proposed design is stable enough to coordinate and again after major changes or before package release for high-risk zones.
Connect this article to the right GDS workflow
Most physical-to-digital projects touch more than one service. GDS can help determine whether the right starting point is 3D laser scanning, 3D modeling, reverse engineering, or consulting before scope, pricing, schedule, and deliverables are finalized.
GDS supports projects nationwide. Examples from the current locations page include Houston, Dallas, Austin, and Fort Worth.
Ready to Start?
Tell GDS about your asset, your goals, and your deliverable needs. GDS can scope the right scanning, modeling, and reporting for your project.