Clash Improvement requests

I just tested this feature and find that the way clashes are displayed makes it utterly useless.

First, the bounding box should either be replaced by
-A dot with the approximate clash volume and color gradient tied to the clash volume range.
-Or a Minimal bounding box which would give a more accurate representation of the intersection shape and size

These bounding boxes aligned with the World X,Y,Z are surely fast to draw, but are in fact mostly misleading.

Then, there’s the fact that one can only toggle from clash one to the other (yay) , but once you hit “Done”, there’s nothing left !
What are we to do ? Remember every spot where there was a clash ?

I don’t know about the accuracy of the algorithm which finds the clashes, but one thing is for sure : I can’t use this for any practical purpose.

We have a great script that takes a long time to run (on the plus side, it justifies the coffee break), but which is actually useful :
-It can look for clashes within blocks , between all blocks , between two sets of blocks
-It creates the intersecting solids and bakes them in a specific layer for further review

This allows to sort clashes by importance and potentially neglect clashes which have no actual ill effect.

I need to check out the Grasshopper component though because it could allow to make this command actually useful.

1 Like

The GH version does not appear to be multi-threaded :

Generally, as it seems this component ist ment to be used in the AEC industry. It might make sense to take a look at the BCF Format as a standardized way to handle clashes:

Also. A Minumum clash size should be definable as well. In some cases a clash of 0.1mm is too much. in other cases clashes of several mm in size can be ignored.



Hi there,

is there a way to set the GH component so that it allows objects to touch without detecting a clash?
I’d like to use it for clash detection between walls and floor in revit. Currently I get clashes for walls that are modeled correctly right ontop of a floor.
I tried setting the distance to 0 but this doesn’t give me the result I’m looking for.


Hello @scottd ,

Any progress with clash detection ?

Do you mean as is it multi-threaded? It is. The reason does not show multi-threaded on the Grasshopper component is that the Grasshopper component is not multi-threaded, but the calculations in the core of Rhino are.

Well, OK, that’s the easy bit.
What about my other remarks ?

I am working through the other remarks here. I think most of the prototyping will come out of the Grasshopper component.

There are two ways to clash objects.

  1. Fast - Mesh based, not concerned with the amount of clash, just that there is a clash. That is the new Grasshopper component.
  2. Slower - Brep based and can create an actual volume of the clash.

So, I thinks what we are looking at here is to use the fast clash to reduce the potential clash tests needed. Then use the more accurate clash to determine volume and shape of each clash. I was going to give that a try in Grasshopper and see if we can get the information requested. We also may be able to eliminate small clashes.

Once we get a workflow in Grasshopper, we can discuss how we might change the UI in the Clash command. Hopefully later today I might have some experiments.

1 Like

Thanks for your Answer Scott.

Why can’t there be mesh clash intersection volumes ?
That would probably require some work on the mesh intersection tools which are notably unreliable in Rhino, but I think that it would be the way to go for fast, useful intersection information (quantitatively and qualitatively speaking).
I suspect thats’ exactly the way most BIM tools do at present since IFC 2x3 can’t deal with NURBS geometry.

We are also working on much better mesh intersection in Rhino 7 also. It is a core change, so we will see what the results are. It is not that we cannot do Mesh intersections with volume, it is a question of speed. This looks like it needs to be a two step process. Essential pre-process the thousands and thousands of objects to see if there is an intersection. Then use the relatively slower process to determine the amount of intersection. Whether it is BRep or mesh on the volume intersections is still slower then the single clash approach.


Here is a definition that takes two sets of brep solids and returns the actual geomtry of each the intersections baked onto the current layer if the toggle is set to True at the end of the definition.

Is the better information? (25.4 KB)

1 Like


First of all, the component should not dive into a deep computation when one of the two sets of objects is not yet referenced : why compute when there is nothing to compute ?

I didn’t push things further because I consider that, if on such a meagre selection set, the component puts my powerful machine in a coma, it’s not going to cut it with the real meat I need to deal with.

I just gave your component a try where I referenced a cylinder in the first set, and another cylinder in the second set.
It took 28 seconds to reference the first one, and 34 seconds for the second.
…and in the end, the boolean failed.

two cylinders.3dm (91.2 KB)

Now, if I move those cylinders closer to the origin, the referencing process is much faster.
The boolean still fails, but I’ve got quite accustomed to that in Rhino ; no big surprise here.

If this tool is so sensitive to coordinates, it’s not going to work for me : I use millimeters on large buildings.
I was rather positively impressed at the ability of Rhino V6 to handle these “objects far from the origin” situations, but your intersector clearly can’t handle this for now.

1 Like

This is a prototypw, you have control over how it works. If you do not want grasshopper to actual calculate until the selection is ready them turn off the solution for while you select. Grasshopper will recalculate at every change unless the solver is disabled. And if it is slower then you want, then disable the Boolean operation to really see what does you can get.

I’m sorry, but for an intersection algorithm to calculate stuff when only one of the operands is defined, there has to be something wrong with the way it is programmed.
Grasshopper has nothing to do with it ; it’s just a matter of logic.

Moreover, the fact that it takes so long to compute for objects far from the origin is a no-go for me.

That’s what I did ! the slow part is the clash detection !
The boolean is just “fast to fail”, as is customary with Rhino booleans.

I can test this model. It previous versions of rhino could do this, then we should have something we can look at.

There is always the spectre of the standard state plane coordinate problem and the limitation of the Intel significant digits. Leaving models far away from 0,0,0 leads to a lack of accuracy that can show up in small detailed calculations. It has been discussed here before.
Thanks for the sample model.

Two cylinders.
Far from the origin.

You’re welcome.

Just FYI, they are part of a 1.6 GB model which has parts even much further from the origin.
In Rhino V5, this would have been impossible to deal with, but in Rhino V6, no problem.

And the model is not “far from the origin” like the survey guys like to do.
It’s a huge building, AROUND the origin, and in mm, as any special structure digital model should be.

Real world stuff, which could use a super-efficient clash detector.

So, there is a bunch of issues here and we need to kind of discuss them one at a time. As I see it we have:

  1. Clash detector - single point of clash between two groups of objects.
  2. Large coordinate booleans
  3. Difficult Boolean conditions - Cylinder to cylinder

The clash detector in Grasshopper. Can it find the clashes in an efficient way? Not the volume or amount of clash, just the fact that there is a clash. How long to that take on the 1.6 GB model?

The Clash is setup to try and clash two separate groups of objects, not really find clashes between the same set of objects. So walls to pipes for instance.

The other two issues of large coordinate intersections and boolean falures in difficult situations are well covered in this forum.

The newest clash detector can now take a negative value for clearance. This means that objects that slightly touch can be eliminated by using a small negative tolerance.

That’s great news!

Thank you for remembering me!