default origin and orientation for sketchOnFaces

[Irev-Dev]

When a user wants to sketch on face, we essentially need to create a new mini coordinate system for them, but the "rules" in how we create that default coordinate system have a lot of second-order effects that we need to think through, What I mean by this is mostly that bad default can make the model brittle to having more features built on top of it (since can CAD modeling can be thought of a dependency tree of features built on top of each other).

To make this concrete here's an example of a stability issue we have today. Take the following code.

const angle001 = 45 + 0.01
const part001 = startSketchOn('-XZ')
  |> startProfileAt([4.68, 3.15], %)
  |> angledLine([angle001, 11.36], %, 'seg01')
  |> line([9.47, -8.73], %)
  |> close(%)
  |> extrude(5 + 7, %)
const part002 = startSketchOn(part001, 'seg01')
  |> startProfileAt([-2.61, 2.95], %)
  |> line([5.32, 0.48], %)
  |> yLine(-6.34, %, 'seg02')
  |> close(%)
  |> extrude(5 + 7, %)
const part003 = startSketchOn(part002, 'seg02')
  |> startProfileAt([-0.73, -2.51], %)
  |> line([-0.01, 2.43], %)
  |> line([-1.3, 0.1], %)
  |> line([1.99, 2.39], %)
  |> line([2.37, -2.46], %)
  |> line([-1.85, -0.05], %)
  |> line([0.1, -2.4], %)
  |> close(%)
  |> extrude(1, %)

The angle001 is used to define the angle of one of the extrude faces, this face has a sketch-then-extrude on it. followed by another extrude again of one of the faces of the second extrude. This last extrude is just an arrow for demo purposes, This is what it looks like.

Notice the arrow points up and to the right ↗️

Now we're going to change the first line from const angle001 = 45 + 0.01 to const angle001 = 45 + 0.0, and now this is what the model looks like:

That is a tiny change (0.01) in the model that caused the orientation to the arrow to complete change orientation, obviously, the example was setup so it was right on the threshold with 45°, but the point the sketch on a face changing orientation as variables in the extrudes parent update will bake KittCAD models very brittle.

With that said let's not get too hung up on this example, I think it has an obvious fix of aligning the sketch y-axis always with the extrude direction, but this likely only covers the case where the face is a extrude wall and not the extrude caps etc.

Josh and I spent some time going back on forth on this, and while I wouldn't say we have definitive answers, we did at least make some solid progress, and that's what I'm going to try and express here, but to express it on one line it's:

Local orientation, global origin position, Camera animations not tied to either

Local orientation

Extrude walls

When sketching on extrude walls the y-axis of the sketch should always be aligned with the positive extrude direction.
Good example (extrude direction aligned with extrusion direction)

Bad example (extrude direction not aligned with extrusion direction)

Extrude caps

Should take the orientation from their parent.

Example: Sketch on default plane -> sketch on cap
The sketch on cap will just inherit the orientation of the sketch before it that was on the default plane.
In the image below we're trying to sketch on the face with the orange outline, and it gets it's orientation from the original default plane

If there's a bunch of these stacked on top of each other because they are all taking the orientation from the parent they will all be the same

Example: Sketch on extrude wall -> sketch on cap
In this case the yAxis of the sketch on the extrude wall should be taken from the extrude direction, and then the next sketch on the second extrude cap will inherit this yAxis orientation

Global origin position

So far we've only been concerned with how we should align the axis on the new sketch plane, but not where the origin should be.
And Josh and I are pretty sure the least bad option is to have global origin.

This is much easier to show than type out.

Screenshare.-.2024-03-19.6_58_33.PM.mp4

Screenshare.-.2024-03-19.7_00_31.PM.mp4

Camera animations not tied to either

Screenshare.-.2024-03-19.7_12_36.PM.mp4

appendix: Do changes need to be made in the Engine or KCL?

I think it's probably easier to do in the engine, but because this is just some 3d transforms and other math, we could implement this all in KCL, however, we would probably need a few more query endpoints in the engine so that KCL had enough information to do the math.

[Irev-Dev]

This has been open as an issue in our engine repo (private) for implementation.