Probably why I never use it because it’s far too unpredictable. When I’m modelling I want to interact with things the way I see it. It’s really a basic aspect of user centred design. Things are legible.
I’m at a loss. I cannot fathom how producing an unreliable and unpredictable result is being accepted as just the way it is. I’m here trying to suggest how things could be better. I’ve yet to see one single reason for why the current behaviour is better, let alone even acceptable. Yet my suggestion seems to being met with a dismissive shrug.
What I’m suggesting would be substantially better, and I imagine, not particularly difficult to implement. If the response is “thanks, we’ll add it to the list but can’t promise when it will be sorted” I’d be like, OK, fair enough.
Or even, “thanks, we understand and will discuss it internally” I’d kind of think, alright, we’ll pick up this discussion later.
I think the thing that is getting in the way is that I believe you are thinking of the axis as a screen based axis - the axis is, in your point of view, drawn flat on the screen plane and should be projected through the scene from that plane, correct? and in fact it is a 3d line that is being made - you can use object snaps for instance - and the two simply do not behave the same way. It would not be a trivial change (not technically hard, probably, I imagine it might be easy enough, but I do not know) to make things work in a screen based way and not a 3d way. Rhino has almost no tools that work off of screen based input. So, in short, it would not be an isolated change, even if it seemed like a good idea, it would have to permeate Rhino’s general behavior, if you see what I mean.
Trim with ApparentIntersection=Yes uses the trimming object projected normal to the CPlane. It is the same of if Project with Direction=CPlaneZ was used to project the trimming object onto the object to be trimmed before trimming.
Trim with ApparentIntersection=Yes does not use the view direction of the viewport nor does it Pull the trimming object to the object to be trimmed.
Project has a Direction=View option which projects the object normal to the screen. It does not project the object directly towards the camera (except at the center of the screen). Use Project with Direction=View in a perspective view and not the projected object may not align with the object’s apparent location before projection.
@pascal We appear to be saying the same thing with different words. The trim direction does not depend on the position that the user sees on the screen of the trim curve relative to the object to be trimmed.
Trim using the Line option uses the CPlane z direction to Project, not Pull, the line onto the object. Example with a plane at an arbitrary angle above the CPlane. The perspective viewport was active. If Pull was used the line would not align with the trim in the top view because the plane was not parallel to the CPlane…
Added: Trim with Line and SplitFace with Axis are inconsistent. Trim effectively uses Project and SplitFace effectively uses Pull.
I really think this is getting over complicated. I do not see why the way splitface works has to be inextricably linked to other tools.
The fundamental question that should be being addressed is:
Does the way it currently behave work well? I would say unreservedly the answer is no.
Going back to my original examples, in an orthographic view, you can only ever want the axis like drawn to be the line where you want the split to happen. Any other outcome is not what the user wants.
The outcome described above would be consistent with how Trim with the Line option currently works. I agree it is the more desirable behavior for both.
@pascal Any idea why the inconsistency between SplitFace with Axis option and Trim with Line option? SplitFace “pulls” the line to the surface. Trim “projects” the line in the direction of the viewport Cplane z-axis.
A file with an arbitrarily oriented planar surface and a reference line is attached if anyone wishes to try the commands.PlaneLine.3dm (39.1 KB)
I do not… but if the question is whether it should project from the current CPlane in a parallel view, (as distinct from view direction based), that makes a lot more sense, to me. I asked above whether it should behave like Split does, but that, unless I misread, was not the answer the OP was looking for, I believe he said it ought to be view based.
That is not what Split nor Trim > Line does. Of course it looks like it does, in a plan view, though.
It is painfully obvious to me now that split face does not work like this. The whole point of this discussion is that I strongly believe it should. It’s so bad currently that I assumed it was a bug. There is simply no reason I can see why anyone would ever want the split to be in an arbitrary location. No matter how many times I’m told it is working as expected (and therefore not a bug), I cannot be convinced that it is working well. It is simply a really badly implemented tool.
I’m prepared to be convinced otherwise. Are there any examples where it is really great that the cut doesn’t happen where you’re expecting? If the answer is no, then it seems like an open and shut case that the tool needs rebuilding to work more reliably.
Now we are getting someplace - it is not, in fact view based at all, what you want. As I asked way up there, it is like Split works with a line in plan view, or Trim > Line.
Question remains: in an oblique but parallel view, as Trim > Line works, the split not would happen in the location relative to the view that you draw the line - this is not consistent with what you said above,
When I draw the axis in the view, that’s where I want the split.
except by luck, as it were, in a plan view, so I want to make sure we are still on the same page.
Perhaps there should be a reset of this topic, maybe even a new thread. Rehashing the earlier discussion is not productive.
Let’s make it simple:
Request - SplitFace with Axis option should function the same as Trim with Line option. The axis/line should project onto the face in the direction normal to the CPlane of the active viewport.
