-
Notifications
You must be signed in to change notification settings - Fork 90
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
Polygon subtraction creates degenerate result polygon #40
Comments
I haven't tried running your code, but just looking at the points, this jumps out to me:
Notice that the Y coordinates are nearly the same, but not exactly the same. This can cause issues with the floating point precision. There is a PR here that aims to improve the epsilon logic. You could try applying that patch. Alternatively, you could round your points before sending them to polybooljs so that they are guaranteed to be the same Y coordinate. For example:
I'm curious if that works for you. |
Hey, sorry it took so long to get back to you. I somehow missed the GitHub notification about your response, and then since then things have been pretty hectic in my personal life. Even so, I appreciate your super-quick response. Regarding your suggestions:
So rounding the points does work. I am a little surprised that it should be necessary, though - after all, this is why we have epsilon logic in the first place, isn't it? The difference between those y-coordinates is ~5e-15, which seems small enough that it should get swallowed. |
i'm facing the same problem today. Showed by the demo screenshot below resulting a single polygon. It occurs sometimes when there are 2 point are sitting on edge or point of either polygons. but it is not always the case. i move a point a bit and it give correct result, 2 polygons I suspect the bug happens when the chainer choose a segment with overlapping points as a starting segment |
With the below polygons, subtracting S from T creates a degenerate result polygon: Instead of splitting the result into two polygons at vertex 3, it creates a single polygon with vertex 3 sitting on the edge connecting vertex 0 and 1.
I'm not sure if this is intended behavior? With other vertex-on-edge scenarios, result polygons always get split up correctly, so I think this is probably a bug.
Here is a graphical representation of T and S:
The text was updated successfully, but these errors were encountered: