Wish: Failed split to become smarter and more user-friendly

Quite often Rhino fails to make a successful split of a surface or a polysurface, and the Command line warning says: “Split failed, objects may not intersect or intersections may not split object.”
Currently, right after the aforementioned warning message, Rhino will “forget” and deselect all the cutting objects that were chosen for the “Split” command, forcing the user to selected them again. Rhino would be much more user-friendly if it lets you continue adding more cutting objects after the warning message, which indicated that the last selection was not enough to make a proper split. Being able to add extra cutting objects while the previously selected ones are still active would save a lot of time, and reduce the mouse clicks and camera manipulation in cases with multiple cutting objects.

Here is a usual example from my workflow. Lets say that my goal is to split a surface via a combination of 50 surface edges, curves and surfaces. If I miss to select some tiny 1 mm cutting object, Rhino warns me with the “Split failed, objects may not intersect or intersections may not split object.” and unfortunately deselects the cutting objects that took me long time to pick one by one, forcing me to spend a lot of time to select them again including the one tiny cutting object I missed to pick initially.

So, I see two good possible solutions here:

  1. Keep the last selection of cutting objects selected after the warning message, even though they failed to split the desired object(a).
  2. Add a Command line option called “Save selected cutting objects”, so that the user could click on in and Rhino will automatically save that as a one-click selection for future split operations.

I think that the 1st solution is easier to implement by the programmers.


My second proposition is to finally add the HIDDEN options to split via curves or surfaces, which could be evoked by typing “crv” or “srf” in the Command line, respectively! I already asked for this enhancement in several topics in the past, but so far these options are still hidden and many Rhino users even don’t know about their existence, resulting into lots of struggles with failed Trim and Split operations, and far less enjoyable experience overall. As we all know, splitting a surface by adjacent surfaces (especially fillets tangent to the surface to be split) sometimes fails and the only solution is to either use the hidden “crv” option or to preliminary duplicate the surface edge and use the output curve. Having visible clickable options “curve” and “surface” in the command line all the time during the Split and Trim commands will make the experience of many Rhino users so much easier.

5 Likes

What are the “hidden options”? What do they do and how are they used?

I’m with you!
Making the crv filter selection a visible option for trim and split would be amazing!

Teaching users this trick is hard.
+1

1 Like

I made a short video for you to show how the hidden options are evoked by typing “crv” or “srf” in the Command line and what’s the benefit of knowing their existence. They both help in situations where the “Split” and “Trim” commands fail for some reason.

+1
adding (or removing) additional cutters would be great. for both command _split and _trim

I would love another enhancement:

chained Isocurves
currently splitting with Isocurves only works for a single surface.
I would love to split across multiple surfaces by selecting a starting Isocurve, and the option should select the isocurves that fits best over an edge…and also swapping U-V …
a very simple example:

the workflow could be like this:
_split
select objects to split (multiple surfaces, polysurfaces)
option Isocurve
option Shrink = yes
option chained Isocurve
→ select starting surface
→ select first Isocurve … auto selection

or for multiple surfaces:
select isocurve on first surface
select isocurve on next surface

:heart: :broken_heart:

kind regards -tom

1 Like

“crv” and “srf” are not options of the Trim and Split commands. Instead they are one shot selection filters which work with any command when an object needs to be selected.

Start a command such as Move, Copy, Rebuild, Trim, Split, etc.

When the command asks for an object type crv or srf and enter. Only curves or surfaces can be selected as the object(s).

1 Like

similarly i would like to select chain of curves in arraycrv command

What do you mean by “chain of curves”? How is that different from a polycurve?

polysurface edges for instance. now you can only select one subobject=edge, but you want your array to follow multiple edges

Chained isocurves
How should this work here ?
AusZ

the behaviour could be similar to
_selChain
continuety can be position or tangent / max angle.
u or v selected by best match (smaller angle)

for this corner:
with option tangent - no chain selected, additional isocurve-selection necessary.
with option position - or with a big tangent-tolerance-angle - closest Point, best fit u or v

and as it is an option - if their is any doubt, it should do nothing - better then something wrong.

1 Like

Just a reminder that “Split” is still not good enough and often fails even in obviously easy cases.

My newest proposal for upgrading the “Split” (and “Trim”) tool is to make it smarter by automatically trying to split the target object via the border of the primary surface, in case that the default splitting algorithm fails.

Take the attached 3d model for example. When you run the “Split” command and try to split the vertical cyan extrusion via the green surface, Rhino fails to make it happen. However, “Split” works properly when the green surface’s bottom edge is being used as a split object. Rhino should do the fix automatically instead of forcing the user to spend more time to do it manually. As I mentioned, this could be an optional secondary fix should the default splitting fails to deliver the expected result.

Smarter Split 2.3dm (191.7 KB)

You may be interested in the history of that particular split/trim operation.

Back in Rhino2 (and probably Rhino1, also) That particular cutting operation works instantly. If you have Rhino2 you will be amazed at how fast and accurately it can trim with a whole string of fillets used as the cutter.
During the development of Rhino4, I pointed out how much better Rhino2 was in this regard. Soon after my complaints this started working in Rhino4. If you have Rhino4, you can see for yourself that it does work.
Then sometime in the development of Rhino5 it stopped working and its been downhill progression ever since.

2 Likes

It’s pity to learn that the trim/split operations became worse with each iteration of Rhino. I don’t have access to Rhino 2 and 4, but I can imagine that they probably use a similar technique as a backup plan to split/trim by surface border.

It may be that teaching sub-object selection would be more helpful for now - that is more universal in Rhino. (There is a general reluctance to load up the command line)

-Pascal

1 Like

In general, trimming with a surface does work whenever the border of the cutter surface is well within tolerance of the surface being trimmed. OTOH trimming with a curve in Rhino will often work even if the curve is not within tolerance of the surface to be trimmed. That makes trimming with edges a risky business. You may get the trim or split operation to work but find out much later that you have serious problems caused by out of tolerance edges.

But. Your example is a unique case. Let me explain. The rules for trimming surfaces with curves are as follows:
A] if the curve is a 3D curve, then the curve will be Pulled to the surface and the result used for trimming
B] if the curve is a 2D curve, then the curve will be Projected to the surface and the result used for trimming

Now your example is case B and if you think about the implications of that, its obvious that following that rule in this case will always produce a result where the result won’t be within tolerance of the surface so the trimming will fail.

The edge in your example is an arc. Well, its really a very close approximation of an arc ( another bug prevents it from being a true arc, but that’s another long story). An arc of course is a 2d curve so even though the edge you are trying to cut with is at least 4 orders of magnitude more accurate than it needs to be to succeed, it fails.

The example I posted clearly shows that both surfaces touch each other, hence the split operation is expected to work flawlessly, but that’s not the case. In case that Rhino needs to project or pull the bottom edge of the green surface over the cyan one, since the former is already perfectly positioned over the latter, the deviation should be zero (assuming that Rhino does its job properly).

Yes I agree 100%. But it would seem that McNeel does not agree.

It does make a difference whether the curve is pulled or projected. If the curve is projected it pretty much misses the surface entirely.
You can run the Project command using the edge of the green surface as the curve to project and cyan surface as the surface to project onto and see what happens.

1 Like

Projecting the bottom edge of the green surface by default uses the Z-axis as a direction, hence it creates a border around the cyan surface instead of the logical location doubling the former. However, using the “View” direction from the Command line fixes the problem.

I received a tip to try the following script. It performs flawlessly on all the examples I tested so far and easily solves various cases that Rhino’s default “Trim” and “Split” tools both fail to figure out properly.

Split surface Pro

1 Like