Polygon DEC

[nzfeng]

Adds polygon Laplacian and other operators for general polygon meshes.

Summary of contributions:

• implementation of polygon Laplacian and mass matrices (unlumped & lumped) from Polygon Laplacian Made Simple by Bunge et al. 2020.
• implementation of polygon Laplacian, mass matrix, gradient, divergence, connection Laplacian, and DEC operators from Discrete Differential Operators on Polygonal Meshes by de Goes et al 2020.
• A PolygonMeshHeatSolver that implements the Vector Heat Method, Unsigned Heat Method, and Signed Heat Method on polygon meshes, analogous to the PointCloudHeatSolver for point clouds.
• Documentation & tests.

The only thing I'm not quite satisfied with is the naming convention for the operators from "Polygon Laplacian Made Simple": geometry.simplePolygonLaplacian, geometry.simplePolygonVertexLumpedMassMatrix, and geometry.simplePolygonVertexGalerkinMassMatrix. My concerns are

• the names can be quite long;
• perhaps the word "simple" will be mistaken as meaning "less sophisticated" and therefore "less accurate";
• perhaps the operators will be mistaken as only applying to "simple polygons", which are non-self-intersecting polygons without holes, though they can indeed apply even when polygon faces are self-intersecting.

Suggestions & review are welcome!

[nzfeng]

@MarkGillespie or @nmwsharp, adding this support for polygon meshes required making some changes for EmbeddedGeometryInterface --- mainly removing the asserts that assumed triangular faces in functions like computeCornerAngles() and computeFaceAreas().

I don't foresee that these changes will result in breaking behavior (especially since all tests have passed), but it might also be a good idea to have a geometry-central expert check the details in surface/embedded_geometry_interface.cpp!

[fire]

perhaps the word "simple" will be mistaken as meaning "less sophisticated" and therefore "less accurate";

What do you think of this argument?

geometry.basePolygonLaplacian, geometry.basePolygonVertexLumpedMassMatrix, and geometry.basePolygonVertexGalerkinMassMatrix.

Rename simple to base.

Like the base polygons are unrestricted, while for example manifold triangle polygon has numerous restrictions.

Edited:

See also general.

[nmwsharp]

This is awesome!! I left a few comments, but nothing major. Looks great.

[nmwsharp]

Why did we define == with a hidden internal eps!?? If I did that it was a silly mistake... This is breaking change but a good one I think.

[nmwsharp]

can you delete the unused eps variable above in this function?

[nmwsharp]

These are a lot of helper functions. I'm worried this class/file is getting too busy.

Could we maybe move these helpers to a separate file, and invoke them as-needed? And maybe once moved to their own file they no-longer need to be virtual?

[nmwsharp]

This function has quadratic complexity in the face degree, when it doesn't need to. It could be implemented with linear complexity by working one face at a time and maintaining a leading a trailing reference while orbiting the face.

[doesn't need to be fixed, just couldn't help but mention it :)]

[nmwsharp]

Re naming for simple polygon Laplacian (thanks for the ideas @fire!). Personally I think the name 'simple' is perfectly good. It matches the title of the paper it comes from. We also already use the term elsewhere in SimplePolygonMesh. Any confusion about the term will be quickly resolved by reading the docs.