-
Notifications
You must be signed in to change notification settings - Fork 35
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
Sketches storing wrong path segment types #4297
Comments
adamchalmers
added a commit
that referenced
this issue
Oct 25, 2024
See "Problem 2" in #4297 This is a pure refactor, it should not change any behaviour at all. It adds more information into the tag system, but nothing reads that extra information yet. It will be used to address problem 3 of the above issue.
adamchalmers
added a commit
that referenced
this issue
Oct 25, 2024
See "Problem 2" in #4297 This is a pure refactor, it should not change any behaviour at all. It adds more information into the tag system, but nothing reads that extra information yet. It will be used to address problem 3 of the above issue.
adamchalmers
added a commit
that referenced
this issue
Oct 25, 2024
See "Problem 2" in #4297 This is a pure refactor, it should not change any behaviour at all. It adds more information into the tag system, but nothing reads that extra information yet. It will be used to address problem 3 of the above issue.
adamchalmers
added a commit
that referenced
this issue
Oct 25, 2024
See "Problem 2" in #4297 This is a pure refactor, it should not change any behaviour at all. It adds more information into the tag system, but nothing reads that extra information yet. It will be used to address problem 3 of the above issue.
adamchalmers
added a commit
that referenced
this issue
Oct 25, 2024
See "Problem 2" in #4297 This is a pure refactor, it should not change any behaviour at all. It adds more information into the tag system, but nothing reads that extra information yet. It will be used to address problem 3 of the above issue.
adamchalmers
added a commit
that referenced
this issue
Oct 25, 2024
adamchalmers
added a commit
that referenced
this issue
Oct 25, 2024
adamchalmers
added a commit
that referenced
this issue
Oct 25, 2024
adamchalmers
added a commit
that referenced
this issue
Oct 25, 2024
adamchalmers
added a commit
that referenced
this issue
Oct 25, 2024
adamchalmers
added a commit
that referenced
this issue
Oct 25, 2024
adamchalmers
added a commit
that referenced
this issue
Oct 25, 2024
adamchalmers
added a commit
that referenced
this issue
Oct 28, 2024
BasePath is a pair of points and geometry metadata. Previously BasePath was used for: - The start of a sketch - The data which all path types have in common It wasn't a good fit for the start of a sketch, because there was a lot of duplicated information, and a sketch starts at a point, not a line (two points). This adds a separate SketchStart struct which replaces the first use of BasePath. This means BasePath no longer needs to be a variant of Path, simplifying it. Solves problem 4 of #4297
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Background
Sketches are composed of a "base path", then a sequence of 0 or more subsequent paths.
Paths have various types (e.g. arc, straight line, tangential arc).
Problem 1
Sketches do not properly store the type of path. Arcs are registered as Path::ToPoint, not Path::Arc. See this program:
creates a Sketch like:
Clearly the lineTo and arc should generate different kinds of path, but they're both ToPoint, which appears to be the "straight line" path type. There's no variant for
Arc
and there needs to be.On the other hand, there's three different types for straight lines (ToPoint, AngledLineTo, Horizontal) where there probably only needs to be one. Kurt might know why these are different but my impression is this was all copied directly from the original JS-only untitled-app prototype.
Problem 2
When users tag a path, the tag stores a reference to "base path", i.e. just a (start, end) pair of 2D points. This should really be storing the type of path too, e.g. is it an arc, straight line, tangential arc, etc. Why? Because...
Problem 3
Functions like
segLen()
aka "segment length" cannot accurately calculate the length of a segment, because they take a tag, and as discussed in Problem 2, tagged paths just store a start/end, not a path type (arc, straight line, etc). Instead segLen assumes the path is a straight line, even if it's an arc. Clearly this is wrong and we have to solve problem 2 to solve this.Problem 4
Why is "base path" even a type? It's used two ways:
start
, whoseto
andfrom
fields are both just the start of the profilebase
field that stores where the start/end isThe first case can be eliminated, sketches can just store a
start: Point2d
field instead ofstart: BasePath
.The second case is weird. We're moving towards a model where paths don't always store their endpoint, because some of them will require (sigh) an API call or jumping out of WASM into JS then back into a different WASM (C++) then back to JS then back to KCL interpreter. So we're going to try to refactor paths so they don't always know their endpoints. And of course, the start of path
n
is just the end of pathn-1
so it won't always make sense for paths to store their end either.So we probably need to remove the base path type.
The text was updated successfully, but these errors were encountered: