Edge3 compatibility with poly2tri #3811
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This isn't going to get the geometry right in future cases where we ask for higher-order triangles and we have curved Edge3, but it's a step in the right direction; at least we're no longer throwing asserts (in debug mode) or empty results (in opt) when we're asked to triangulate an Edge3 boundary.
|
Downstream failures here are unrelated. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pinging @miaoyinb and @eshemon, both to report this and to ask a couple questions at the end.
The results of my preliminary investigation into poly2tri's interaction with quadratic elements:
Bad news: There are definitely a number of real bugs preventing our triangulators from generating output based on higher-order boundary and hole elements.
Good news: Getting output instead of bugs doesn't look to be very hard; it's easy enough to decimate boundary data before passing it along to poly2tri. This PR does that for the case of Edge3, and it took me an hour or two. Handling Tri6/Tri7/Quad8/Quad9 will be harder but I'd guess a day's work.
Bad news: Decimating boundary data decimates it. To get a geometrically-correct Tri6 triangulation from our output here, which for your use cases is kind of the whole point, we'll need to not only add a Tri3->Tri6 conversion (easy) but also snap our mid-edge nodes to the geometry defined by the original mid-edge nodes which, at that point, are already deleted by the decimation.
Good news: Preserving that data and doing the snapping afterward ... won't be an hour and a half job, but it will be doable without too much work, cleanly enough for my tastes. I ought to be able to squeeze this in to my meshing time in the next few months.
Bad news: The more sophisticated we want to make this, the harder it's going to be to do. "Snap existing boundary nodes to the correct geometry after all the interior geometry is done" will be some work. "Snap all boundary nodes afterward, because we want to be able to refine the boundaries" will be harder. "Snap all boundary nodes as soon as each boundary edge is refined, because we don't want the interior elements to be too stretched near the boundary" will be harder still.
How useful are each of those levels of sophistication for you? To put it into XYDelaunay terms, it's all about
refine_boundaryandrefine_holesoptions. Level 0 is "if you use quadratic elements, the triangulated domain borders can't even be curved" - I can't imagine that being useful to you but if I'm wrong let me know and I'll knock it out ASAP. Level 1 is "if you use quadratic elements, you can't refine borders". Level 2 is "if you use quadratic elements and you refine curved borders, elements near the border will be stretched". Level 3 is "this all actually works the way it should".