After a BooleanUnion I got this:
What I was expecting to see was a single object shaped like the input I recovered from Undo:
Is there any circumstance in which BooelanUnion should discard input?
What I was expecting to see was a single object shaped like the input I recovered from Undo:
Post the 3dm file please.
Are all polysurfaces closed ?
Check with selection command s that start with
_selclosed… …
Or
_selopen
Or
Prooerties
Or command line feedback
Use
_dir
To check if normals point outward
If none of this helps it s impossible to help from a Screenshot.
I didn’t recall using any tool that should have yielded a polysurface that wasn’t closed, but the “cap” command closed 74 polysurfaces and then the BooleanUnion succeeded.
Thanks!
For history on why I had 74 polysurfaces that needed to be capped, I’ve had to fall back on using Split because BooleanSplit didn’t seem to be doing what the instructions said:
I really appreciate the heads-up the Boolean was failing due to unnoticed open surfaces. Thanks again!
happy to help - but please mark my post above as solution, so others don t need to dig into the topic to see that it s already solved. thanks - kind regards -tom
I just marked it as a solution. In case someone is reading along, I’ll repeat the cure was to “Cap” the whole selection so Rhino would close the open polysurfaces. In this particular selection this solution worked, because “cap” was capable of closing the tube shapes I was using but this isn’t always the case.
When making closed shapes using different techniques (e.g., adding a “roof” to irregular groups of exterior walls) it’s easy to make something that appears to be closed but isn’t, and which “cap” can’t fix. It’d be nice if Rhino had a mode that would ensure all resulting objects from operations were closed polysurfaces (or at least all objects on layers set to enforce polysurface-only behavior) in order to give those trying to make 3D models a better shot at creating 3D models instead of accidental open surfaces, which I’ve ended up with while trying to make a roof for irregularly-shaped structures … sometimes snaps hit something tiny that looks right but at the scale of the UI isn’t clearly a miss. It’s frustrating to have something that’s been built up from many components or operations suddenly fail a BooleanUnion for reasons you can’t discover, leading to weird rendering artifacts that make an image look like it’s full of errors simply because the surfaces can’t be merged.
@CD_Lewis -
Maybe it would be good to read up on how Boolean operations actually work - here:
https://wiki.mcneel.com/rhino/booleanfaq
And, after having done that, if you still have a situation with operations that are not working as you think they should, please post a file so people can check.
Here’s a simple file whose contents demonstrate the problem I’ve mentioned before in which BooleanSplit makes a union with the cutting object in Rhino 8.
Start with the leftmost object
BooleanSplit
select the large flat irregularly-shaped yellow object as object to be split
Select blue rectangular solid as cutting object
RESULT (as seen on far right):
(1) The unchanged irregular yellow shape
(2) The unchanged rectangular solid
(3) The union of the two objects, colored yellow (shown separated in the middle).
I asked about this elsewhere to no result, and it seems related to the weird behavior I’ve got with Boolean operations in Rhino 8.
BooleanSplit does Union.3dm (488.1 KB)
did you read the recommondation ?
if boolean operations check the result of
_intersect
or
_intersect2Sets
in the file you posted:
zooming further in
_dupEdge (the cyan curve)
_pull to the face of the box (red curve)
see the deviation (x)
in above link you will find:
→ Known Rhino limitations
- Coplanar faces
- Nearly tangent surfaces
you can also use _trim and _join instead of all boolean operations (if the input is precise enough, which is not the case in the posted file)
hope this helps - kind regards -tom
I have seen Rhino sometimes leave a tiny little plane where a BooleanSplit was employed on a target that shared one surface with its cutting object, but how on Earth would anyone ever expect BooleanSplit to UNION the target and a cutting object? The problem you’re describing doesn’t generate the mysterious result I show.
Trim leaves open objects and “cap” won’t reliably close irregular shapes. It’s why I’m using boolean operations and not trim or split.
Are we supposed to expect BooleanSplit to UNION the objects without actually delivering even a split of a slightly off-kilter object? The latter, I learned to handle in Rhino 7. This behavior is new to me and frankly weird. It’s the wrong operation. I ask BooleanSplit and get BooleanUnion. That’s really supposed to happen to users of BooleanSplit?
what are you after ? what s the target geometry ?
for any usable result you have to correct the imprecision I mentioned above.
then my guess are 2 solutions:
left
_scale the blue box to increase the unused faces - to get rid of the imprecision
_delete the unused faces to better show the intend
_split
right
_scale the blue box to increase the unused faces - to get rid of the imprecision
_cap the grey surface
_booleanSplit
_delete the surface created by cap
booleans and open (poly)surfaces
…and read above linked article please.
Boolean Operations best deliver expected results for closed solid (Poly)Surfaces with outwards normals.
Boolean Operations work only if the intersection result is a closed Curve / Loop / Polycurve (details in the article)
Boolean Operations work for open surfaces if you know how.
I normally teach to use Boolean Operations only for Solids. For anything else I teach the students to use
_trim or _split
and
_join
and for error findings use _intersect2Sets (and follow the knowledge from above article)
kind regards - tom
I think someone is missing the forest for the trees. The purpose of the post is not to solicit feedback whether I should call BooleanDifference on an object when its cutting object is oriented differently or is larger, the purpose is to point out Rhino isn’t delivering what the description of BooleanSplit describes, it’s delivering what the description of BooleanUnion describes.
When you can tell me why the BooleanSplit function delivers BoleanUnion results, I may be in a position to care whether I like the result of BooleanSplit. Right now I’m not getting BooleanSplit at all, I’m getting the result I would expect from the description of the BooleanUnion function.
Perhaps if you are getting a different result than I do, that’s something McNeel would be interested in, but it has nothing to do with my problem. My problem is illustrated in the unioned yellow solid in the file I uploaded. For those who didn’t open it, the left has the overlapping solids and after calling BooleanSplit I get the two solids added instead of the blue solid subtracted from the yellow object:
Why does BooleanSplit deliver BooleanUnion? Is there some setting one could expect to deliver this or is it as nonsensical to everyone else as it is to someone whose expectation of these functions flows solely and exclusively from McNeel’s documentation of the BooleanSplit and BooleanUnion functions?
some related topics: