There are a few overriden Brep.Split methods.
The ones that take a Brep paramter as the splitter call RHC_RhinoBrepSplit internally.
The ones that take an enumerable as the splitters call RHC_RhinoBrepSplit2 internally.
The two internal methods have very different behaviours.
So Splitee.Split(Splitter, t); gives me different results than calling Splitee.Split(new Brep{Splitter}, t);
The differences are the number of Breps returned and their indexes differ.
I noticed this because I was adding splitters to a List and taking the returned brep at index 0. I then realised that I could get what I wanted by just splitting with a single Brep so I used the Brep parameter version of Split.
Doing the above broke my code because the Brep I wanted was now returned at index 1 as opposed to index 0.
I imagine that this is hard to follow so I have included a 3dm file that shows the green Brep that will be split by the red Brep. From the split I want the top part, the part above the red splitter.
split-differences.3dm (968.1 KB)
To investigate the problem, I wrote some code to do the different splits. I wrote the returned parts to the file and associated a user string with each part to identify it. I then manually moved the parts into layers to identify them.
You can see the results of the Brep parameter splits under the brep layer, and the results of the enumerable parameter split under the enum layer. These layers are under the parts layer.
The code was initially part of a, compiled, c# grasshopper component. But I rewrote the code as a c# grasshopper script node that you can run yourself, if you are interested. Just enable the node. I internalised the splitee and splitter so you don’t need the 3dm file to run it.
Here is the grasshopper file that shows the code.
split-differences.gh (150.3 KB)
I haven’t marked this as a bug because people could have written code that depends on these different behaviours and a fix could break existing code.
I’m just posting this as a heads up for people who haven’t spotted the problem, to save them wasting time debugging why their code just broke. Well, they will still have to debug but they will have an idea what to look out for and how to spot the index that they want.