Request: SplitFace with the Axis option should be consistent with Trim with the Line option.
Trim with the Line option projects the line created on the current viewport’s CPlane in the direction normal to that CPlane onto the object to be trimmed.
Current implementation of SplitFace with the Axis option pulls the axis/line created on the current viewport’s CPlane onto the face to be split. (Corrected)
The desired behavior is for SplitFace with the Axis option to project the axis/line created on the current viewport’s CPlane in the direction normal to that CPlane onto the face to be split.
With the desired behavior in an active ortho viewport with the CPlane normal to the view direction (most common situation) the split will occur at the location of the axis/line as seen in the active viewport.
I believe, after mulling all the back and forth in the neighboring thread, that behaving like Split using a line as input, is more consistent with other related tools - that is to say, Split. The change from current behavior would be that in ortho views the axis would be projected from the current CPlane, which is I think at the nub of the original request, otherwise pulled. Would that work for you?
I think in all scenarios it would be reasonable for the line / axis to be projected onto the CPlane of the view. As @davidcockey noted, this is by far the most normal arrangement for an ortho view to have the CPlane parallel with the view. (This last sentence has been edited for clarity)
Currently, and I think this is a bit confusing, the splitface tool behaves a little differently from the way @davidcockey describes, in that I believe the axis is pulled from the drawn location to the surface along the surfaces normal.
So the change would be that the axis is projected in the direction of the CPlane normal rather than pulled to the surface along the surfaces normal.
Well, no… Split. Split pulls in some cases, SplitFace currently pulls all the time. I am suggesting that the possible change to SplitFace match Split (using a line). It seems a more closely related tool than does Trim, and I think it would be bad to completely break the current behavior.
I have to say, I would much rather they both behaved like trim. Split with Isocurve is still superior to splitface in that it shows you the projection lines so you can see that something undesirable is happening.
I still revert to my point in the other thread that I cannot see any reason why this pulling would be desirable in any circumstance when working in a parallel / ortho view. It just makes both split and splitface unnecessarily finicky and very easy to get the wrong result.
If you want to work perpendicular to a face then set up a CPlane to do it. Forcing this pulling of a perpendicular interaction is counterintuitive and a bad experience that results in modelling errors. The examples given result in very obvious errors because the distances are large. Modelling with smaller geometry that results in a smaller error may not be visible and the user would have no way of knowing until later on finding that something had gone wrong.
I think the way that trim works is exactly what I think most users would need and expect and would much rather both split and splitface to work in the same way as it. Currently there are three different behaviours for three very similar tools. One (trim) is good, the other (split) is OK because at least it shows you the error as it is happening and the other (splitface) is basically broken. Here is a video showing the three behaviours in order. Note the split with isocurve is really annoying in that it tries very hard to do the wrong thing but it can be made to work as desired.
It is really striking when using these three tools in order, how the interface, naming of options (line, isocurve, axis) varies. The snapping / UI within the viewport is different. It seems like these are all three different approaches to doing something very similar. This is exactly contrary to the points made in the original thread about how fixing splitface would make it inconsistent with other tools. In fact, all three tools are completely inconsistent as it is and the debate should be around making the tools work well for users.
Hi David - it pull non-linear curves in non-Plan views - so that would apply in the ‘Curves’ option; using an axis, I guess it would always project - I must say that makes me a little nervous as a change, I will consult with the developer…
@davidcockey and @pascal it should be clear in my video (although the resizing when posting perhaps makes it more difficult to see) but it is very fussy due to snap settings. But you really don’t want to have to change snap settings for each tool.
Pascal: When you say ‘non-linear’ what do you mean? By non-plan views, do you mean perspective views or do you mean anything other than a top view?
It should also be clear in my video above that split tries to pull even when using an orthographic view. The UI makes it much more clear what is happening so you have a hope of seeing that it is going wrong at least. Still I would question how visible this visual cues would be when the geometry was closer together with smaller errors.
These three tools are all behaving differently and using different terminology which is making this discussion strangely difficult.
Please tell me how this behaviour is in any way helpful to anyone? Before recording the video I’d tried using the orthographic views but the split misses the face because it is ~45degrees off the views. In this situation, I’m actually not that bothered where the specific split was taking place, but it was proving to be very tricky to get a split to happen anywhere.
I have to say, Splitface is the most annoying rhino tool there is. MOST of the time, it doesn’t do what is intended.