Dragging hexagons is unstable

[jamwaffles]

Please see video:

Screen.sharing.-.2026-04-09.1_08_41.PM.mp4

I drew a hexagon which is completely constrained aside from its vertical position. Dragging any of the vertices causes the hexagon to snap into a different shape. I'd expect dragging an otherwise constrained shape to not change the shape. This hexagon is sourced from this KCL:

sketch001 = sketch(on = XY) {
  line1 = line(start = [var 0mm, var 7.16mm], end = [var 7.25mm, var 2.97mm])
  horizontalDistance([line1.start, ORIGIN]) == 0mm
  line2 = line(start = [var 7.25mm, var 2.97mm], end = [var 7.25mm, var -5.4mm])
  coincident([line1.end, line2.start])
  line3 = line(start = [var 7.25mm, var -5.4mm], end = [var 0mm, var -9.59mm])
  coincident([line2.end, line3.start])
  horizontalDistance([line3.end, ORIGIN]) == 0mm
  line4 = line(start = [var 0mm, var -9.59mm], end = [var -7.25mm, var -5.4mm])
  coincident([line4.start, line3.end])
  line5 = line(start = [var -7.25mm, var -5.4mm], end = [var -7.25mm, var 2.97mm])
  coincident([line4.end, line5.start])
  line6 = line(start = [var -7.25mm, var 2.97mm], end = [var 0mm, var 7.16mm])
  coincident([line5.end, line6.start])
  coincident([line6.end, line1.start])
  equalLength([
    line1,
    line2,
    line3,
    line4,
    line5,
    line6
  ])
  vertical(line2)
  vertical(line5)
  angle([line2, line1]) == 60
  verticalDistance([line3.start, line5.start]) == 0mm
  distance([line6.start, line2.start]) == 14.5
}

[adamchalmers]

I suspect this is also coming from our angle constraint impl. The 2 lines meet at two different angles, and this is flipping from 60 to (180-60) i.e. the other angle.

[davreev]

Yep, this is (sort of) expected given how our angle constraint works currently. Details in this thread.

The reason I say "sort of" is because the drag interaction doesn't look large enough to be pulling to the configuration to a different solution. Seems like it might also be an issue with how drag is interacting with the solver.

Also related to KittyCAD/modeling-app#10964

[varun29ankuS]

I think the flip comes from the LinesAtAngle residual — u × (R⁻¹v) is zero at both θ and θ+180°, so a drag can slip to the antiparallel branch. Maybe a single-valued residual like atan2(cross, dot) − θ would fix it?

Happy to try a PR if that's useful.

[davreev]

@varun29ankuS yes that's right, the new PointsAtAngle constraint (added in #252) addresses this issue though the residual used there differs a bit from the one you've proposed (for conditioning/stability reasons).

[varun29ankuS]

@davreev May I ask what residual PointsAtAngle ended up using?

[davreev]

PointsAtAngle uses the following residual (see source for details)

$$ \frac{(\lVert u \rVert + \lVert v \rVert)}{2}( \hat v - R \hat u) $$

where

• $u$ is the vector from the angle vertex to the end of the first "arm"
• $v$ is the vector from the angle vertex to the end of the second "arm"
• $R$ is a rotation of a specified angle

The issue with using an angle residual like you mentioned is that it doesn't scale with the variables (ideally we'd want it to scale linearly) so the influence of the constraint depends on the size of the sketch being drawn. Also the gradient of the angle residual explodes near the central vertex which can cause stability problems.

[varun29ankuS]

That's elegant — the (|u|+|v|)/2 prefactor is doing double duty. Past the linear scaling, it cancels the 1/|v| from normalizing v̂ (∂v̂/∂v = (I − v̂v̂ᵀ)/|v|), so the Jacobian stays bounded as an arm collapses toward the vertex — the exact spot an angle residual blows up. And going to the 2-vector v̂ − Rû instead of a scalar kills the θ/θ+180° branch by construction. Makes sense, thanks for the detail.