3D circle center through 3 points

[SimonAndreys]

Re-wrote the function calculate-circle-center-3pt in src/utils.typ
Previously, this function took three 3D vectors as input but was essentially 2D, taking the z-coordinate from the first vector. Now the output is the center of the circle passing through the 3 point even if they have not the same z-coordinates.
Note : if two of the points are equal, there is no uniqueness of the circle center. Originally it returned the center passing through the 2 different points with x-coordinate 0, which seems arbitrary. Now it returns the midpoint between the two different points.
The function fails if the 3 points are aligned and different.
This is a first step towards making arc-through and circle-through work with 3D points with different z-coordinates.
All test passed.

[johannes-wolf]

Thank you! Some small things to fix. I have not yet tested it.

[johannes-wolf]

Typo: ligne-pt → line-pt – maybe we should change that to vector.lerp.

[johannes-wolf]

Since Typst evaluates all arguments of assert, this should be a panic inside an if.

[johannes-wolf]

Indentation is off.

[SimonAndreys]

I use typstyle to format the code, linebreaks and indentation are automatic... I put this string back to one line.

[johannes-wolf]

You can use range(0, 2) instead of (0, 1, 2) – same for line 114 and 145.

[johannes-wolf]

Ok, I've tested the changes. There is a problem with circle-through: We have to transform the circle. This is tricky because of the anchors; I've played around with it and the problem is, if the normal of the plane the circle is on points backwards (negative z), the anchor rotation flips – which is expected but a breaking change.

The current implementation does not take the point order into account, but if we want to support 3D circles, we cannot have a „default“ behavior that always works.

One option would be switching to the current behavior if the normal is $\lambda \cdot e_3, \lambda \in\mathbb{R}$.

[SimonAndreys]

I understand, for any circle there are two choices of "normal direction" (defining "up" and so defining what is a counterclockwise rotation). When you flip the circle you end up with angles with opposite order (anti-trigonometric), and maybe 0deg exchanged with 180deg.
I feel like having a switch in behavior for horizontal circles would be confusing. I think the switch in behavior should be controlled by the user.
Here is how I see it : we have some "oriented 3D circle" object, which consists in a circle, a choice of a normal direction, and a "0deg" reference point on the circle, thus allowing well defined anchors. Then circle-through(a, b, c) can have two behaviors :

1. by default, it returns the oriented circle where we chose the normal direction to be the one with positive z-coordinate and the reference point to be the one with highest x-coordinate (and some convention for when the circle is in a "vertical" plane). Some discontinuity happens when the circle gets vertical but at least we have the usual behavior for horizontal circles.
2. The "advanced" behavior which depends on the order of the points : it would return an oriented circle with normal vector (b-a)cross(c-a) and with reference point a. This way we do not have discontinuity, but we don't have the default behavior even when the circle is horizontal.

[johannes-wolf]

Sounds good!