Python: BooleanUnion


#1

Hi,

I’m writing a small script in python within grasshopper. I have two objects I want to boolean together, in some cases these to objects do no touch and I was expecting to get an error but I do not. I get returned the first element of the list.
So my question i:. Is it possible to return None/Error when the 2 objects are unable to join?

Thanks,
Miguel


#2

Hi Miguel,

Rhinoscript syntax method rs.BooleanUnion() returns a list of guids with following elements: a guid of a newly created geometry made from union of initial two; or if those two initial geometries do not touch each other, it will return their original guids. This could be used to construct a conditional, to achieve a bit of what you want to do:

import rhinoscriptsyntax as rs

guids = rs.GetObjects("choose two geometry to union")

union = rs.BooleanUnion(guids)
if len(union)<2:
    print "Union successful"
else:
    return None # or "Error"

Sorry if this is not what you’re looking for.


#3

Hi @djordje,

thanks for your quick reply. The thing is that the union list that I get, only contains one element. So your solution wont work.

-M


(Willem Derks) #4

Hi Miguel,

FWIW:
I’m not able to test it, But I suspect the returned guid is equal to either of the inputs when the union fails.
Upon success a different guid is returned…?

_Willem


#5

Actually, running objects through rs.BooleanUnion will return new GUIDS even if no union is found. @stevebaer This is IMO incorrect behavior, but that’s how it currently works. Worse, if the optional delete_input argument is set to False, new duplicate objects are returned and added to the file anyway… VB Rhinoscriptsyntax correctly returns Null (None) if the objects do not intersect.

OTOH, rs.BooleanUnion of two objects that don’t intersect in Python returns two objects (with different ID’s from their original ones), so if you’re only getting one, something else is going on…

–Mitch


#6

If I use the Solid Union component from grasshopper I get the same result. I’ve attached a file, maybe it helps to narrow down the problem. I think it might be specific to the geometry, because I’ve tried the BU with another set of breps and it wont give me an error, but it will return a list with two elements.

-Miguel

BooleanUnion.gh(16.5 KB).


#7

Ok, so I am getting extremely confused. I think it might be a BUG. I’ve uploaded a second file with both internalized geometry from another GH file and the same geometry baked first and later internalized. I get 2 different results.

Internalized data from another GH file:
1.- if i do a solid union the result is the boolean intersection.
2.- if i do a solid intersection I get the boolean union.

Baked Geometry First and later interlnalized
1.- Get a solid union as expected
2.- Get a solid intersection as expected.

Maybe @stevebaer or @DavidRutten might have some clue of whats going on.

Thanks,

-Miguel

BooleanUnion_2.gh(32.5 KB)


#8

Interestingly when breps are baked, the script works with no problem:

import rhinoscriptsyntax as rs

def union(x):
    union = rs.BooleanUnion(x)
    if len(union)<2:
        return union
    else:
        return None #or "Error"

a = union(breps)

BooleanUnion2.gh(3.3 KB)

BooleanUnion2.3dm(108.9 KB)


#9

Normally, if you are getting unexpected (reversed) results from Boolean operations it is because one of the BReps you think is closed isn’t… and it’s got its normals facing inwards which will give inverse results from what you expect.

The fact that a solid union component on two disjoint BReps yields two BReps (the two originals) means it has the same behavior as the Python BooleanUnion method. That makes sense because both Python and GH are based on RhinoCommon and are calling the same code - namely

Rhino.Geometry.Brep.CreateBooleanUnion(breps, tolerance)

behind the scenes. This is supposed to return “An array of Brep results or null on failure.” The question is if the result of running a BooleanUnion on two disjoint BReps is to be considered a “failure” and return null or none… I seem to recall we have discussed this previously…

–Mitch