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

Bt.cover (and bt.cut) render line segment incorrectly when endpoint is close to border #420

Closed
Elijah-Bodden opened this issue Apr 17, 2024 · 2 comments

Comments

@Elijah-Bodden
Copy link
Contributor

Elijah-Bodden commented Apr 17, 2024

When bt.cover or bt.cut is operating on two sets of polylines polylinesA and polylinesB, if any segment of polylinesA has one endpoint inside of polylinesB and one within 0.0001 of an edge of polylinesB (on the inside), the segment will render the opposite of how it should (it will render even though it shouldn't with cover, and won't render even though it should with cut). Example.

Looks like the bug is caused by the following two lines in pointInPolyline

// if on edge
const distanceToSegment = pDistance(point, [xj, yj], [xi, yi]);
if (distanceToSegment < 1e-4) return edge;

I don't know enough about the codebase to know why being on the lines needs to count as outside instead of inside (or thus how to fix the bug without breaking other stuff) but @leomcelroy probably knows. If this is necessary for other functions, removing it seems to at least not break bt.cover and bt.cut and fixes the bug, so we could maybe add an option that's only true when we call from the boolean function and change the lines to something like

// if on edge
const distanceToSegment = pDistance(point, [xj, yj], [xi, yi]);
if (distanceToSegment < 1e-4 && !ops.reffererIsBooleanFunction) return edge;

to disable this code in the context where it causes the bug

@Elijah-Bodden
Copy link
Contributor Author

Okay, patch actually does have bad results - when two edges are perfectly overlapping they both disappear in cover. I've tried some alternative solutions but haven't found any working solutions without this problem

@Elijah-Bodden
Copy link
Contributor Author

UPDATE: I was wrong, the "bad results" I was seeing were actually my test code being flawed in a way that made the bug unbreak it. After fixing the test code, the the bad results with the patch went away. That means the patch (which does resolve the bug) may actually work. Playing around with it, I don't see any bad effects, but there may be edge cases where the tolerance is needed even in cut and cover.

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