-
Notifications
You must be signed in to change notification settings - Fork 630
Ignore all flat triangles in triangulation #2248
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
Conversation
|
Should the assertion |
|
Sorry for leaving this here so long; I agree that this is a strict improvement over main, I would say let's merge it but leave the issue open for later fixing.
Yep, let's do that! @andy-sweet do you have time to bring up to date and make this little change? Otherwise I can take care of it! |
Oh wow, this is a bit of a blast from the past. Let me try to bring this up to date with |
|
Also, I'm not sure if this problem is still an issue in napari (I remember some more recent activity around fixing triangulation there), but that doesn't mean we shouldn't fix things here. |
|
Thanks! Yeah I also don't know how it overlaps to the work in napari, but indeed this seems like a good thing to get in in vispy anyways :) |
|
Caught up with
If we put the assertion after the check for duplicate points, then I think we should just remove it because it will never be true (because if any of the vertex indices are repeated, the duplicate by value check will return). I assume the assertion was added because this algorithm assumes that That being said, the current implementation has some issues and feels a little unfinished, so maybe it's worth just removing the assertion and hoping for the best? In the unlikely event it causes downstream issues, we could just make a quick follow-up release with a revert commit. @brisvag : sorry to push this specific decision to you, but I'm about to be very unavailable, so I'm going to do so... |
|
We can leave it as is, though it's kinda pointless to have an assert and immediately after or before have (a better version of) the same check but with an if statement. Either way, I'd say let's merge this as soon as tests are good :) Thanks a lot for reviving it @andy-sweet! |
|
We do have a genuine test fail though 🤔 |
That test also fails locally for me. Fortunately, past me is smarter than current me (see PR description).
Though I need to remind myself how a vertex can be returned that is not in the input. We could mark that test as expected fail, though it would be good to provide an explanatory comment. Or just remove it. |
|
mhm... I'll try to look into it later to see if I can figure it out :) |
The initialization does add artificial points, so this is not unexpected. And the failing test case is the main one described in #2247 , so I think the best course of action is to mark the test with |
|
Great, will merge soon unless @djhoese has some reason to block :) |
|
I never understood it in the first place so go ahead and merge. |
This partially fixes #2247. By ignoring flat/zero-area triangles (i.e. where all three points are collinear), we avoid the assertion failure associated with overwriting the entry in
_edges_lookup. But there is still an unexpected triangle and vertex in the output.I added a few simple and similar tests to capture what I expect from the output, and where the behavior breaks down. Before the change both
test_triangulate_collinear_pathandtest_triangulate_collinear_path_with_repeatfail with the assertion failure. After the change, onlytest_triangulate_collinear_path_with_repeatfails, not due to the assertion, but because a triangle is found, which also contains a vertex that is not in the input - instead I would expect no triangles to be returned.I think this PR represents a small improvement from
mainfor two reasons.# ignore flat tris, which suggested that the_add_triwas trying to skip zero-area triangles. But the implementation only ignored triangles with at least 2 points that have duplicate coordinates. This PR adds a proper check for that condition.However, I have some reservations about this PR in its current state.
Note that some of the test cases represent degenerate cases, so I think an alternative fix here is to raise an exception with a suitable message and document that behavior. Personally, I would expect a triangulation algorithm to expect some degenerate cases and handle them fairly gracefully (perhaps with a warning), but this is my first time thinking about triangulation, so I'm very much a beginner here.
Any thoughts/comments/ideas welcome!