Why can’t I split/trim/cut this model with the centerline curve, but I can with the other?
TEST_04.3dm (1.1 MB)
I am not sure this is what you wanted but, I exploded it and made a surface from your split curve , then split the part in half and rejoined the each side. I bet you are wanting a better reason why, I am not that smart. —Mark
The bottom surface is causing the problem. If you isolate it, untrim the openings and use the trim curves to retrim then it no longer joins fully onto the rest of the object. I don’t know what process has made it problematic.
I had to isolate and untrim it, then extend the matching edges downward and use them to trim it. The rejoined object splits with the centreline:
Well now, I’ve come back and taken another bite at this and strangely the base isn’t the problem - it split without issue - but there is something else going on to prevent the rest of the model splitting. So, all I can think is that the order of operations I apply to your object is significant…
I’m going to keep worrying at this, but hopefully someone wiser will take a look and discover the root cause.
It is possible to split the object in half without first having to do additional trimming etc..
Switch view to left
Create a cutting plane using the centerline, adjust height and width to make sure it extends to outside the object
Issue split command, select object, enter, select cutting plane, enter and the object is cut in half.
See attached file
TEST_04 split.3dm (858.7 KB)
Hi @Art,
That isn’t working for me with the original object: the split fails. Did you do anything prior to the actions listed?
The object does split as you describe if first I explode it and then re-join the surfaces.
The rebuilt object also splits with the centreline in the top view.
This is getting weird. It is starting to look like instead of exploding and rejoining the entire object to get it to split you can get away with extracting a single surface and rejoining it to the rest. It doesn’t seem to matter which surface you choose. I’ve tried with a variety of surfaces from different positions, reverting to the original model before trying the next, and so far every one causes the subsequent split to work.
@stevebaer, do you or any other McNeelie have an explanation for this?
This is something that happens quite often in my work, but I never paid too much attention to it because by exploding the polysurface and trimming it, I can still split or separate the object. Usually this happens when you cut a symmetrical object and then join it again after using Mirror. If you later try to use Split or trim again while it is still a polysurface, the operation fails. I usually solve it by exploding the object.
I suspect the problem originates with the bad edges in this area of your polysurface.
BadEdgesX.3dm (701.8 KB)
I think the root cause is the triangle shaped planar surface (the bad edges were created when that was joined to its neighbors). To fix it extract the triangle surface and adjacent planar surface and replace then replace both with the Cap command. If you don’t fix it, it is likely to cause similar failures down the road.
Edit:
Also, another thing about your model is the edge tolerance.. When your model is first open Property>Details reports the polysurface has an edge tolerance of 0 to 9 mm. That’s a ridiculously large number. After doing what others have suggested of exploding or extracting and then rejoining the edge tolerance is correctly reported as 0 to .083. That is still out of tolerance but not enough to interfere with splitting. I still suspect the bad edges are the root cause that gets Rhino confused. The edge tolerance is just another manifestation of the problems that causes.
Jeremy, what I couldn’t understand was that I could split/cut it on the back portion, but not the center. (As in my original image) I thought if a model geometry was bad and would not split, it would apply to any attempt to split regardless of location on the bad model? That I could split at other places confused me.
Yep. I remodeled and replaced that area, and it split fine after. However, as many have said, exploding and re-joining made it split work, so could have been just the joining that enabled the action?
These bugs related to huge edge deviation are typical for objects that were originally much smaller, joined, then scaled to 10 times or greater size. Or after converting/importing a file from inches to millimeters.
Thanks for that info. This started as a .stl that I copied. I did explode it get face dimensions, so it is possible a face from the .stl made it into the model. I did not scale the model, but I can’t remember if the original was imperial. When working on small models I do it in metric and often do that conversion.
I recommend you to use this hidden command when you work with imported models (not created by you) or when you scale them while they are joined. It’s capable of detecting geometric issues with trimmed and joined edges that any the rest analysis tools can’t.
“Mark improperly trimmed edges”
'_testMarkOTEdges
Wow! Thanks. I understand the process, but am unfamiliar with many of the commands.
The problem of not being able to split the polysurface is not caused by out-of-tolerance edges. Rhino reports that some edges on this model have deviation of 9mm, but that is just an error. Those edges are not out of tolerance at all. Whatever bug that caused Rhino to get confused and report edges with a huge deviation that wasn’t there may be related to the bug that caused split to fail.
As I said in my earlier post I suspect the thing that got Rhino so confused about edge definitions is the bad edges that I marked. One thing is for sure is that as long as Rhino fails to detect errors like this Rhino will just keep on stumbling and tripping over its own geometry.
STL is a polygon mesh format. That would mean all the faces in this model were made in Rhino.
The bottom surface was subsequently modified and became curved, whereas the vertical surfaces were left straight, this is why joining them is causing issues. The '_testMarkOTEdges command clearly indicates the edges where the deviation is most critical. Set the “display precision” to maximum, then explode the model and show the control points of the surfaces at the bottom. You will quickly discover that the bottom edge of the vertical surfaces is at z=-4,4450000 units, whereas the control points of the bottom surface are at random height such like -4,4586708 etc.
I suspect that the joining of the surfaces was forced either by a coarse scene tolerance setting or by the ! _JoinEdge command.
Also, the diameter of the top round end is not consistent (mostly 66,9999937 mm). Instead, it’s a variable value, which means that the model was either joined with a very coarse file tolerance setting, or created very far from the origin. Or, it was scaled after the joining. An evidence about that is the fact that the inner circular surface of the pocket consists 10 control points along its height instead of 2 control points. These unwanted extra spans are usually generated after multiple scaling or moving of the edges of degree 2 surfaces (cylinder or arc extrusions).
Joining and exploding the model multiple times must be avoided, because the ! _Join command is a bit of cheating - it uses double the file tolerance setting to make sure that the adjacent surfaces built within tolerance (lets say 0,01 mm) will join successfully. In this case, the joining process uses a temporary 2x tolerance (0,02 mm) to overcome the slight deviations. Once you explode a joined polysurface, its surface edges are no longer accurate, because some of them may inherit the double tolerance of the ! _Join command. When you repeat that process multiple times, the deviation may increase even more.
It’s recommended to use “Join” only when you are ready with the modeling and want to export the final model.
If you use ! _Join command as a way to test whether the edges will join together, then it’s recommended to use Undo instead of ! _Explode. Or “Global edge continuity” set to G0 with the desired tolerance.
Also, when you explode a polysurface that needs a further work, either use ! _Untrim or ! _RebuildEdges to each surface to restore its original state and get rid of the possible microscopic zig-zaging of the trimmed and joined edges. My video above shows exactly that type of deviation caused by creating the model far from the scene origin.
Thanks again for this education. I discovered the above before you pointed it out when I tried another modification. 
All the spots marked by the command. I was surprised at the one on the top of the circle, then I had a problem show up there while modeling. After my rebuild, '_testMarkOTEdges only found 1 poor edge, which I was now able to fix.
Amazing how a small adjustment could screw up so much. I thought I had adequate modeling skills for these simple models, but I’ve been away from Rhino for a bit. Obviously, my skills have backslid. Thanks so much for this instruction.
Gracias amigos.