Poor geodesic distance accuracy in a simple case

[brucedjones]

Forgive me if my expectations for accuracy are unreasonable for the HEAT method. I have the following minimal example

import numpy as np
from potpourri3d import MeshHeatMethodDistanceSolver

solver = MeshHeatMethodDistanceSolver(np.array([[0, 0, 0], [1, 0, 0], [0, 1, 0]]), np.array([[0, 1, 2]]))
solver.compute_distance(0) # -> array([0.        , 0.70710654, 0.70710654])
solver.compute_distance(1) # -> array([0.91430181, 0.        , 1.31933315])
solver.compute_distance(2) # -> array([0.91430181, 1.31933315, 0.        ])

The fact that the first example is returning distances of sqrt(2)/2 makes it seem like this is a bug rather than a limitation of the method somehow.

Its worth noting that setting t_coef=0.001 makes the results of the second two cases more accurate, but the first case returns [0. , 0.70710654, 0.70710654] no matter the value of t_coef

[nmwsharp]

Hi! Thanks for reaching out.

What you observe here sounds correct and is the typical behavior of this algorithm. The Heat Method is a PDE-based method, so it works by solving a sequence of partial differential equations on the surface. This is great because it gives it nice smooth results and allows us to leverage fast numerical solvers, but a small downside is that your mesh needs to have enough vertices to accurately represent the solution. This is similar to simulation problems, where simulating on an extremely coarse mesh often doesn't work well.

You should find that if you refine the mesh to have more vertices, the solution quickly becomes more accurate.

For a fancier solution to this problem, intrinsic refinement quickly produce meshes on which PDEs are very accurately solved, while avoiding many of the usual pitfalls of remeshing (however, this refinement is not currently exposed in Potpourri3d, only a simpler intrinsic flipping :) )

I also just added a small note to the potpourri3d readme about topic.

[brucedjones]

Understood, thanks for the response! It would be great to expose more of the functionality supported by the intrinsic triangulation in general!

[brucedjones]

Will close this issue since it doesn't seem like theres much actually actionable on this.