Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Constraints #16

Open
nrc opened this issue Oct 24, 2024 · 5 comments
Open

Constraints #16

nrc opened this issue Oct 24, 2024 · 5 comments

Comments

@nrc
Copy link

nrc commented Oct 24, 2024

Constraints seem like a big rough edge in KCL at the moment. This is a tracking issue to collect related issues, document problems, and discuss solutions.

Currently constraints are initiated and manipulated by the UI. They are not explicit in KCL: they are represented by different functions, e.g., xLineTo is a more constrained version of lineTo, and by factored-out variables. These patterns are then recognised by the UI for further manipulation of the constraints.

This is unsatisfactory because it is fragile - the user could change a constraint in code such that the UI can no longer treat it like a constraint. It is sub-optimal for users because of the implictness of the constraint. It also doesn't scale well: we end up with a lot of closely related but different std lib functions.

We would also like a bunch more constraints than we currently support.

@nrc
Copy link
Author

nrc commented Oct 24, 2024

@jtran has proposed a change to the language making constraints first-class: #13

Some related issues: KittyCAD/modeling-app#1626, KittyCAD/modeling-app#1498, KittyCAD/modeling-app#111

@nrc
Copy link
Author

nrc commented Oct 24, 2024

I have a rough idea which might help (would need other improvements too): rather than have multiple different line functions with different levels of constrainedness, we have a single line function who's argument defines how the line is drawn, including constraints. So line(pt(0, 0, 0)) would replace lineTo, line(vec(0, 1, 0)) would replace line, and for more advanced cases, something like line(parallel(X) & length(4)) (& here is a strawman syntax) would replace xLine(4), or line(angle(90) & length(4)) would replace angledLine, etc. Similarly for arc and other drawing functions which might be constrained. This puts the constraint in one place and makes it more explicit. It also makes the std lib smaller and better organised. However, it doesn't extend to constraints across multiple items, e.g., we might want to constrain two lines to be parallel, but not give one a specific angle and the other follow the first.

@nrc
Copy link
Author

nrc commented Oct 29, 2024

The currently supported constraints are:

  • AngleLength: set the angle or length of a line using angleLine
  • AngleBetween: set the angle relative to another line using angleLine, used for making lines parallel
  • Intersect: I think this is "perpendicular distance"? Not sure what it does, uses angledLineThatIntersects
  • AbsDistance: ??
  • HorzVertDistance: sets the endpoints of a segment to align horizontally or vertically with the endpoints of another segment, uses lineTo
  • EqualLength: make two lines the same length, using angleLine
  • HorzVert: make a line horizontal or vertical using xLine or yLine
  • EqualAngle: ??

Note that another key way for defining constraints is to use values which are defined using a value of another object, e.g., using segAng(seg02) where seg2 is the tag of a segment.

@nrc
Copy link
Author

nrc commented Oct 31, 2024

Some notes and start of a design: https://gist.github.com/nrc/efdec535bd961a0f7b470480676fa9eb

@nrc
Copy link
Author

nrc commented Nov 6, 2024

See also this list of sketch features, including constraints: https://github.com/KittyCAD/notes/blob/main/docs/personal/Boone-Nick/Advanced-Sketch-Features.md

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant