In the attached file
Problem Split.3dm.zip (65.9 KB)
I hav a donut shape with surfaces radiating from the center where I want to divide the donut into segments.
If I try to do a boolean split on the lower donut using the surfaces, the operation fails.
I have joined some of the surfaces going through the upper donut to create some Vee-shaped polysurfaces. If I do Boolean Split using that mixture of surfaces and polysurfaces, the operation succeeds: problem solved.
I could not see any reason why one would fail while the other would succeed so I share here.
Yeah… Bolean operations depend on finding an unambiguous inside/outside - the surfaces want to be both - if you give them some thickness they ought to work, otherwise just
Cap the results.
I’m not sure this is the reason - this looks more like a “special case” bug to me. Open surface BooleanSplits work fine - if the surface or surfaces go all the way through the object. If the object has a hole however and all of the cutters end inside the hole, the BooleanSplit fails - as if it was programmed to detect this situation and not go any further.
If even one of the splitting surfaces go all the way through the object, the BooleanSplit then works. In my example below, I can split everything well if only one of the surfaces cuts through the object. I also tried with @miano 's case by extending one of the surfaces, and it seems to succeed as well. However, while I was experimenting I did seem to find a couple of cases where only the surfaces that completely cut through the objects worked to split, but I can’t reproduce those anymore. I’m not sure why exactly.
BooleanSplitExample.3dm (3.4 MB)
Problem Split-msh.3dm (3.2 MB)
In any case, IMO, this could be “tuned up”. It’s a situation that should work, for me it is not ambiguous at all.
Edit: thinking about this further, this probably comes from the fact that if a single surface cuts through a tube at only one spot for example, the split can’t happen because the object is not divided into two separate parts (akin to splitting a circle at only one point). In this case Rhino decides that it shouldn’t attempt the split. However, it looks like it is not programmed to analyze a situation where there are multiple instances of the above that taken together might result in a valid solution.
And… it also does have to do with the “sided-ness” of the surfaces. In the example below, trying to cut the tube with 2 single surfaces that have more or less opposite-facing normals fails. Joining them makes the normals consistent so it succeeds. What really surprised me is that flipping the normals on one of the surfaces also made it work. Clearly this can only work with two unjoined surfaces. Add a third unjoined surface to the mix and it fails again. Join two of the three… it works.
BooleanSplit-Normals.3dm (4.3 MB)
Hi Mitch - yeah, it is a puzzler.
Here’s how it looks to me-
I suppose that if two are joined then the remining one is considered on its own with the remaining part of the ring that it intersects and it works. … but I guess I need to think about that one some more - it fails if there are two more surfaces.
I think the problem is that BooleanSplit still uses one of the the surface normal direction dependent Boolean operations like BooleanDifference - and simply keeps the parts that would normally be discarded.
My premise is that this is counter-productive - since we’re splitting and not trimming, the surface normal directions (of the splitters at least) are no longer relevant. The operation should just split the base surfaces with the splitters, then split the splitter surfaces with the result, retain the part(s) of those necessary to keep the object a closed solid and join. Exactly what one would do manually.
CreateSolid ! (the splitter surfaces go away though)
that too! In fact, I wonder if there is a case where
CreateSolid would not be the equivalent of
BooleanSplit as far as finding the right results, with some bookkeeping for when there are multiple objects to be split, DeleteInput=No, etc.