SplitFace bug

I’m trying to use SplitFace and it keeps splitting the face in the wrong place.

There is a horizontal surface which intersects with the face I’m trying to split. Primarily this is here to help illustrate the issue.

maybe working too far from the origin?

I doubt it. The whole model is within the limits of the grid and before I start modelling I bring everything to be centred on the origin.

1 Like

I can repeat the issue in angled faces while picking a start point different from the surface edges. didn’t paid attention to that before
it seems the surfaces needs to be normal to the view. If I change the Cplane to the surface it works as it should.

1 Like

Thanks, this seems like a bug. There’s no way anyone could want the current behaviour.

1 Like

Please post a small sample file and detailed instructions we can follow to reproduce the problem.
Without that we have no chance of finding and fixing whatever is going wrong.

Thanks

Hi John

Hopefully this works (doesn’t work?!) for you.

Robin

Splitface bug.3dm (2.7 MB)

Hi Robin,

I think this is working as designed. Try it in Perspective as shown below. I used a Near Osnap and then the OnSrf Osnap one shot to get an Intersection on Ortho with the adjacent edge. That last part is done by holding Shift for the second click needed for the split line.

When you are in the Ortho view and getting end Osnaps far away from the plane to split I think it just misses it since they aren’t in the same spot.

An alternate workflow would be to use Split instead and then Join the two pieces back together.

It looks like the split axis is pulled to the target face.

-Pascal

Hi, I can’t see how it could be as intended when the split results in not ending up where it is drawn when defining the split. There is no aspect of that workflow that could ever be desirable.

I can’t remember how I originally came across the problem now, but it really shouldn’t go wrong if you happen to have a surface there.

I think as @pascal has suggested, that the split axis is being pulled to the surface according to the surface normal rather than perpendicular to the view. If this is the case, it would mean that often split face introduces an inaccuracy into modelling. Normally this would probably be a tiny error but in this case it was highly noticeable. With geometry that’s closer together the error might not be easily visible but it would be there.

Hi Robin - to be honest it has never occurred to me to use other than an axis on the face to split with… A projected axis, which is what I think you are suggesting, would simply lead to a different version of the same ‘inaccuracy’ problem.

-Pascal

Why would it create such an inaccuracy? Conceptually, the axis would be creating a virtual plane that’s perpendicular to the view? That’s how I’ve always assumed the tool worked. Seemingly wrongly.

But if a plane were constructed as I described and as shown on the example file, surely the split of the face should be as accurate as splitting a surface with another surface?

As it stands, it’s just totally wrong. There is really no good reason why you’d ever want a split face to occur anywhere other than where you drew the axis for the split.

But that is exactly what happens any time you draw the axis off the face - it has to go in some direction to get to the face - depending on the view and Cplane, Projecting can give a variety of answers, Pulling only gets you one answer, which seems like a better way, to me…

-Pascal

I’m really confused here. I cannot comprehend why pulling it to the surface would be better than making the split where you choose for it to be in the viewport?

Isn’t the idea with modelling via a GUI that what you do on screen is what happens to the geometry? In the example I’ve provided, why would you ever want the resulting outcome rather than the one where the cut is where you put it in?

I guess, I’m just really flummoxed. I just can’t envisage any scenario where having it pulled to the surface is preferable to projecting it from the view.

So have we reached a conclusion to this discussion here that McNeel policy is that in some circumstances, splitface happens not where you choose it to happen? And not only that, but this is an acceptable and intended result?

Hello - If the axis is not on the face, the axis must be moved to the face in some way… If you Project the axis, would you project it from the view direction, the current view direction, or as in Split, differently depending on the active CPlane. If you want it to behave exactly like a line used in Split, then at least I have something to go on - it might be OK, but as mentioned, the answer can be different in different circumstances while with Pull there is only one answer, which in this context seems like a better thing, to me.

three different CPlanes, three different results:

-Pascal

I think this is being hugely over complicated. I just want it to split where I draw the line on a viewport. I guess this would be described as projecting from the view?

I really don’t see why CPlanes should have any bearing on this. It’s just a question of the relationship of view to the geometry of the face.

When I draw the axis in the view, that’s where I want the split. Any other outcome seems highly undesirable to me. Is there a scenario where anyone would want anything other than that?

There are currently no surface editing commands that project geometry in the view direction (that I can think of) Trim does this, optionally, and not by default, when curves trim curves; this would be completely new behavior. Hence the push-back.

-Pascal

Are there other surface editing tools where you literally draw a line on the viewport to define where you want something to happen?

All other tools I can think of are interactions between geometry. This is modifying geometry based on a line drawn on the viewport.

Perhaps adding a direction option like with extrude tools would make it explicit what’s going on. The HUGE problem at the moment is there is no way the user knows what is happening. And worst of all, what’s happening is not what you would expect based on the user input.

There is, actually. Trim with the Line option - it behaves as though you drew a line object on the CPlane and used it to trim - it does not use the view direction.

-Pascal