New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Poor geodesic distance accuracy in a simple case #5
Comments
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. |
Understood, thanks for the response! It would be great to expose more of the functionality supported by the intrinsic triangulation in general! |
Will close this issue since it doesn't seem like theres much actually actionable on this. |
Forgive me if my expectations for accuracy are unreasonable for the HEAT method. I have the following minimal example
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 oft_coef
The text was updated successfully, but these errors were encountered: