A sphere has one edge. If you split the sphere in half in a way such that one half is fully divided by the spheres edge, you get three pieces not two. Would be great if this was fixed. I have automation software that relies on the geometric fact that splitting a convex closed brep with a plane results in no more than two pieces.
Thanks!
can you send us a file with steps to repeat this issue?
also any supporting info like screen shots or recordings and a file with the incorrect result you are seeing would be super helpful.
Here is an image of the setup that causes a sphere to be split into 3 pieces. Notice that one half of this split has an edge bisecting it. This is what causes the issue.
I think repeating this issue should be fairly straight forward using the image provided, but please let me know if you need anything else.
Thanks for the quick response!
right… that would be 100% expected.
you can move the seam by rotating the sphere or moving the seam with the srfseam command.
a sphere is in its essence a 4 sided surface where two edges are collapsed to a singularity, and the other two are coincident.
see this image for what I’m talking about-
in this case, you’d get 3 pieces if you split the sphere like surface
this is exactly same structure is how an actual sphere is structured, so you get the same results.
I disagree that this is the correct behavior. The edge should be “welded”. In not sure if that is the correct term in this instance. Any geometer would agree that splitting any closed convex brep with a flat plane should yield no more than two pieces.
Opening up the sphere, like in your image, creates a completely different situation. That is an open brep. Im using a closed brep.
If I am missing something, please let me know. otherwise agree to disagree.
Thanks.
It is incorrect behavior in the theoretical world of the geometry purist. In the Rhino world, where the developers have chosen, for a variety of practical reasons, to represent a theoretical sphere the way Kyle illustrated it is the correct (and really only possible) behavior.
Kyle showed you the workarounds we all use now that we have come to accept the way it works.
After all, we are modelling the real world, not creating it.
@Nick_Drian note I did not say “correct” I said “expected” 
you are welcome to argue with the devs ad nauseum about “correct” that is way above my pay grade to speak intelligently on the geometrical “correctness” of a Rhino sphere.
All I can do is explain how rhino works at the moment and hope you can adjust your workflow to allow you to get results that work for you.
Well, as a counterpoint to this argument, I would say that Rhino’s behavior in the case illustrated above is… inconsistent.
Lets take a circle as an example - it is after all the basis for a sphere. If you make a circle by clicking a center point and typing a radius, the circle seam will be along the X-Axis (0°). Now, if you split the circle with a vertical line passing through it, one would expect that the behavior would be like that of the sphere - the left part would be one single arc and the right part would be two joined arcs - the joint being the former seam of the circle. But that is not the case - the result is just two continuous arcs, Rhino has automatically eliminated the former curve seam…
In fact I think Rhino did actually leave the seam up to Rhino 3 or 4, it was changed on request.
Rhino copes with a circle that’s split by a line without leaving you with one of the resulting arcs with a join where the seam was. In that sense, Rhino is a bit inconsistent in it’s treatment of the object hierarchy.
Mitch beat me to it by a few seconds 
I think that 3 dimensions does actually complicate the problem quite a bit though. When you split a surface, the parts are not shrunk - if you untrim the split part it becomes whole again (unless you shrink it). So in the case of a sphere part, to have a NURBS surface representation and not just a mathematical construct, Rhino would have to move the seam somewhere else - but the seam would still exist. So how would Rhino decide to move the seam? What happens if the split cuts partially through the seam leaving a singularity on both parts? Depending on the geometry, I can see a lot of “special casing” might need to be done.
I agree. also, very interesting. If they removed the seem for circles, maybe they can do it for spheres too…
If a sphere where composed of two hemisphere surfaces joined together, Then rhino would have the correct and consistent behavior. This solution would be extremely easy to implement. If you agree, please give this a like and maybe we can make a change 
Then there would be two seams…
There would be one seem going all the way around. But at the end of the day, I don’t care how many seems there are, I would just like geometrically sensible behavior during a split.
Let’s say that “all around” seam is horizontal. Now split the sphere in two vertically. You now have two parts, both with seams. Doesn’t help much.
In NURBS modeling, a sphere has two poles (singularities) and a seam. You can move them around, but you can’t eliminate them. If you need more than a half-sphere, there will need to be a seam left somewhere. Half or less sphere parts could theoretically be represented without a seam, but the poles are still there - a sphere is a surface of rotation.
I’m not really sure what you’re getting at. Are you familiar with polysurfaces/breps? “seems”, or edges as they are called in Rhino source codes, don’t matter to me. What matters is that if you split a sphere using a plane, you only get two pieces. One way to make this happen is to have the sphere command create a polysurface composed of two surfaces joined together. The reason that two surfaces is important is that Rhino fails to recognize when a single surface should be connected to itself. With two surfaces, Rhino now realizes that the two faces of the edge are joined together. I feel like I’m beating a dead horse, so signing off 
if you have a closed brep, why not use solid difference/boolean split to get your two parts.
the seam-iness of spheres/ellipsoids only become significant if you then evaluate them as surfaces.
if you need the surfaces, then you can augment your automation software to delete the plane in each new solid that lies in the same plane as the split plane to get two shells.
Boolean split is a great work around, Thanks!
I do still stand by the fact that the current functionality of split is incorrect.
