Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
A simplicial mesh structure that supports general non-manifold meshes and associated data
C++
branch: master

Fetching latest commit…

Cannot retrieve the latest commit at this time

Failed to load latest commit information.
VS_files
headers
src
test
.gitignore
Acknowledgments.txt
README

README

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".
Something went wrong with that request. Please try again.