Ridges and bad refinement

[Johannes_Neumann]

Hello,

I’m trying to use MMG3D while providing ridges. I’ve created a simple test mesh which contains a couple of ridges on round surfaces.

On the left you can see the input mesh together with the provided ridges. When called with
mmg3d_O3 -in egg.mesh -out out.mesh -nr -hgrad 1.3 -hausd 0.001
I obtain the output mesh on the right side where one of the rings is not meshed correctly and the ridges are moved out of place. In an anisotropic setting it get’s worse.

Here is the test mesh. It contains two volume sets, ridges and four triangle sets.

egg.mesh (723.4 KB)

Did I make a mistake during mesh saving (ridge/edge orientation/format/sets) or is it something else? The angle at that ridge is 179° so almost flat but not quite.

Thanks a lot,
Johannes

[Johannes_Neumann]

I could side step the problem by providing the ridges also as RequiredEdges though I feel that this is less ideal.

[Algiane]

Hi,

The issue you are facing is due to the fact that you provide ridges on along edges that don’t define real sharp angles. Some of our computations are sensitive to the almost colinearity of the normals along the 2 surfaces on both sides of the ridge.
The issue is more visible using anisotropic remeshing because normals and tangents are more frequently used (due to the fact that we need it to transport and/or rotate the metric tensors along the surface).

Normally, if you provide reference edges instead of ridges, the direction of the provided lines should be preserved (such as in the attached picture, obtained with your command line args and the -ar 25 threshold for ridge detection):

If reference edges are not enough because you want to avoid the surface smoothing along the lines, it seems from your mesh that the use of ridges along one line only creates issues (probably because the other lines form a sufficiently sharp angle) so maybe you can define only the other lines as ridges?

You have already founded the other possible solution: using required edges to avoid the normal computation along the lines. It has 2 drawbacks: (i) your lines will not be remeshed, (ii) the behaviour along required edges may change in a distant future, we guarantee to preserve required edges but we may choose to build a smooth surface along it one day (because in fact it doesn’t make lot of sense to manage required entities as surface singularities…).

Best regards,
Algiane

[Johannes_Neumann]

I see. How can I provide reference edges. Are these those Edges in the mesh file that are not marked as Ridges (or RequiredEdges)?

In that scenario, the ridges would solely come from the angle detection together with edge alignment from the reference edges and otherwise the reconstructed surface at those edges would be smooth, correct? So if I’d provide ridges for large enough angles and otherwise reference ridges I should be able to get close to what I want, correct?

edit: Or do you mean to provide different references for the edges?

[Algiane]

Hi,

Yes, you have understood the idea: you can provide ridges for large enough angles and ref edges otherwise.
You don’t have to provide different references for the edges.

By default, any edge that is provided is a reference edge (so all edges following the Edges keyword). In a normal use, these edges define geometrical lines (characterized by their tangent) which, a priori can be remeshed, but for which a bezier curve is reconstructed in order to preserve the regularity of the curved line (a new node is not inserted in the middle of the “straight” edge). Without other specifications, the surface is supposed to be smooth across the reference edges (on both sides of the edge, 2 distinct bezier patches are reconstructed but they share the same normal(s) along the edge).

Additionnal features, such as the ridge specification or the required one, can be attached to reference edges:

• For ridges, it means that the edge (or the line, at least locally), is at the interface of 2 portions of surfaces that intersect with a sharp angle. On such locations we don’t want to reconstruct a smooth surface across the ridge: it is a singularity along the surface. Thus, in this case, at each node along ridges, we must be able to compute one normal per portion of surface and both normals must not be colinear (the 2 bezier patches that are built on both sides of the ridge will not share the same normal(s) along the ridge);
• For required edges, it only means that Mmg is not allowed to remesh the edge.

You can either provide your own ridges if you know where they are or let Mmg detect it (sometimes the automatic detection is not possible due to spuriosities on the surface that creates artifact ridges). But if you provide ridges, they have to be at a sharp angle (to ensure the non-colinearity of the computed normals).

Best Regards,