Skip to content

Fix broken trace behavior for non-closed paths - #511

Open
jeffc wants to merge 3 commits into
GridSpace:rel-nextfrom
jeffc:trace-fix
Open

Fix broken trace behavior for non-closed paths#511
jeffc wants to merge 3 commits into
GridSpace:rel-nextfrom
jeffc:trace-fix

Conversation

@jeffc

@jeffc jeffc commented Aug 29, 2026

Copy link
Copy Markdown

Fixes two bugs in trace operations for open paths:

  1. Allows length-2 open paths (ie, a single segment), which were previously filtered out
  2. Checks the direction ("winding order" equivalent) of open paths and corrects them if necessary. Open paths are generated by linking segments selected by the user, which could lead to arbitrary flipping of segment direction. By ensuring that the "right-handed" normal points out of the part, we ensure that "outside" offsets do indeed go out (and "inside" offsets go in).

I've attached an example workspace that traces a single segment on a part. In the current version of kiri:moto, no toolpaths are generated. If you apply the first commit in this PR, the toolpath gets generated inside the part even though "outside" is selected. When you apply both commits, it works as expected.

note: I discovered #510 while writing this, which is why .right got switched to .left in polygons.js. I figured I'd stick with the current convention rather than try to fix the whole thing as part of this PR.

workspace_key_offset_example.zip

jeffc added 3 commits August 28, 2026 20:24
…ations) and correct them if necessary

This ensure that "inside" and "outside" work as expected for open paths
polylines not on the convex hull of the part
@jeffc

jeffc commented Sep 5, 2026

Copy link
Copy Markdown
Author

After playing with this some more, I found another edge case (pun intended):

image

Since this line isn't on the convex hull of the part (or, to think about it in 2D, this line isn't an exterior edge of the shadow at its z-height), both the "left" and "right" test points test inside the part. I modified the probe to first test whether they're inside/outside the shadow at a small epsilon above the given Z. It also now explicitly tests both the left and right normals. If they're both inside or both outside, it falls back to a test at exactly the given Z (which is necessary in the case of lines at the perimeter of a local maximum, where nothing exists in the shadow at epsilon above)

@jeffc

jeffc commented Sep 5, 2026

Copy link
Copy Markdown
Author

I've been noodling with the idea of whether it makes sense to just add a "flip normals" checkbox if "inside" or "outside" is selected for a trace. If a user ever encounters a case where the direction is still detected incorrectly, this would give them a solution.

@stewartoallen

Copy link
Copy Markdown
Contributor

thanks for all the digging with these PRs. I'm in the middle of a big move that's taking place over several weeks. DM me on Discord or send me an email so we can better coordinate. I'm not ignoring these. just lacking bandwidth at the moment.

@jeffc

jeffc commented Sep 5, 2026

Copy link
Copy Markdown
Author

No worries! I sent you a discord message (I've found discord can be weird about not showing notifications for message requests from non-friends, so following up here just to close the loop)

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

Successfully merging this pull request may close these issues.

2 participants