Ruppert's Refinement Algorithm.

[Islam0mar]

Current status --20°threshold--:

Issues:

• Currently refinement is applied on all triangles inside super triangle which isn't efficient. Better update triangles linkage after deleting super/outer/... triangles, so refinement can be applied on the result.
• Some cases goes into infinite loop (Constrained Sweden.txt, square with crack.txt).

TODO:

• Cleanup
• Increase Steiner point number inside addVertex.
• Remove not referenced vertices.

Ref.s:

• Lecture Notes on Geometric Robustness for equations such as circumcircle.
• A Delaunay Refinement Algorithm for Quality 2-Dimensional Mesh Generation

[artem-ogre]

Great, thank you for the PR, @Islam0mar!
I will look into it as soon as I will have time.

[artem-ogre]

Hi @Islam0mar,
I had some time today to start looking at your code. So far it looks really neat! Thanks a lot for your work.

I did some code refactoring and fixing. You can check it out here.

Constrained Sweden.txt refines now and looks absolutely stunning:

I did not yet have time to look at the core parts of the algorithm, so this is still a work in progress.

[Islam0mar]

Hi @artem-ogre,

I have merged your branch and did these changes:

• Add functions to collect erased triangles to run refinement on non-erased triangles only.
• Fix split condition.
• some GUI improvements.

Results:

[Islam0mar]

@artem-ogre sorry, I didn't notice your recent refactor.

let me know your opinion about collecting erased triangles.

[artem-ogre]

Hi @Islam0mar,

Sorry that I could not find time to continue working on it yet. But I remember about this PR all the time :)

Yes, I think we should implement skipping the 'to-be-erased-later' triangles and I have some ideas of how this could be done. However, I think it is best to first focus on the core of the algorithm and get it right. Skipping triangles is an improvement that can always be implemented on top.

Another feature that's really nice to have is not to attempt refining triangles where both edges of the sharp angle are constrained (because it is futile and leads to infinite loop in the refinement).

[starseeker]

@artem-ogre @Islam0mar I'm interested in this work as a possibly-more-robust-than-poly2tri CDT for triangle generation from trimmed NURBS surfaces... if there's a potential infinite loop case with constrained edges on sharp angles, would you advise avoiding testing such an application for now?

[artem-ogre]

@starseeker
Are you interested particularly in Ruppert refinement or generally in triangulating polygons? Triangulating polygons (constrained or conforming Delaunay triangulation) is already possible in CDT. And if there are no self-intersections in the polygon both methods should be robust (constrained triangulation 100% numerically robust).

[artem-ogre]

@starseeker
Generally triangles where an acute angle is formed by two constrained edges cannot be refined without violating the constraints. In this PR (as it is now) this indeed leads to an infinite refinement but we plan to add some strategy to terminate the refinement (e.g., not even attempting to refine triangles with constrained acute angle or adding a lower threshold on such triangle's surface area). Also it is already possible to set a limit on the number of vertices inserted during refinement.

[starseeker]

@artem-ogre My specific interest is triangulating a data set with bounding polygons, holes and "interior" points not on polygons - the latter serving to force the generated mesh to more closely conform to a NURBS surface from which we're generating the input data. In poly2tri the latter are Steiner points - I wasn't sure if this work was also adding that capability, or whether the inserted points are only generated algorithmically for refinement purposes.

This report has some visual examples of the sort of thing we're trying to do: https://apps.dtic.mil/sti/pdfs/AD1094344.pdf (Figures 12, 13 and 17 for example) Apologies if I'm a little off topic for this particular pull request.

[artem-ogre]

@starseeker
CDT is a general purpose Delaunay triangulation library: input does not have to be a polygon and any arbitrary points can be added. One needs to provide the points however. This PR is implementing a triangulation refinement: new points are inserted into a triangulation so that triangles with acute angles are split into triangles with larger angles until some refinement criterion is reached.

[Islam0mar]

Hello @artem-ogre,

I have found the error in Constrained Sweden.txt case:

• according to WHEN AND WHY RUPPERT’S ALGORITHM WORKS, not all bad triangles should be resolved.
• some new vertices already exists in the input vertices.
• tryAddVertexToLocator doesn't handle nan and consume lots of memory--this case happens from duplicated vertices--.

Reading through triangle. I used his condition on equidistant to avoid aggressive splitting and it seems to work.

Let me know your opinion about these updates, so we can move forward with this PR.

[artem-ogre]

Hi, Islam. Thanks for continuing working on it. I came to similar conclusions earlier and was thinking about skipping triangles when, e.g. acute angle is formed by constraint edges. Regarding inserting duplicates I recently updated CDT to throw an exception when this happens.

I will check out your changes. Are you available for a call or messaging so we can efficiently discuss how this can be finalized? My email is [email protected].

[Islam0mar]

Sure. I available for a call or messaging, [email protected]

[sampotter]

How's this going? Anything I can do to help? Having this feature would be huge.

[artem-ogre]

@sampotter
Hello, thanks for your interest.

The status is that I can’t yet find the time and energy to integrate this PR. I work on CDT in my spare time, and I’m on parental leave with two small kids (almost no spare time). Integrating this feature is very high on my TODO. I think that Islam’s fork is in quite a good state and can be used at one’s own risk for CDT refinement “here and now”. I will try to do it this July but no promises.

[sampotter]

@artem-ogre Ah, I hope you're enjoying your parental leave. :-)

I just forked both CDT and PythonCDT and hooked Islam's changes up for myself and it seems to work well so far. At least, for the simple example I'm working with, I didn't notice any issues, and tried a reasonable spread of parameters while refining.

Is there anything I can do to help with integration? Or should I just wait until you have more time?

[LukeMinnich]

hello! FWIW I would also like to use the work in this branch. I'd like to use CDT in a commercial product, so I plan to perform lots of fuzz testing. If @Islam0mar or anyone else could resolve the branch conflicts, I'd be happy to test and share my findings of any issues. After some initial testing, I'm hitting an infinite loop, and I don't know if that's simply because the fork is behind by several commits. In the meantime, I'll read up on the underlying methods and see if I can't troubleshoot any issues on my own.

[sampotter]

@LukeMinnich @artem-ogre I'm actually in a pretty similar situation. We need a Delaunay mesher with refinement that has a more permissive license and haven't been able to reach Shewchuk to work out some kind of deal to use Triangle. I'm not sure to what extent we'll be able to share data, but if we're able to get CDT integrated into our usual workflow, we'll be stress testing it on a continuous stream of examples coming from real CAD geometry and should be able to provide useful fuzzing.

[artem-ogre]

@LukeMinnich @artem-ogre I'm actually in a pretty similar situation. We need a Delaunay mesher with refinement that has a more permissive license and haven't been able to reach Shewchuk to work out some kind of deal to use Triangle.

CDT exists because we were not able to reach Shewchuk. And we tried hard.