Trim / split inconsistency

I attach a very simple file which demonstrates this, but in words the problem is this:

An extrusion can be split or trimmed with a line regardless of where the line is as long as it crosses the extrusion in the viewport used for the command.
A 2D entity however, can be trimmed as above, but it can’t be split if the line is not actually intersecting the entity.

Why? It drives me nuts, especially as I can see no logical reason why it should be so…?? It just feels like an oversight that both these similar commands don’t follow the same rule…?

[In the file, with the right viewport being active, any of the lines will TRIM the objects, but the red line will not SPLIT the circle, because it doesn’t actually intersect it, even though a similar non-intersecting line will split the extrusion.]

oops - here is the file…trim-split.3dm (41.9 KB)

Correct. Trim and Osnaps have the ability to use apparent intersections or not.
Split does not have that capability.
If you turn off using apparent intersections then Trim works like Split.
It sounds like you would rather have Split have the option of using apparent intersections.
I don’t know why Rhino works that way but you’re right it does.
I routinely run with using apparent intersections turned off so I don’t get into unexpected problems.

Thanks John - Well, surely now is the time to look at this and re-code so split can use apparent intersections?

If no-one can come up with a good reason for this behavior, then it would be great to clean this up before V6 is released…?


Too late or that. V6 is on rails at this point.
I half remember this came up with V2 or V3, and there was some specific reason at that time.
I’ll see if it’s on the wish-list on Monday when we’re back in the office.

The "use apparent intersection " function only applies to curve-curve intersection points. It doesn’t have anything to do with trimming surfaces or extrusions.

If you want to split a curve with the apparent intersection of another curve you have to use the “point” option in Split command. You then can explicitly pick each apparent intersection point where you want a split.
However, you will only see the “point” option if you are trying to split one curve. If you want to split more than one curve you will need to repeat the split command for each curve.

Trim has its own “ApparentIntersections” option which functions as @rabbit described… I believe that is what @rabbit and @John_Brock are referring to.

Well, I’ve had this discussion several times here, the most recent being just a month ago…

The “official” line is that because the cutting objects are chosen last and that you could choose those in several different viewports, that the apparent view might be considered ambiguous… Thus it has never been wishlisted as far as I know.

I don’t actually buy this completely as this situation just demands that the user be conscious of what view they’re in when they finish the command - something that is also required when trimming with apparent intersections.

But in the end, I gave up on this long-standing request, and just use my own scripted functions when I need.


He didn’t mention “ApparentIntersections” option in trim. But one can suppose that is what he wants included in the split command. The trimming of extrusions has nothing to do with “ApparentIntersections” option. Trimming an extrusion will work the same if that option is on or off

That is a pretty empty excuse. because the cutting objects are chosen last and you can choose those in several different viewports for splitting everything else besides curves. So why is that a problem when splitting curves?

Hi Jim, all - I don’t know for sure - I think @theoutside has asked one of the developers if this can be tuned up, but I am just guessing that the apparent is less clear in Split because the relevant view is not predictable - i.e splitting occurs when the selection is done, not per pick, and that the rules for whether to pull or project curves do not apply, fully, to target curves since they cannot pull like surfaces. Surfaces are not split to apparent intersections unless things are lined up right.



First of all, as I said one can already split curves using apparent intersections by selecting the “point” option in split and using intersection snap to select the apparent intersection points one by one.

I assume people are asking so that they have a less tedious way to do it and I guess the way it would work is that the last view where the last cutter curve was picked would be used to determine which intersections are apparent. My point was that is how it already works for splitting surfaces. Split uses the last cutter pick to determine the view for projecting curves. So that means if you pick cutters in different order in different views you may get different and possibly unexpected split results. I suspect people rarely change views when picking cutters so its never been a problem.

That may be true, but its also misleading. The important fact that users should understand is that the “use apparent intersections” options only affect trimming curves and snapping to apparent curve curve intersections. You can turn those options on or off and the way split or trim works on surfaces and polysurfaces will not change.

As far as a consistent user interface goes, it seems to me that split and trim are the same thing, in that if the trim command had an option for “KeepAll” like wirecut does, then they could indeed be the same command ie the split command is redundant.

Likewise, in terms of consistency, why does wirecut step out of line and not ask for “enter” after selecting the cutter (yes I know - because it only allows one line to be the cutter), but the majority of other rhino commands expect an enter to accept the options chosen, with the result that every time i go to use wirecut, i have to restart it several times because I automatically press enter after choosing the cutter, and the command terminates.

The argument is not whether one way of doing this is better than the other; the argument is that we have two interface methods, whereas we should only have one, which is consistent throughout the program.

There are plenty of these kind of interface inconsistencies and methodologies throughout the program, and I’d welcome a good cleanout and rationalisation of the whole thing; its a shame that it looks like this won’t happen before V6 is released…