Mmgs : surface remesher with stl-like geometry

User Help
#1

Hello,

I’d like to remesh a very bad stl-lie geometry to get a better surface mesh using hgrad parameter (seems unsensitive).
I tried with the attached surface mesh file playing with hgrad but without good results.
export.mesh (9.0 KB)

I’d like to have this kind of improvements :

  • remesh a “bad” stl file
  • uncoarse a too fine mesh
    Any idea ?
    Best regards.

before
before1024×600 91.9 KB

after
after1024×600 134 KB

before1
before11024×600 73.4 KB

after1
after11024×600 67.4 KB

#2

Hello,

I have results quite close to those you are looking for on the attached file using -hmax option of Mmg that impose maximal edge length (see attached image). The command line I used is the following:

mmgs_O3 -hmax 0.1 export.mesh

Capture d’écran 2022-12-06 à 02.59.46
Capture d’écran 2022-12-06 à 02.59.461128×1142 44.5 KB

You can also play with -hsiz option instead of the -hmax, it will probably give similar results as it asks for a constant edge length aver the mesh. Similarly to -hmax option you can play with the -hmin one to force coarsening.

Difficulties that you may encounter on other models:

  • the fact that mmgs deal only partially with non-manifold edges (edges belonging to more than 2 triangles): we are able to insert nodes along such edges in the first wave of adaptation (rough adaptation to mesh size) but not in the second wave (fine adaptation to mesh size) and we are not able to collapse nodes along such edges (thus, mesh coarsening doesn’t work along non-manifold edges)
  • issue with the surface model due to the fact that your input mesh is stl-like and Mmg doesn’t have enough internal vertices along surfaces to get informations on the underlying surface. this issue is discussed here: Wrinkles in surface mesh with Mmgs.

In all cases, you can help Mmg by providing input ridges (edges along sharp angles) and normals at nodes.

Best

#3

Hi @Algiane,
Thanks for your answer, I got the same results as you. But as you can see, when using hmin/hmax, the mesh seems to not take into account hgrad.
With the following parameters hgrad=2, hmin=0.0034 and hmax=0.17, I get this with using mmgs :

image
image1212×870 68.3 KB
image
image852×918 35.1 KB

With a commercial mesher I get the following result using this parameters

image
image935×730 185 KB
image
image1065×715 159 KB

You think mmgs can’t produce this kind of mesh ?

Best regards.

#4

Hi Friends,

I’m facing similar issues with non manifold geometry, and would like to add some informations.

Algiane, you’ve suggested to “help” MMGS by defining Edges / Ridges int the input mesh.
I’ve tried that, using either Ridges or RequireEdges, but in both case the result is exactly the same, HGrad is not respected in the model (actually the result mesh is exactly the same, either defining edges or not).

Of course tweaking HMax will somehow do the job, but this is like “cheating”, and is not always suitable.
Moreover, defining a correct HMax for a specific model is not always possible.
Finally, using HMax will lead in numerous cases to over refined meshes.

Thanks for you help !

#5

Hi,

Without input size map, Mmg compute its own size map in order to satisfy the prescribed hausdoff distance while respecting the gradation threshold and truncating sizes by hmin/hmax parameters. On your mesh, it gives the following:

  • step 1 - computation of the size map linked to the hausdorff distance
    as your input mesh contains only planar surfaces, the hausdorff distance is 0 everywhere (the discretization represent perfectly the underlying geometry) and the associated computed size map contains infinite sizes. And Mmg will not refine your boundaries on this criteron.
  • step 2 - truncation by hmin/hmax
    then this size map is truncated by the hmax/hmin parameters: in your case, only the hmax parameter applies because all sizes are too large. You obtain a uniform size map equal to hmax.
  • step 3 - sizes gradation to avoid too large variations between the lengths of consecutive edges
    the aim of this step is to control the mesh quality: if we have large variations for edges belonging to one element, then the element will b distorded. In your case the size map is constant so the gradation doesn’t apply.

I think that there is a misunderstanding for the hgrad parameter: it doesn’t force edge jumps to be equal to the threshold, it only ensure that the jump is not larger than this threshold.

For the comparison with the commercial mesh: It seems to detect that some edges are constrained by the geometry and will be forced to be very small. It is an approach that you have often when you work in the specific field of mesh generation (because you always start from the definition of the geometry). In Mmg, we don’t have this kind of detection (we guess that we don’t know if our mesh is a direct definition of the geometry of the object or if it is a discretization / computational mesh of the object.

To conclude: sorry, but with mmgs, you will need to compute and impose your own size map. I think that it is not too hard to do, either by directly hacking mmgs to impose small sizes on corners, either with mmgs API functions:

  • you run mmgs one time in analysis mode to add corners to your mesh
  • you travel your mesh nodes and impose a small size at corners and a large one on other nodes.
  • you run mmgs a second time with this size map.

For the aircraft test, I think that the hausdorff threshold is too large.

Just for your info: it is my last answer on this forum because I leave the project tomorrow.

Best Regards

#6

Algiane, thanks a lot for this deep and full explanation.

I agree with you on that point, but if you look at the second image of MrBenson, you’ll see that the “jump” between edges can be locally way larger than the threshold, and this is the very point !

For any pair of touching edges in the model, the ratio between their length should be between 1/Th and Th (this comes from MMG doc).
And you can obviously see that this is not the case in the above images.
So maybe it is a misunderstanding of the HGrad param, or maybe a misleading description in the doc ?

By the way, thanks Algiane for your efforts and wish you the best in your next adventure :slight_smile:

#7

Hello @Algiane ,
Thanks a lot for your explanations that’s make clear some points. I hope mmg will still be maintened.
I wish you good luck in you next challenge.

Best regards.