Problem with surface.booleanIntersect




I’m trying to create a freeform gridshell structure with grasshopper and coding and for the data handling I’ve created two classes in ghpython object:

Risteyspiste: In this class i’ll save all the lines connected to a grid point.

Sauva: In this class i’ll save all the points (Risteyspiste) connected to a grid line and also all the geometry i’ll derive from the line (brep)

I have done all the data management coding and all the data seems to be nice and tidy in their own class instances. The next step I’m doing is cutting the ends of the beams with the crossing beams. I’m doing this with rhinocommon.surface.booleandifference method. Everything works nicely if i pick one beam and the crossing beams. (btw I’ve done some scaling for the crossing beams (picture below) so that I can create a clean cut).

In below is my code for this:

So what the code does it goes through all the instances in Sauva class. first it saves the extrusion related to that line to a variable extrusionList1 after that it checks that does the beam have two cutting objects (jatkuvaSauva1 and jatkuvaSauva2) if it does it gets the cutting extrusions from those instances and saves them to the extrusionList2 after that the code does the booleandifference and saves the new brep to a designated variable in Sauva instance.

So the problem is that the booleandifference fails after three loops and it fails for perfectly fine geometry (in below: the cutting objects are in green and the object to be cut in red). I’ve tried to add these objects to another component and do the boolean difference and it still fails. I can do the boolean difference with grasshopper component and if i bake these objects and the bring them back to grasshopper as reference I can do the boolean difference to them with the rhinocommon method. Any ideas whats wrong?

ps. I’ve posted this post in grasshopper forums already, so If you see this twice sorry for the double post.

(Giulio Piacentino) #2

Hi @Matti_Pirinen,

what happens if you run brep.Faces.SplitKinkyFaces() before running the Boolean operation?

Background info: RH-23423. This is a bug that has, at least partially, been addressed within the improvements to Booleans in V6.


Giulio Piacentino
for Robert McNeel & Associates


Oh my! It is finally working. It has been a rocky road with this one. I’ve been doing debugging for about 8 hours without much success :). Thanks for you help!



Just got another problem with the boolean intersect. In some cases the boolean intersect results not the geometry that is outside of the cutting geometry but the geometry that is inside of it (see picture below). Any ideas why?

(Giulio Piacentino) #5

About the latter picture, I am unable to say much without the definition. Just remember that solid Booleans search for volumes, not for areas, of intersection.



The definition is the same that was posted in the first post. now im just using this ellipse shaped brep instead of the rectangular object as cutting object. I’ve made sure that the brep is is actually solid before making the boolean intersect. The picture I posted below above might lie a bit in that recard that the cutting object has thickness off 10mm so it looks like surface. I’ve tried also with thicker object but had no success.

(Giulio Piacentino) #7

@Matti_Pirinen could you please add a new definition (as simple as possible) that shows:

  • what you get
  • a picture or a manual model of what you expect to get from the definition?

Thanks! (PS: please @-mention me to get a faster reply)


Giulio Piacentino
for Robert McNeel & Associates


@piac I figured it out. The geometry shown in the picture above was created with brep.CreateFromSweep method. I had created another geometry before which was created from a closed curve. With this geometry the Boolean difference worked just fine. However now that my curve wasn’t closed the createFromSweep command didnt create automatically a solid. So I hadn’t capped the holes at the end of my geometry and because of that the boolean difference gave a funky result. Thank you from your help and sorry for the inconvenience.

(Giulio Piacentino) #9

No problem and I’m happy I could help @Matti_Pirinen