Boolean difference in gh much slower than in Rhino (137.3 KB)

In this simplified example (I cut part of the model for IP reasons) it takes 14+ seconds to calculate, whereas in Rhino this goes almost instantly. When I leave the cut-off part in tact the calculation takes even much longer (43 seconds). The amount of faces in the polysurface seems to have huge impact on calculation time.

The same using python / Rhino common takes 1.1 seconds (using the brep lists variant of Boolean difference) So my guess is that the current SolidDifference tool in gh uses the first implementation of BooleanDifference. Could well be the same with SolidDifference, I haven’t checked yet

So this solution is actually much faster than the built in solid difference. the one that took 43 seconds takes 2.8 seconds now for substracting 24 objects from the original solid. But still it is slower than Rhino, the python version takes 1.8 seconds with only one object

Are you explicitly setting the tolerance in your scripting implementations? I believe the native Grasshopper components uses the Rhino document tolerance. This might be part of the explanation.

I don’t quite understand your conclusion, because if gh uses my native Rhino tolerance, then the Boolean difference should take about as long in Rhino as it would in gh. When I use the first implementation of Boolean difference of rhino common, it takes about as long in python as it does in gh. Therefore I assume gh native component uses this rhino common method rather than the second implementation doing the Boolean difference by sets

@pascal @wim ?

Just guessing at part of this, that the relatively small difference between the faster GH way and the native Rhino way we can put down to the extra layers of GH, dotNet, Python, that GH must wade through to get it done. But, I have not ideas beyond that - @chuck - is in charge of Rhino Boolean operations, but I do not know how much of that is relevant to the GH component…


did you see also my second post, where I used a different method in a gh python component that speeds things up considerably?

If I remember correctly, in order to make the dotNet calls happy and threadsafe, all of the surface trees and other cached information is created on a dotNet polysurface beforehand. This eliminated a huge number of crashes at the expense of creating caches on surfaces that don’t need them for a particular boolean operation, and could be the source of the difference. @stevebaer does this sound familiar?

@pascal feel free to create a YT issue for this and put it on my list