MeshHeatVectorSolver::transport_tangent_vectors Non-finite matrix entry for finite input

[JulianKnodt]

I've read thru prior issues & didn't see any similar problems before, so I am logging this in case you're interested in updating it.

I am testing a mesh with many small triangles (area < 1e-8), and am hitting NaNs when trying to transport multiple transport vectors over the surface of the mesh. I noticed that the x-basis & y-basis provided by solver::get_tangent_frames also has some NaNs in it, so I suspect that the NaNs are internal to the algorithm. I triple checked that the input vectors I'm providing are not NaN. In this case, should I work to clean my input mesh, or is it likely I am using the API incorrectly?
If it is a problem with the input, what conditions should I change such that the input will work sufficiently well?

If you need the mesh to test, please let me know.

[nmwsharp]

I just pushed some changes which modify the algorithm for the VectorHeatSolver to use intrinsic triangulations under the hood by default, if you're lucky it might fix this problem.

However, if your mesh has 0-area (or very nearly 0-area) triangles, it is possible that many routines will fail due to the degeneracy (it sounds like perhaps constructing tangent frames per-vertex is failing, probably due to 0-length edges). My usual suggested workaround is to use intrinsic mollification, but these bindings are not configured to do that internally right now.

If you're up to writing some C++ you could try it using the lower-level implementation in geometry-central linked above. Otherwise it would require adding some more features to the bindings, and I can't say when I'd be able to do that.

[JulianKnodt]

I'll try out your changes, I probably don't have time to try out the C++ version but will lyk if it fixes it!