Thanks to visit codestin.com
Credit goes to Github.com

Skip to content

Conversation

@andy-sweet
Copy link
Contributor

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_path and test_triangulate_collinear_path_with_repeat fail with the assertion failure. After the change, only test_triangulate_collinear_path_with_repeat fails, 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 main for two reasons.

  1. The original assertion failure makes me think that the triangulation algorithm assumed that it would never see duplicate edges based on the way it was implemented (i.e. the state is not just exceptional, it should be impossible). This PR prevents one way of reaching that state.
  2. Before this change there was an implementation comment # ignore flat tris, which suggested that the _add_tri was 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.

  • I'm not exactly sure what to expect from the output of triangulation. It looks like we always get some vertices that weren't in the input, but in most cases they are not actually used in any of the output triangles, so that seems fine (as reflected by the tests).
  • It doesn't fix all the issues described in Unexpected triangulation results #2247 (i.e. there is still an unexpected triangle and vertex).
  • It does a little refactoring/simplification in the implementation, which I think is correct, but would be good for someone to check my geometry!

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!

@andy-sweet andy-sweet marked this pull request as draft November 3, 2021 17:11
@andy-sweet andy-sweet changed the title Ignore all flat triangles in triangulation [WIP] Ignore all flat triangles in triangulation Nov 3, 2021
@SystemicArcana
Copy link

Should the assertion assert a != b and b != c and c != a be placed after the check for triangles with duplicate points? I kept on hitting a failed assert error there and moving that assertion fixed the issue for me.

@brisvag
Copy link
Collaborator

brisvag commented Jan 16, 2025

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.

Should the assertion assert a != b and b != c and c != a be placed after the check for triangles with duplicate points? I kept on hitting a failed assert error there and moving that assertion fixed the issue for me.

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!

@andy-sweet
Copy link
Contributor Author

@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 main and my brain over the next few days. If I fail, I'll mention you to try instead!

@andy-sweet
Copy link
Contributor Author

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.

@brisvag
Copy link
Collaborator

brisvag commented Jan 16, 2025

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 :)

@andy-sweet
Copy link
Contributor Author

Caught up with main and still feel fairly confident that this is an improvement over main, though it does not fix all the issues in #2247.

Should the assertion assert a != b and b != c and c != a be placed after the check for triangles with duplicate points? I kept on hitting a failed assert error there and moving that assertion fixed the issue for me.

Yep, let's do that!

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 _add_tri should never be called with repeat vertex indices. Unfortunately, I didn't write this code and I don't have access to the cited publication, so I can't state that with much confidence and feel a little nervous about (re)moving it.

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...

@andy-sweet andy-sweet marked this pull request as ready for review January 21, 2025 13:52
@andy-sweet andy-sweet changed the title [WIP] Ignore all flat triangles in triangulation Ignore all flat triangles in triangulation Jan 21, 2025
@brisvag
Copy link
Collaborator

brisvag commented Jan 21, 2025

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!

@brisvag
Copy link
Collaborator

brisvag commented Jan 21, 2025

We do have a genuine test fail though 🤔

@andy-sweet
Copy link
Contributor Author

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).

After the change, only test_triangulate_collinear_path_with_repeat fails, 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.

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.

@brisvag
Copy link
Collaborator

brisvag commented Jan 21, 2025

mhm... I'll try to look into it later to see if I can figure it out :)

@andy-sweet
Copy link
Contributor Author

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.

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 xfail and link to the issue. Pushed that up.

@brisvag
Copy link
Collaborator

brisvag commented Jan 22, 2025

Great, will merge soon unless @djhoese has some reason to block :)

@djhoese
Copy link
Member

djhoese commented Jan 22, 2025

I never understood it in the first place so go ahead and merge.

@brisvag brisvag merged commit d1c4d94 into vispy:main Jan 22, 2025
15 checks passed
@andy-sweet andy-sweet deleted the fix-triangulation-ignore-flat branch January 22, 2025 17:54
@brisvag brisvag mentioned this pull request Feb 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Unexpected triangulation results

4 participants