view-independent cut

Hi!
I noticed that the click&drag cut is view dependent. It works similar to the quick slice, where the slice plane is given by the camera vectors. It's very nice to be able to cut through multiple components at once, because you can accomplish a "straight line" for the cut. But for cuts through non-planar geometry this straight line is only formed from a specific point of view, that is, the view it was generated from.
I have a proposal for a view indepentent cut. I know I have seen this work before in another program, I just don't know how they did it. So this needs some experimentation! And since I am no math genius I could be totally wrong.
You can imagine it, like if you're using the slice tool, you just have to determine how to set up the plane. What I can imagine how this could work is, that you draw a line (vector) from your starting position to your end position of your cut, so you have the first axis of your plane. Instead of facing the second axis to the point of view, it should be set in a way that you get the smallest possible area enclosed by your first vector and the nearby polygons.
Now the question is, how does one get to this smallest possible area and get a second vector for your plane from it? This is my guess: from any edge you can draw (an infinite number of) vectors that are perpendicular to your start-to-end-line. It's the shortest one. So the cut on an edge should be made where the perpendicular distance between your path and edge is shortest. To be honest, if you do that for each edge that should be cut, I don't know if you end up with a straight line (ergo plane) from any point of view.
With the current view dependent cut, NVIL already knows which edges to cut and when not to cut, so I assume this should not be the problem. It probably has to be ensured, that the cut isn't facing away from the camera (at most 90°). But that's what vector calculus is for (cross-product, I believe).

I have mashed up a picture to illustrate what I mean.

Another solution I can think of is to take the average normal of all to-be-cut edges as the second orientation of the plane. I guess this would be simpler, but I don't know how the outcome would be. As I said, this may require some experimentation.

PS: Of course, to build an infinte plane you only need 1 vector (the normal vector), but I didn't want to wrap my head around how to get this directly.

...that you draw a line (vector) from your starting position to your end position of your cut, so you have the first axis of your plane...

The problem is this may not be true. When you draw out a slice line, there may be no way to determine its depth. That means you don't know where it is, so it can't be used as an axis. But, if the start point and end point both intercept into a mesh, the two intercept points can be used to determine the line position.

The area computation is very challenging.

It seems the outcome could be unpredictable.

Oh, I'm sorry, I didn't mean the slice line. Then of course you're right about the depth. I was assuming a cut that starts and ends at a vertexx or edge. Because of the challenge of computing an axis that would give the smallest possible planar area, I thought maybe it could be done by computing a cut one at a time, by finding the shortest distances from each relevant edge that are perpendicular to the start-to-end-line. The disadvantage could be, that you don't get a planar area, thus defeating the purpose.

At the end, what I wanted was a reliable cut, that will give you the same result on identical topology. By relying on the view at the moment, that isn't possible. And with the slice plane, this would also be too complicated (for example when you want to start and end on vertices). Therefore, it might work to take the average normal of the components to determine the orientation of the cut, as the average normal would also be the same on identical topology.

The new view tool may help.
Viewport context menu > Align Along Subobject normal.

It's a start. But it only works if the selection is somewhat aligned with the world axis. If I have an arbitrarily rotated Object or selection, the alignment produces different and mostly unusable results for this task. See the picture for an example. And not being able to rotate or move the view while cutting is a downside, if you wanted to cut around corners or a more comlicated mesh.

The resulting view from that tool also changes, if I use 'freeze object orientation' beforehand on the rotated object. But the normals of the selection didn't change. So I suppose there's something off.

Fixed.

As far as I can tell from my short experimentation, with this workaround I now can get reliable, identical cuts across multiple edges at once on identical topology. I believe few apps can do this. Thanks!

Maybe someday in the future, there will be a more direct approach, allowing for camera rotation while cutting.