Polygon DEC #195

nzfeng · 2024-09-17T17:33:01Z

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 · 2024-09-17T21:57:53Z

@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 · 2024-09-25T22:27:59Z

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 · 2024-10-01T05:01:14Z

include/geometrycentral/surface/surface_point.ipp

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.

I think that might have actually been me at some point in the past... sorry! (I might have done this while debugging something else and accidentally included it in a PR.)

nmwsharp · 2024-10-01T05:02:00Z

include/geometrycentral/surface/surface_point.ipp

  }
  case SurfacePointType::Edge: {
-    return edge == other.edge && abs(tEdge - other.tEdge) < eps;
+    return edge == other.edge && tEdge == other.tEdge;


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

nmwsharp · 2024-10-01T05:04:51Z

include/geometrycentral/surface/embedded_geometry_interface.h

+  DependentQuantityD<std::array<Eigen::SparseMatrix<double>*, 7>> polygonDECOperatorsQ;
+  virtual void computePolygonDECOperators();
+
+  // helper functions


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?

Yeah... a lot of these functions depend on EmbeddedGeometryInterface and quantities within, which made it hard to truly separate these functions into separate files without writing tangled code with a bunch of arguments accounting for data being passed around (commit c94b23c).

For now I separated what I could cleanly separate, into a new file called polygon_mesh_helpers.cpp, which doesn't help a ton but is at least a tiny bit better. Other options I can see are to (1) move some function definitions into separate cpp files, even if all the function declarations remain in the one file embedded_geometry_interface.h; (2) think long and hard about how the number of functions could be reduced... though I'm not sure how to do that, currently, without sacrificing code cleanliness :(

nmwsharp · 2024-10-01T05:11:16Z

src/surface/embedded_geometry_interface.cpp

    he = he.next();
    Vector3 pB = vertexPositions[he.vertex()];
-    he = he.next();
+    do {


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 :)]

Should be fixed in a most recent commit!

nmwsharp · 2024-10-01T05:15:05Z

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.

…ing else except for DEC operators

…how much sense it makes to expose d operators since they map between the refinement

…act on the virtual triangle refinement, which will (should?) never get exposed to users

…so much uglier. I think I made a mistake to try and separate from the class as well...

…tryInterface

nzfeng · 2025-05-16T21:12:34Z

FYI this PR also updates the cornerAngles issue mentioned here.

nzfeng · 2025-05-19T21:20:13Z

I've squash-merged for now! 🤞

nmwsharp reviewed Oct 1, 2024

View reviewed changes

xprssn2 mentioned this pull request Jan 12, 2025

Logarithmic map and geodesic tracing for general polygon meshes #169

Open

nzfeng and others added 22 commits February 22, 2025 17:59

Block out functions and documentation; names could use some work

b6487e7

Add simple polygon operators, minus DEC operators

db076b6

Update variable names to something more manageable; flesh out everyth…

26f9e44

…ing else except for DEC operators

Update docs; in the middle of simple polygon DEC operators, not sure …

0f9b813

…how much sense it makes to expose d operators since they map between the refinement

Add polygon DEC operators

f4e0963

Get rid of simple polygon DEC operators (d0 and hodge1) because they …

5f45918

…act on the virtual triangle refinement, which will (should?) never get exposed to users

Add gradient and divergence operators

e529be4

Fix some typos and required quantities

aa0e80b

Fix DEC operators

bf79c2c

In the middle of debugging hodge1 and connection Laplacian

10b210a

Add a bunch of temporary experimentation

1fbdc3b

Update DEC and docs

27a6370

I forget what I added

db9b5ea

Finish polygon connection Laplacian

1c949b7

Get rid of redundant functions

a565c94

Use correct tangent basis vectors

54f2dab

Add rest of heat solvers for polygon meshes

e1ddcaf

Finalize changes

f4a76fe

Add licensing info

8ca9110

Finish implementation and docs

aa6ae5c

Add tests

5eacff4

Update cornerAngles function

dbb0b97

nzfeng force-pushed the polygon-dec branch from 326df40 to dbb0b97 Compare February 22, 2025 23:00

nzfeng added 2 commits May 16, 2025 11:42

Remove unused eps

bee9c13

Split off helper functions into a separate file... but the code gets …

c94b23c

…so much uglier. I think I made a mistake to try and separate from the class as well...

Separate just the helper functions that don't depend on EmbeddedGeome…

ad2367c

…tryInterface

nzfeng merged commit 73da1d8 into nmwsharp:master May 19, 2025
3 checks passed

Polygon DEC #195

Polygon DEC #195

Uh oh!

Conversation

nzfeng commented Sep 17, 2024

Uh oh!

nzfeng commented Sep 17, 2024

Uh oh!

fire commented Sep 25, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nmwsharp left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nmwsharp commented Oct 1, 2024

Uh oh!

nzfeng commented May 16, 2025

Uh oh!

Uh oh!

nzfeng commented May 19, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

fire commented Sep 25, 2024 •

edited

Loading