KittyCAD / modeling-app

The KittyCAD modeling app.
https://kittycad.io/modeling-app/download
MIT License
412 stars 35 forks source link

Stdlib: functions for various quadrilaterals #4375

Open adamchalmers opened 4 days ago

adamchalmers commented 4 days ago

Right now ZMA has a very limited constraint solver. This makes it hard to express relationships between points. For example, it's difficult to express a parallelogram. Here's my best attempt in KCL:

// Creates a parallelogram with the given side lengths.
fn pgram = (side1, side2) => {
  d1 = side1/2
  d2 = side2/2
  l = sqrt(d1 ^ 2 + d2 ^ 2)
  theta = toDegrees(atan(d2 / d1))
  angle1 = 2 * theta
  angle2 = 2 * (90 - angle1)
  return startSketchAt([0, 0])
  |> angledLine({ angle: angle1, length: l }, %)
  |> angledLine({ angle: angle2, length: l }, %)
  |> angledLine({ angle: 180 + angle1, length: l }, %)
  |> angledLine({ angle: 180 + angle2, length: l }, %)
  |> close(%)
}

I had to break out some pen and paper to do geometry in order to figure out the correct relationships and get this code correct. It took some debugging, I got it wrong at first. We shouldn't make KCL users do this themselves.

One option is to offer a powerful constraint solver, so they can say "this parallelogram has diagonal distances of 6 and 15" using the Dimension tool. That tool lets users constrain points to be a certain distance away. That'll be a significant change from ZMA.

Another option is to offer a range of different stdlib functions to define a parallelogram, for example parallelogram.withSides(number, number) or parallelogram.withAngles(number, number) to define them based on the minor/acute and major/obtuse angles.

We can definitely do the former option, but we should also offer the latter option. The latter will be quicker to implement and will help users get through more and more tasks without needing a constraint solver. Of course, we can't possibly offer a function for every shape users will ever imagine. But we can offer a range of functions for common problems, to let users get further and further in their work before they need a constraint solver.

Suggestions:

These should be namespaced, both for readability and organization.

jtran commented 23 hours ago

I'm definitely in favor of the general idea of using namespaces.

Using the dot syntax is the most straight-forward and likely the easiest to learn for users. But it would mean that it's not easy to determine whether something is accessing a member of an object (must be runtime) or navigating the namespace (could be done statically).