A simplicial mesh structure that supports general non-manifold meshes and associated data
|VS_files||Fixed potential stack overflow.|
|src||Corrected likely cut/paste error: next/prevFace used m_FE instead of …|
|.gitignore||Added gitignore rules|
|Acknowledgments.txt||Added some acknowledgments of funding sources.|
The goal is to construct a general non-manifold, non-regular simplicial mesh data structure and library for representing simplicial complexes up to 3D (verts, edges, faces, tets) and associated data stored on the simplices. (This essentially means a mesh that mixes and matches regions of solo vertices, segments, triangles and tetrahedra, rather than requiring restrictions, e.g. only triangles, embedded in 3D, with no non-manifold edges.) Priority is given to simplicity and usability over speed, hence the choice (for now at least) of using a representation based loosely on sparse incidence matrices. Our goal is to facilitate research in non-manifold mesh processing and simulation. Because of the potential complexity of such meshes, the intention is for mesh operations to rely on a core set of "atomic" operations of the form addSimplex/deleteSimplex, and write all other operations in terms of these ones. Only common operations that would be significantly accelerated by being integrated into the core data structure should be implemented within SimplicialComplex itself, while all others should be relegated to external utility functions/classes. The underlying data structure is analogous to that discussed in "Building Your Own DEC at Home" by Sharif Elcott and Peter Schroeder, again emphasizing simplicity. Ultimately, it should be possible to swap this out for a more efficient (but complex) one, if desired. E.g. the IA* data structure from the SMI paper "IA*: An Adjacency-Based Representation for Non-Manifold Simplicial Shapes in Arbitrary Dimensions" by Canino, de Floriani, and Weiss. Likewise, since the code is intended for research purposes, we should err on the side of safety when we can, by spending extra effort to make handles (and possibly some iterators) robust in the face of mesh editing. This has not been done yet. We aim for a similar degree of ease of use (and relatively comparable API) as the recent Surface_mesh library for triangle meshes, by Daniel Sieger and Mario Botsch described in the IMR paper "Design, Implementation, and Evaluation of the Surface mesh Data Structure".