Python bindings to geometry-central?

[mhogg]

Have you considered providing python wrapper of geometry-central? Yes - I realize it would be a significant amount of work :)

[nmwsharp]

Yes, we have considered it. And yes, it is a ton of work :) We're very interested; the only thing holding it back is the time investment.

There are two main strategies one could pursue for bindings:

• Option A: Write bindings for high-level routines, which would take in rectangular arrays defining a mesh (etc) and give back the result as one big array. E.g. a binding for building the Laplace matrix, or a binding for computing heat distance. I've already written a few bindings of this form for personal code, and they aren't too bad. PyBind11 w/ automatic Eigen/Numpy interop works wonders.

• Option B: Really write bindings for all of geometry-central: the mesh element types, containers, query functions, etc. This is a lot more work, and in some cases it might be quite difficult to translate C++ concepts to Python bindings (e.g. some of the neighborhood iterators). However, it's the most powerful option, and could offer a fully-feature mesh library beyond much of what exists in the Python ecosystem.

Obviously, I gravitate a bit more towards Option A, since it's straightforward. However, I'm interested to hear if folks would have a use-case for Option B.

[MJHutchinson]

Is there anything a mainly python developer could do to help speed up this process (I can also vaguely write C++)? I am keen to use the vector heat method in particular for a machine learning application and would love to not have to rewrite the method in numpy or similar! I'd be willing to put a reasonable amount of time into helping with this.

Alternatively, you mention

I've already written a few bindings of this form for personal code

would it be possible to share these to see how it works, and I could then apply this to the methods I need?

[nmwsharp]

Actually, I have just the thing! I put this up on pip recently: https://github.com/nmwsharp/potpourri3d which includes Vector Heat Method stuff on meshes and point clouds. Hopefully it serves your use case.

Feature requests or pulls in that repo are welcome for additional parts of geometry-central which you would like to make use of.

[mhogg]

This is what I wanted too! Do your heat methods actually calculate the geodesic path, in addition to the geodesic distance?

On Fri, Mar 12, 2021, 3:38 AM Nicholas Sharp @.***> wrote:

Actually, I have just the thing! I put this up on pip recently: https://github.com/nmwsharp/potpourri3d which includes Vector Heat Method stuff on meshes and point clouds. Hopefully it serves your use case.

Feature requests or pulls in that repo are welcome for additional parts of geometry-central which you would like to make use of.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nmwsharp/geometry-central/issues/64#issuecomment-796871849, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA3WP6VXZT7JF3RZIVS4MULTDDPVRANCNFSM4WII6RCQ .

[MJHutchinson]

This is brilliant, thank you!

One thing that I'm particularly interested in is being able to precompute the transform that gives the parallel transport between each pair of nodes in the mesh. For a 3D mesh I think this would be an NxNx2x2 matrix. I need this as I want to use these parallel transports many times, and I want to be able to backprop through them in something like PyTorch.

Is there a sensible way to compute this using the vector heat method? My best guess is that I could for every node and for each of the two basis vectors at the node , compute the parallel transport of that basis vector to every other node and build the matrix I need iteratively?

[nmwsharp]

Do your heat methods actually calculate the geodesic path, in addition to the geodesic distance?

No, they do not calculate shortest geodesic paths. Part of why they are fast & simple is because they really just output the distance function itself without a full representation of the paths. You can sorta reconstruct a path by tracing the distance function backwards, but this isn't guaranteed to work out.

Separately, there are some other flip-based algorithms in geometry-central for manipulating geodesic paths (but not-necessarily shortest geodesics), but that's another story.

[nmwsharp]

the transform that gives the parallel transport between each pair of nodes in the mesh

Makes sense! Initializing a solver and using a for-loop to populate this tensor by computing parallel transport from each vertex is a reasonable way to go about it. Perhaps we could add a builtin for this in potpourri3d, though I'm not sure there would be much performance gain.

[MJHutchinson]

I know of at least 1 other person who might be interested in this, so I think it would be nice to add as a utility in potpourri3d! I'll work on something.

@nmwsharp do you have any good resources for getting started writing bindings using pybind11 and the automatic NumPy integration? It's not something I'm very familiar with.

[nmwsharp]

Pardon the delayed response, but posting here for posterity:

For using pybind11 w/ numpy, the amazing thing is that it basically just works automatically. Write functions that take Eigen arrays as inputs and outputs, and pybind11 will magically generate bindings that convert to/from numpy arrays.

The only tricky part then is getting initial build system and basic binding commands set up. Just copying / bootstrapping of https://github.com/nmwsharp/potpourri3d is a good option in this case.

One small tip I have is not to directly expose the generated bound function to Python users, but instead to create an extra level of indirection (users call a higher-level Python function, which then calls the bound function). This is useful when you inevitably want to add some error checking or argument translation on the Python side, which is otherwise impossible if they are directly calling the bound function.

[sonukiller]

Any updates regarding the Python wrapper with pybind11?