thank you for the post, it’s very interesting to read about your understanding and usage of Rhino 6’s MeshSplit. There’s no public specification about these details, so you probably checked the results like I did. I also did just that for many cases, because it’s not always easy to understand implications. Rhino 6’s algorithm was based on normals. For simple cases, it used to work fine. But for more complex ones, it very often didn’t get to the final result. For example, try putting either spheres in the first example near one another, across one another, or try to put one inside the other. Do you see the problem?
In Rhino 7, MeshSplit was entirely rewritten, and does not use normals. This means that island treatment works differently and can be tweaked. If we dialog about what you expect, we can see what applications we could get. Otherwise, there might also be some simple checks to get to the computation that you would like. Mesh inclusion in Rhino 7 SR3+ is inexpensive.
Let me enumerate how I would understand this island treatment that you like:
- Define islands as split pieces that come from the same pair of splitter-splittee, and that do not share edges with other split pieces from that pair.
- Islands from the same splitter get joined after the split.
I don’t mind this personally, and might not be immidiate but it’s something that is definitely possible, but I’m trying to think if it would impact users otherwise. What do you think?