search

MarcoAttene / CDT

47 stars 13 forks source link

Recovering original vertex indexes #9

Closed sampotter closed 3 months ago

sampotter commented 3 months ago

I'm using CDT as a library inside a larger C++ program where I'm using it to build a tetrahedron mesh on the interior of a triangle mesh.

It would be very helpful if there were a convenient way to relate the original boundary triangle mesh to the tetrahedron mesh. To use CDT, I've basically just copied over what's done in the main executable, stripping out the extra options that I don't need. It does appear that CDT scrambles the vertices on the way in, and the permutation sending the final tetrahedron mesh vertices back to the original triangle mesh vertices isn't available, although I haven't studied the code very closely. Maybe it's hiding somewhere.

As an addendum, I will say that CDT is quite difficult to use as a library currently. No documentation, no examples, very little commenting, terse variable names...

MarcoAttene commented 3 months ago

Hi. Thank you for your interest in our code. I feel the need to clarify that this code is a prototype we used to demonstrate the results of our research. We released it on github in the hope that it is useful for others, but without warranties and/or commitments of any kind. We are currently committed to other projects and have no resources to maintain this code. Having said that, I think that the input vertices retain the same order in the output vector, and possible Steiner points are just appended afterwards. I say "I think" because I've not been working on this code for more than one year and I might have forgot something. Hope it helps!

sampotter commented 3 months ago

Hi @MarcoAttene. No problem, and thanks for the helpful clarification.

I believe there is a good chance that we (i.e., Coreform---the company I work for) will be pushing ahead with evaluating CDT for our purposes. This is motivated by the fact that TetGen doesn't have permissive licensing, and we need a tet mesher which conforms exactly to the input PLC.

So, I have two quick follow-up questions now that you've made your clarification:

  1. Do you think it makes more sense for me to maintain my fork with no intention of reconciling my changes with your code base? Or would you prefer that I submit pull requests to merge my changes back? I have already made some small changes to my fork and will continue to do so.
  2. In your SIGGRAPH paper on this library, you mention a version of Delaunay refinement based on your implicit predicates as a possible future research direction. Of course, we all know this can mean anything;-) May I ask what your plans are?
MarcoAttene commented 3 months ago
  1. Do you think it makes more sense for me to maintain my fork with no intention of reconciling my changes with your code base? Or would you prefer that I submit pull requests to merge my changes back? I have already made some small changes to my fork and will continue to do so.

This really depends. If you plan to have up to three/four pull requests per year and the changes are of general interest (e.g. bugfixes, optimizations, ...) you may proceed this way. Otherwise feel free to maintain your fork.

  1. In your SIGGRAPH paper on this library, you mention a version of Delaunay refinement based on your implicit predicates as a possible future research direction. Of course, we all know this can mean anything;-) May I ask what your plans are?

We are currently working on it, but our research is still at a fundamental level - we are still trying to understand whether to use a CDT as a starting point (as done in tetgen) or to adapt the input so that a true (a-la Ruppert) Delaunay refinement can converge. I'm afraid you'd better not expect results too early...

sampotter commented 3 months ago

OK, this all sounds good to me, @MarcoAttene. I'll check in with you later on.

I wish you luck on your research. It will be a very exciting result if you can get it to work. :-)

I'm trying to make do without refinement for now. Mainly, I'm using the constructed tet meshes as the starting point for building an atlas on the volume, so there is quite a lot I can do with simple refinement methods (e.g. conformal uniform refinement on each tetrahedron; or even uniform refinement with hanging nodes...).

But we do have some use cases where true Delaunay refinement would be quite helpful. But, using some other library MMG might get us pretty far when this comes up, anyway...