heat_geodesic underestimating distance about gptoolbox

[alecjacobson]

TL;DR The "Geodesics in Heat" method needs a clean triangle mesh. Remeshing will improve accuracy.

These results were initial surprising to me. I played around quite a bit and have come to the conclusion that "Geodesics in Heat" is fairly sensitive to the mesh triangle quality.

First things first, 3D plots in MATLAB can be very deceptive. Here's the default view of the peaks surface:

Looks like a good enough mesh, eh?

The deception is that MATLAB automatically scales the axes to fit the window by default. You can see the actual surface by issuing:

axis equal

Now it's quite clear that the mesh elements are severely stretched along the "peaks".

The "geodesics in heat" method is based on solving the Poisson equation using the finite-element method. The accuracy of these solutions is bound by the quality of the underlying mesh.

To investigate this, consider keeping this mesh but changing the height from a flat (no peaks) to 10-meter tall peaks.

Left: Exact geodesic to centre point. Right: "Geodesic in heat".

As the peak gets higher, the mesh gets more and more stretched out. The difference between the exact distance and Geodesics in heat gets larger and larger.

The Geodesics in Heat method has a couple parameters. I'm using the boundary conditions that the Crane et al. refer to as "Robin" boundary conditions. For the "time" parameter, I conduct a search for the optimal value with respect to error against the exact solution using fminsearch. For the error, I factor out a constant scale and shift.

The error seemingly grows exponentially with respect to the height of the peaks.

It most cases, meshes can be "fixed" or "cleaned" to have better behaving differential operators.

In this case, I tried flipping all non-Delaunay edges while keeping the same vertex set. This does change the surface, but not so dramatically. Better remeshing methods exist.

You can see that the mesh combinatorics change as the height changes, but the comparison to the exact geodesic distance is much better.

Indeed, the error is much lower (and quadratic(?) if I had to guess by eye-balling).

Another possible fix is to avoid converting the peaks quad-mesh into a triangle mesh in the first place. There are discretizations of the surface Laplacian for quad meshes that might work better and avoid the needs for remeshing.

Disclaimer: There's always a chance that my implementation of "Geodesics in Heat" is flawed and this could be improved without remeshing. If you're reading this and you know it to be the case, let me know!

[keenancrane]

@alecjacobson, are you using the implementation from libgeodesic, or did you roll your own?

Running this on a unit square mesh with libgeodesic I get a corner-to-corner distance of 1.4128, which is very close to sqrt(2) ≈ 1.4142. So it seems there may be a bug in the gptoolbox implementation. (Boundary conditions, perhaps?)

As for the "peaks" mesh, your implementation is visibly computing a pretty reasonable distance function (even on the original mesh), but it seems to be shifted relative to the polyhedral distance. How are you picking the constant shift in the final Poisson solve?

[alecjacobson]

On the flat square, the exact and my implementation agree up to 1e-3 (I'm fine with that).

But they really disagree for this "peaks" mesh.

I'm using my own Matlab implementation. I could try libgeodesic if you think it's a bug.

FWIW Here's a .obj file of the "tall" peaks mesh

tall-peaks.obj.zip

[keenancrane]

Here's the first thing I caught in the MATLAB implementation:

% "Note that a Dirac delta appears as a literal one in this system since we
% are effectively working with integrated quantities"
u0 = zeros(n,1);
u0(gamma) = 1;

Q = M - t*L;
B = M*u0;

What's written in the comments disagrees with what happens on the final line: the right-hand side should just be a Kronecker delta, not weighted by the mass matrix (i.e., the final B vector should contain only zeros or ones).

[alecjacobson]

Thanks for catching that. I fixed it, but it didn't make a qualitative difference on these meshes.

I also quickly tried libgeodesic (below is a simple command line wrapper calling it with temporary files from Matlab). The results are not identical but look similar and exhibit the same issues on the stretched out peaks mesh.

function D = geodesic(V,F,gamma,t)
  % GEODESIC Simple wrapper for calling libgeodesic, the reference
  % implementation for "Geodesics in Heat" [Crane et al. 2013].
  %
  % Inputs:
  %   V  #V by 3 list of vertex positions
  %   F  #F by 3 list of triangle indices into V
  %   gamma  list of source vertex indices into V
  %   t  smoothness parameter (use ~40x `t` in `heat_geodesic.m`)
  % Outputs:
  %   D  #V list of distances
  %   
  prefix = tempname;
  input_obj = [prefix '.obj'];
  input_txt = [prefix '.txt'];
  writeOBJ(input_obj,V,F);
  f = fopen(input_txt,'w');
  fprintf(f,'%d\n',1);
  fprintf(f,'%d ',[numel(gamma);gamma(:)]);
  fprintf(f,'\n');
  fclose(f);
  path_to_geodesic = '/Users/ajx/Downloads/libgeodesic/geodesic';
  command = sprintf('%s -i %s -s %s -o %s -m %g -b %g', ...
    path_to_geodesic,input_obj,input_txt,prefix,t,0.5);
  [status, result] = system(command);
  if status ~= 0
    fprintf(command);
    error(result);
  end
  output_obj = [prefix '.0.obj'];
  [~,~,D] = readOBJ(output_obj);
  D = D(:,1);
  delete(input_obj);
  delete(input_txt);
  delete(output_obj);
end

[keenancrane]

Ok, sounds good—the noisy solution in the first post had me a bit worried (still not sure what's going on there!).

Yeah, I'm not surprised if it doesn't work well on the "stretched" mesh. Would be interesting to try fast marching here, though I think again you may not have much luck since most of the triangles will be (very) obtuse. The polyhedral distance may be the only way to go if you want to avoid remeshing.

…that being said, window-based algorithms for computing the polyhedral distance are essentially doing a kind of remeshing! Basically the windows slice up the triangle into a (not simplicial, but still polygonal) mesh that is ideally suited to computing the distance to the given point:

The distance is computed on the augmented mesh, but in the end you just throw away this intermediate mesh and store the distance values on the vertices of the original mesh. Of course, the downside of doing it this way is that that new "mesh" is tailored to one particular query point (or points); you have to "remesh" for each new query.

From this point of view, the idea of remeshing in order to run a PDE-based method (like fast marching or the heat method) becomes less objectionable. Probably the right idea is to perform a remeshing that (i) keeps the original vertex set and (ii) keeps the original piecewise linear geometry. For instance, use Delaunay insertion rather than Delaunay flips. This way you can still compute distance values for the original vertex set, without modifying at all the geometry of the surface. Unlike window-based algorithms, a potential benefit is that your mesh does not depend on the choice of query point, i.e., it can be re-used for future queries. On the flip side, it may be that for certain corner cases (like extreme "stretching" of a mesh along one axis) the size of the Delaunay triangulation grows faster than the number of windows used by a polyhedral scheme.

In the end, there is probably no silver bullet. But "intermediate remeshing" sounds like a good general design principle for geometry processing software, especially when PDEs are involved. :-)

[quadmotor]

Ok, sounds good—the noisy solution in the first post had me a bit worried (still not sure what's going on there!).

Yeah, I'm not surprised if it doesn't work well on the "stretched" mesh. Would be interesting to try fast marching here, though I think again you may not have much luck since most of the triangles will be (very) obtuse. The polyhedral distance may be the only way to go if you want to avoid remeshing.

…that being said, window-based algorithms for computing the polyhedral distance are essentially doing a kind of remeshing! Basically the windows slice up the triangle into a (not simplicial, but still polygonal) mesh that is ideally suited to computing the distance to the given point:

The distance is computed on the augmented mesh, but in the end you just throw away this intermediate mesh and store the distance values on the vertices of the original mesh. Of course, the downside of doing it this way is that that new "mesh" is tailored to one particular query point (or points); you have to "remesh" for each new query.

From this point of view, the idea of remeshing in order to run a PDE-based method (like fast marching or the heat method) becomes less objectionable. Probably the right idea is to perform a remeshing that (i) keeps the original vertex set and (ii) keeps the original piecewise linear geometry. For instance, use Delaunay insertion rather than Delaunay flips. This way you can still compute distance values for the original vertex set, without modifying at all the geometry of the surface. Unlike window-based algorithms, a potential benefit is that your mesh does not depend on the choice of query point, i.e., it can be re-used for future queries. On the flip side, it may be that for certain corner cases (like extreme "stretching" of a mesh along one axis) the size of the Delaunay triangulation grows faster than the number of windows used by a polyhedral scheme.

In the end, there is probably no silver bullet. But "intermediate remeshing" sounds like a good general design principle for geometry processing software, especially when PDEs are involved. :-)

wow,
this thread is nice, is it the original idea lead to the Intrinsic Triangulations?

[alecjacobson]

IIRC the original "intrinsic triangulation" for laplacians is "A discrete Laplace-Beltrami operator for simplicial surfaces." by Bobenko & Springborn way back in 2005. Matt Fischer and colleagues followed up on this with a flipping strategy and description of building the intrinsic Delaunay laplacian in "An Algorithm for the Construction of Intrinsic Delaunay Triangulations with Applications to Digital Geometry Processing" in 2006 (there're a couple minor typos in this paper if I remember right).
As far as I know, the first paper to consider heat geodesics in the context of intrinsic Delaunay triangulations is "Efficient Construction and Simplification of Delaunay Meshes" by Yong-Jin Liu and colleagues in 2015, who propose yet a different remeshing method but compare to IDT:

Can't speak for others, but I wasn't aware of this 2015 paper at the time of this thread.

"The Vector Heat Method" (2017) and then "Navigating Intrinsic Triangulations" (2019) by Nick Sharp and colleagues does a really thoroughly study intrinsic triangulations and propose insertion technique that improves things well beyond just flipping edges (sadly not yet implemented in gptoolbox).

[keenancrane]

As Alec points out, the idea of intrinsic triangulations is much older. The first work to really consider this perspective in depth was Alexandrov’s study of embeddings of convex polyhedra in the 1940s. Regge outlined machinery for solving problems of relativity using intrinsic triangulations in the 1960s, which looks a lot like modern geometry processing and discrete differential geometry. Rivin considered the intrinsic Delaunay triangulation for Euclidean polyhedra in the 1990s, and Bobenko and Springborn defined an associated discrete Laplace operator in the 2000s.

It is an unfortunate oversight that we didn’t use the intrinsic Laplacian for the original heat method—which may have avoided many initial critiques of sensitivity to mesh quality. Later, more sophisticated data structures for intrinsic triangulations (such as Fisher’s explicit overlay, and the signposts of Sharp et al) are not necessary for applying the intrinsic Laplacian to this problem—since the true geodesic distance is not a function of the triangulation, and can be trivially copied from the vertices of one triangulation to another. Intrinsic Delaunay refinement (a la Sharp et al 2019) can make things more robust & accurate, but requires more sophisticated intrinsic data structures, to allow vertex insertion.