Incorrect Hausdorff distance?

[jdumas]

Hi,

I'm observing a weird bulging effect with mmgs's surface remeshing. If I take a unit cube and remesh it with the default option, without angle detection (-nr -hausd 0.01), I get the following result:

Measuring the Hausdorff distance with the original cube gives me a value of 0.21, which is super large compared to the requested one (0.01). Any idea what went wrong? How is mmg ensuring the Hausdorff distance during the remeshing?

[Algiane]

Hi Jeremie,

Your initial mesh is a cube mesh with 2 triangles per faces?

In fact, Mmg computes the local Hausdorff (and not the global one):

• Mmg build and ideal surface from the initial discretization by local approximations: we build a curve cubic bezier triangle from the coordinates and the normals of a triangle vertices. Thus, we compute the Hausdorff distance between each curve triangle and the initial triangle.

• if this distance is too large, we insert points onto the curve bezier triangle (on the linked picture, the initial straight triangle is in grey, the bezier triangle is dashed, we insert points because the Hausdorff distance is too large and we obtain the triangles in red)

  
  • At the next step of mesh adaptation/optimization, a new "ideal" surface is computed: from the new coordinates and normals of each triangle, we build cubic bezier triangles...

I think that the 0.21 value is the maximal distance between the faces of the initial cube and the final mesh, so the global Hausdorff distance, am I right?

In your case, because the automatic detection of sharp angles is disabled, Mmg "smooth" the geometry according to the normal at vertices that it computes (from the normal at the triangles sharing the vertex) and as you have very few triangles per cube faces, this normal is far from the normal at the cube faces. With sharp angles, Mmg computes 2 normals per point (one for each surface that the sharp angle delimits) so the cube geometry keeped.

To conclude, in your case, you have 2 solutions:

• enabled the automatic sharp angles detection;
• provide the corner and sharp angles (ridges) to the software.

[jdumas]

Thanks for the detailed explanation.

How can we provide ridges to mmg?

In fact I stumbled upon this issue when trying to remesh the Ford engine model. The cylindrical holes are made of long thin triangles, and I'm seeing bulges inside the holes, even with sharp angle detection enabled. I think mmgs should subdivide triangles until a certain edge length is reached before attempting to remesh using local Hausdorff distance maybe? I mean I could also look into doing this preprocessing myself and see if it helps.

[Algiane]

Because of the coarse initial mesh, the surface reconstruction of Mmg is very sensitive to the ridges detection. To give the ridges to Mmg :

• using an an input file, it is possible only with the Medit file format (not the Gmsh one): you can use the Ridges keyword followed by the number of ridges and the list of the indices of the edges that are ridges (see the Medit documentation );
• using the API + library, you can use the MMG3D_Set_ridge(MMG5_pMesh mesh, int k) function (k being the index of the edge that you want to mark as a ridge);

If you know it, you can also provide the normals at vertices to Mmg:

• with the Normals and NormalAtVertices keyword in your input file (resp. the list of normals and the list of indices to which the normals apply);
• with the MMG3D_Set_normalAtVertex(MMG5_pMesh mesh, int k, double n0, double n1, double n2) function in library.

[jdumas]

Ok thanks! Any suggestion how to deal with the long triangles in the cylinders of the ford engine model? Would providing correct ridges and vertex-averaged normals on non-feature vertices would be enough to get a good remeshed surface? How does mmg numbers the edges of the mesh? Do I need to explicitly call MMG3D_Set_edge and then call MMG3D_Set_ridge with the same number? If I provide vertex normals with MMG3D_Set_normalAtVertex, will mmgs recompute one normal per incident triangle for vertices on a ridge?

[jdumas]

Just for reference, here is the result I'm getting if I try to remesh the Ford engine model from Thingiverse, as linked above:

I just merged duplicated vertices from the .stl, saved as .mesh, and called mmgs with default parameters on it.

[Algiane]

Hi Jeremie,

You made a good point, in fact, providing the vertex averaged normals on non feature vertices is exactly what Mmg computes so the result will be pretty similar. And for now, Mmg always computes its own normals at ridges points so you don't have any way to provide it. But I think that it can be useful to add it (I am not sure about when it can be done but I add it to my todo list).

Having the suitable ridges will strongly help Mmg (see the attached picture) but it seems to not be sufficient. I am not sure why but Mmg still corrupt the geometry in some specific areas.

To provide ridges, yes, you must explicitly call MMG3D_Set_edge and then MMG3D_Set_ridge with the edge index.

[jdumas]

How did you generate the above screenshot then? By changing the angle threshold for ridge detection?

[Algiane]

Oh yes, sorry: I use the increase the sensitivity for the sharp edge detection -ar 15 option (just to check that having all the ridges of the cylinder helps). Of course, in consequences, I have some spurious ridges.

[jdumas]

Ok I see. Not completely satisfactory since it still mess up the geometry somehow. Please let me know if you ever find out why.

[jdumas]

Just a note that -- unsurprisingly -- this problem also happens with mmg3d. Here is an example using default ridges in red. The result is over-refined in region where the ridge detection missed the transition to the flat regions. This creates some unwanted bump, although not as bad as on the previous example.

If you're interested let me know and I can upload the input tet mesh.

[Algiane]

Hi Jeremie,

Thank you for the feedback. Yes, it is not suprising that missing some ridges leads to introduce a bunp in the surface: Mmg thinks that the surface is smooth so it computes the normals at vertices taking into account the 2 surfaces that in fact are shared by a sharp angle.

But I am still not sure of what happens here, because in this case, it seems that we have all the ridges but we still destroy the surface.

Regards,

Algiane

[pareshspatel]

Hi Algiane,

MMGS messes up the geometry and causes bulging effect in curved areas with high aspect ratio triangles. Is there a solution or work around for this issue? What is the root cause of the problem? I can help resolve the issue.

Regards,

Paresh

[Algiane]

Hi Paresh,

The bulging effect may have several causes:

• the initial mesh is meshed "side to side" (I am not sure of the english term) : as you don't have any point between sharp angles, the mesher becomes very sensitive to errors in the normal evaluation; If I remember well it is what happens finally here
• the Mmg analysis misses some sharp angles. It happens here. In this case you can try to play with the '-ar' option or to provide some sharp edges in input.
• a bug (;-) )

Do note hesitate to create a new post around this issue and to attach your input mesh, I can try to see what happens...

Regards, Algiane

[pareshspatel]

Algiane , thank you for your message. I'll create an issue and attach a simple sample model. Thanks!