Convertir 3MF en PLY

Le Polygon File Format a été conçu à Stanford en 1994 pour numériser des objets avec un scanner 3D, et le choix qui en découle est dans le format : un en-tête ASCII lisible, un nombre quelconque de sommets, un nombre quelconque de triangles, et la possibilité d’attacher des propriétés par sommet et par face — couleur, normale, confiance, identifiant de scan, tout ce que l’expérience de numérisation veut noter. Le résultat est un format qui se prête aussi bien à un maillage qu’à un nuage de points pur.

3MF est un format d’impression. PrusaSlicer, Cura, Bambu Studio et Microsoft 3D Builder le lisent et l’écrivent, et en dehors de ce cercle le support s’amenuise. Quand un fichier d’impression doit entrer dans un pipeline de recherche, de CAO ou de visualisation, PLY est en général l’étape suivante : MeshLab, CloudCompare, PyVista, trimesh, et la plupart des outils de traitement de maillage le lisent sans configuration.

Un élément model d’3MF porte un attribut unit, et c’est le seul format de cet ensemble qui en déclare un. Le convertisseur le lit et met la géométrie à l’échelle en millimètres : micron par 0,001, centimètre par 10, pouce par 25,4, pied par 304,8 et mètre par 1 000. Le millimètre passe inchangé.

PLY n’a pas d’attribut d’unité dans sa forme standard, ce qui fait des millimètres un choix aussi bon qu’un autre. Le registre l’adopte par convention avec le monde de la CAO et de l’impression, qui lit des nombres non étiquetés comme des millimètres. C’est aussi le seul endroit de cette catégorie où les nombres que vous voyez après ne sont pas ceux avec lesquels vous avez commencé, ce qui vaut la peine d’être su avant de les comparer à un plan ou à un autre fichier ouvert dans la même scène.

Un 3MF sépare ce qu’est un objet de l’endroit où il va. La section resources contient les maillages ; la section build contient des items, chacun nommant un objet et portant optionnellement une transformation — douze nombres décrivant une matrice quatre-par-trois rangée par lignes, la dernière colonne étant implicite.

PLY n’a pas d’équivalent, donc la transformation de chaque item est appliquée à une copie des sommets de l’objet avant l’écriture. Les pièces arrivent là où la section build les a placées. Si le même objet est référencé par plusieurs items de build — la même cale imprimée quatre fois sur un plateau — vous obtenez quatre ensembles de sommets avec quatre copies complètes de la géométrie, parce qu’il n’y a pas d’autre façon d’exprimer une instance dans un format sans instanciation.

Un objet avec un attribut name le conserve, et le nom est écrit comme un commentaire dans l’en-tête PLY. C’est moins expressif qu’un groupe dans l’OBJ, et c’est volontaire : PLY ne connaît pas de groupes nommés, et la convention est d’utiliser des commentaires en début de fichier pour donner au lecteur un contexte que le format ne porte pas en propre.

Les objets sans nom reçoivent un nom générique. Notez que le sens compte : la conversion inverse, PLY vers 3MF, perdrait ces noms parce que PLY ne les porte pas dans la géométrie. L’information sort du 3MF et n’y rentre pas, et c’est la même limitation que pour les couleurs et les matériaux de la section qui suit.

3MF a un vrai modèle de matériau : groupes de matériaux de base, groupes de couleurs, et un index de propriété sur chaque triangle pour qu’un objet unique puisse être multicolore. Les imprimantes multi-matériaux l’utilisent et les trancheurs l’écrivent. Aucun de ces éléments n’est lu ici, et PLY n’a nulle part où les mettre de la même manière — le format a des propriétés par sommet, mais la conversion actuelle ne les remplit pas à partir des index 3MF.

C’est le coût d’un convertisseur qui transporte la géométrie entre formats qui s’accordent sur très peu d’autre chose. Si 3MF multi-matériaux est converti pour visualisation, la géométrie arrive et les couleurs doivent être recréées à l’autre bout. Garder 3MF d’origine à côté du PLY est la seule façon de préserver l’affectation exacte de matériau que le trancheur avait produite.

PLY a deux encodages : un format ASCII lisible par un humain, et un format binaire Little Endian qui est environ deux fois plus compact. Le format ASCII est ce qu’un humain peut ouvrir dans un éditeur de texte, et c’est aussi ce qu’un scanner écrit naturellement. Le format binaire est ce qu’une chaîne de traitement lit, et c’est le défaut d’à peu près tous les outils de recherche parce qu’il est plus rapide à parser.

La conversion écrit en ASCII par défaut parce que le fichier résultant reste lisible et se prête à un débogage rapide — un mauvais sommet se voit dans un éditeur de texte, ce qui n’est pas vrai en binaire. Pour un pipeline qui veut la taille minimale, ouvrir le fichier dans MeshLab et le ré-exporter en binaire est l’étape qui prend une seconde et donne un gain mesurable sur les maillages denses.

3MF permet de définir un objet non par son propre maillage mais par un élément components listant d’autres objets, chacun avec sa propre transformation. C’est ainsi que le format exprime un assemblage construit à partir de pièces réutilisables, et c’est légal et utilisé. Ce convertisseur lit l’élément mesh de chaque objet et ne suit pas components.

Un objet défini de cette manière ne contribue aucune géométrie, et si tous les objets du fichier sont un assemblage de composants, la conversion se termine par un message indiquant qu’aucune géométrie de triangles n’a été trouvée. Si un fichier converti manque des pièces que vous voyez dans votre trancheur, c’est la première chose à vérifier — réexporter depuis le trancheur aplatit en général l’assemblage en maillages simples.

Quand 3MF a une section build, seuls les objets que ses items référencent sont convertis. Un objet assis dans resources que rien ne construit n’est pas écrit dans PLY, ce qui est délibéré : la section build est la déclaration du fichier de ce qui se trouve réellement sur le plateau.

Il y a un repli. Un 3MF avec des ressources et aucune section build du tout — inhabituel mais lisible — voit ses objets convertis quand même, puisqu’ils sont manifestement le contenu et n’ont tout seulement aucun placement déclaré. Entre ces deux règles, PLY converti contient ce que 3MF disait être en train d’être produit, et une pièce qui disparaît était une pièce que le fichier ne revendiquait pas.

Le fichier s’importe dans MeshLab, CloudCompare, PyVista et Blender sans configuration. Il contient des lignes property et element, ce qui rend l’en-tête lisible et permet de vérifier d’un coup d’œil que le nombre de sommets est ce qu’il devrait être. Un PLY bien formé a un en-tête qui dit la vérité sur son contenu.

La première chose à vérifier est la taille. Le PLY est en millimètres par construction, et les applications de visualisation diffèrent sur ce que signifie une unité non étiquetée : Blender traite une unité comme un mètre par défaut, donc une pièce de 63,5 mm apparaît comme un objet de 63,5 mètres à moins que l’échelle d’import ne soit réglée. C’est une question d’échelle d’affichage et de scène plutôt qu’une erreur de conversion, et mesurer une dimension connue sur le modèle la règle en dix secondes.