MMG3D_Set_triangles switches the second and third vertices

[jcortial-safran]

It is obvious when looking at the source code :

mmg/src/mmg3d/API_functions_3d.c

Line 943 in fe5ce20

ptt->v[0] = tria[j] ;

However, MMG3D_Set_triangle (actually used in the examples) does not perform the switch.

[jcortial-safran]

There seems to be the same inconsistency in MMGS :

mmg/src/mmgs/API_functions_s.c

Line 541 in fe5ce20

ptt->v[0] = tria[j] ;

[Algiane]

Hi,

Thank you for your contribution. Indeed, it doesn't make much sense to permute the triangles vertices but does it create an error in Mmg or is it an issue for you?

I think that in any cases, when Mmg analyzes the surface mesh provided by the user, it tries to find a consistent orientation for connected pieces of surface and may change the orientation of your input triangles:

• for 3D volume meshes, triangles are oriented in the direction of the outward normal for an outer surface and in an arbitrary direction for an inner surface
• for 3D surface meshes, the orientation of the first provided triangle is choosen (I think).

Thank you by advance for your feedback,
Best

[jcortial-safran]

So far I did not observe any error in Mmg due to triangle orientation.

Nevertheless, I think there should be a consistent behavior between MMG3D_Set_triangles on the one hand and MMG3D_Set_triangle, MMG3D_Get_triangles and MMG3D_Set_triangle on the other hand.

Currently, a round trip using MMG3D_Set_triangles and MMG3D_Get_triangles does not preserve the user data, which is how I discovered the discrepancy.

[Algiane]

Hi,

I agree that a consistent behaviour would be preferable: I just wanted to be sure on the consequences of the vertices swaps.

As it doesn't create errors, I prefer to integrate your improvement in the 'develop' branch that in the 'master' one (in which I try to only directly merge hot fixes): it will be integrated in the next release of Mmg.

Best