Clash detection and getting to a coordinated model

📖 10-minute read · Intermediate

Clash detection is easy to run and hard to use. The first run on a real project returns thousands of hits, most of which do not matter, and teams routinely abandon the process at that point. This guide is about the difference between finding clashes and resolving them.

What a clash actually is

At its simplest, a clash is two pieces of geometry occupying the same space. A duct through a beam. A pipe through a column.

But "occupying the same space" is a poor definition of a problem. Consider:

A pipe passing through a wall — intended, that is what a sleeve is for.
Insulation touching the pipe it insulates — a mathematical overlap, not a conflict.
A beam meeting a column at a joint — that is the structure working.
Two ducts 5 mm apart — no overlap at all, but nobody can install either one.

The last is the important one. Geometric overlap and buildability are different questions. Things that do not touch can still be impossible to build, and things that overlap can be perfectly correct. A clash report that only answers the geometry question is mostly noise.

How detection works

Testing every element against every other element is unworkable — a model with 50,000 elements would need over a billion comparisons. So detection runs in stages, each cheap and approximate, narrowing the field for the next.

Broad phase. Every element is reduced to a simple box and boxes are tested for overlap. Crude, but it eliminates almost everything instantly. The boxes are padded by about 50 mm so near-misses survive into the next stage.
Narrow phase. Surviving pairs are tested against a tree of tighter, rotated boxes — which matters for anything long and diagonal, where an upright box is a poor fit.
Triangle test. Only pairs that survive both get an exact surface-against-surface test.

This is why a run takes minutes rather than days, and why the reported volume of a clash is an estimate rather than an exact intersection — computing true intersection volumes for every hit would cost far more than it is worth for a number used to sort a list.

Tolerance and clearance — not what they sound like

This is the part most worth reading carefully, because the names are misleading.

Which pairs of things get checked, and how strictly, is set by a matrix of rules. Each rule pairs two categories and gives them a tolerance:

Pair	Tolerance	Severity
Duct vs structural beam	Hard	High
Structural column vs architectural wall	Hard	High
Sprinkler vs duct	Clearance 100 mm	High
Duct vs duct	Clearance 100 mm	Medium
Pipe vs pipe	Clearance 50 mm	Medium
Light fitting vs ceiling	Clearance 50 mm	Low

Services against structure are hard — any overlap is a problem, because you cannot route a duct through a beam without someone approving a penetration.

A clearance setting relaxes detection; it does not widen it. "Clearance 50 mm" does not mean "report anything within 50 mm". It means "tolerate up to 50 mm of genuine overlap before treating it as a clash". Two pipes 30 mm apart are not reported at all, because they do not overlap. If you need true proximity checking for access or insulation space, do not rely on clearance rules to provide it.

Each rule also carries an owning discipline and a stage gate, so structural conflicts can be raised at design development while service-against-service congestion waits for coordination stage — matching the order in which the work is actually resolvable.

Filtering the noise

Separately from the matrix, a set of rules classifies hits as genuine, intentional, or artefacts of how geometry is represented. Curved surfaces are approximated by flat triangles, and two nominally touching curved surfaces will overlap slightly — a real number, not a real problem.

Thresholds matter enormously here, and one example is instructive. The rule that recognises structural joints originally ignored overlaps below a 10 cm cube. Real beam-to-column joints routinely overlap 30–80 cm in each direction, so every joint in the building was reported as a clash. The threshold is now around 500 litres. A filter set too tight is indistinguishable from no filter at all.

Where several rules apply, the strictest verdict wins rather than the first one matched — so the order rules are listed in cannot silently change the result.

Grouping — 3,000 clashes into 40 problems

The single biggest step from raw output to usable output. One misrouted duct crossing twenty beams is one mistake with one fix, but naive detection reports it as twenty clashes. STING groups in three passes:

By element — the same element appearing repeatedly becomes one group. Fix the duct, clear twenty hits.
By pattern — evenly spaced repetition, such as a riser hitting every floor or a light row hitting every ceiling tile, becomes one group with a recognisable shape.
By location — whatever remains clusters spatially, so one congested plant room is one item on the list rather than sixty.

The spatial grid adapts to what is being grouped: small light fittings cluster at around a metre, large plant against structure at several metres. A fixed grid over-clusters the small things and under-clusters the large ones.

How STING approaches it

Clash tools sit on the BIM tab of the main panel.

Detect — run detection.
Run — the full pipeline through to stored results.
X-Model — extend across linked models. This is where the real conflicts live: your services against someone else's structure. A model checked only against itself will look far cleaner than the project actually is.
Matrix — edit which pairs are checked and how strictly.
Refresh — re-run against the current model.
Manager — work through results.
BCF — export findings.

Detection runs inside Revit against your model. It is not a streamed feed from a server, so results reflect the model as it is on your machine right now.

Getting issues to the rest of the team

BCF is the open format for construction issues, and STING exports BCF 2.1 — readable by Solibri, BIMcollab, Navisworks and Autodesk Construction Cloud. Each issue carries a viewpoint, so opening it puts the recipient's camera on the problem rather than leaving them to find it.

One detail that matters more than it sounds: each issue gets an identifier derived from the clash itself, so re-exporting after a second run produces the same identifier for an unresolved clash. Without that, every weekly export would land as a fresh batch of duplicates and the issue tracker would become useless within a month.

Severity maps onto the priority levels those tools expect, so a critical clash arrives as critical rather than flattening to a default.

Getting to a coordinated model

Set the matrix before the first run. Running everything against everything produces a number so large it teaches the team the report is not worth reading.
Run cross-model. Single-model results are reassuring and misleading.
Work groups, not clashes. The list of forty grouped problems is the real agenda. Twenty hits from one duct is one conversation.
Fix causes. If a service crosses a structural zone repeatedly, the route is wrong — nudging each crossing individually guarantees they return next week.
Export to BCF and assign owners. A clash nobody owns does not get fixed.
Re-run and compare. What matters is the trend: are groups closing faster than new ones appear.

The number to watch is not clashes found — that number reflects how much of the building is modelled as much as how well it is coordinated. Watch how many grouped problems are open, and how long they stay open.

That completes the current guide set. If something you needed is not covered, email hello@planscape.build — the answer usually becomes the next guide.