Convertir STL en PLY

Chaque autre paire dans cet ensemble sacrifie quelque chose. glTF perd ses matériaux, OBJ perd son MTL, 3MF perd sa couleur. STL en PLY perd les normales de face, et elles sont calculées à partir de l’ordre d’orientation par chaque lecteur qui en a besoin et sont notoirement fausses dans les fichiers produits par des exportateurs négligents, ce qui explique que plusieurs slicers ignorent entièrement la valeur stockée.

Tout le reste survit parce qu’il n’y avait rien d’autre. Un STL est une liste de triangles sans couleur, sans unités, sans noms, sans pièces et sans attributs. Un PLY écrit avec x, y et z et une liste de faces contient exactement cela. Les deux formats s’accordent sur ce qu’est un modèle, ce qui est une chose rare dans cette catégorie.

CloudCompare, MeshLab, Open3D et trimesh prennent tous PLY comme entrée de première classe, parce que Stanford l’a conçu en 1994 exactement pour ce genre de travail : un en-tête auto-descriptif listant les propriétés par sommet et par face dont un outil de recherche a besoin. Le scan et la photogrammétrie l’ont standardisé pour la même raison.

Ils lisent aussi STL, et c’est là que les ennuis commencent plutôt qu’ils ne finissent. Un STL se charge, s’affiche et a l’air correct tout en étant topologiquement inutile — voir la section suivante. Convertir n’est pas une question d’ouvrir le fichier ; c’est une question d’obtenir un mesh dont les algorithmes puissent se fier à la connectivité.

STL stocke trois sommets indépendants pour chaque triangle. Un cube est trente-six enregistrements de sommets pour huit positions. Chargez cela dans un outil de mesh et demandez si la surface est fermée, et il vous dira que chaque arête est une arête de bord, parce qu’aucun triangle ne partage un sommet — même si la forme n’a aucun trou.

La conversion arrondit les coordonnées à six décimales, s’en sert comme clé, et effondre chaque coin à la même position en un sommet partagé référencé par tous ses triangles. Six positions est bien en dessous de toute tolérance dont une pièce physique se soucie et bien au-dessus du désaccord de dernier bit que deux triangles adjacents ont en flottant. Ensuite, contrôles de manifold, estimation de normales, courbure, décimation, lissage et remplissage de trous opèrent tous sur une vraie adjacence.

L’en-tête est le conservateur : ply, format ascii 1.0, un commentaire nommant l’auteur, une déclaration element vertex avec trois lignes property float pour x, y et z, une déclaration element face avec une ligne property list uchar int vertex_indices, et end_header. Puis une ligne par sommet et une ligne par triangle.

Rien d’autre n’est déclaré — pas de normales, pas de couleur, pas de confiance, pas de qualité, pas de propriétés personnalisées. C’est volontaire : un en-tête qui promet une propriété que le fichier ne peut pas remplir est pire qu’un en-tête court, et chaque lecteur qui gère PLY gère ce dialecte. Si votre pipeline attend des propriétés spécifiques, MeshLab peut les ajouter après l’import plutôt que le convertisseur de les deviner.

Chaque enregistrement de triangle de cinquante octets dans un STL binaire commence par douze octets de normale de face. Ces douze octets sont sautés. L’information qu’ils portent est entièrement déterminée par l’ordre des trois sommets, donc la recalculer est exact plutôt qu’approximatif.

Ce n’est pas un raccourci pris par commodité. Les normales STL stockées sont en désaccord avec l’orientation assez souvent pour que plusieurs slicers et outils de mesh les écartent par principe, précisément parce que trop d’auteurs se trompent sur le signe ou la normalisation. Recalculer à partir de l’orientation donne une réponse cohérente, et un mesh dont l’orientation est incohérente est un défaut que vous voulez voir plutôt qu’un que vous voulez recouvrir d’une valeur stockée.

Chaque coordonnée est écrite comme du texte décimal, un sommet par ligne, et chaque triangle comme un 3 suivi de trois indices. Un sommet qui faisait douze octets en binaire en fait vingt à soixante en texte. En face de cela, le soudage a déjà supprimé environ cinq sixièmes des enregistrements de sommets que le STL portait.

Les deux effets s’annulent en partie et le résultat dépend du modèle. Ce qui est prévisible est le côté STL : exactement 84 + 50n octets pour n triangles, donc un mesh de deux millions de triangles dérivé d’un scan fait 100 Mo avant conversion et vaut la peine d’être décimé d’abord. Si le PLY résultant est peu maniable, l’enregistrer en sortant de MeshLab en binary_little_endian est un correctif en une étape.

La raison la plus courante de cette conversion est l’analyse de déviation : une pièce a été imprimée ou usinée à partir d’un STL, puis scannée, et quelqu’un a besoin de la différence. La distance cloud-to-mesh de CloudCompare veut la référence comme un mesh avec des faces, ce que cela produit, et le scan comme des points, ce que le scanner a produit.

Deux aspects pratiques. Les deux jeux de données doivent être alignés d’abord — une sélection grossière de paires de points suivie d’ICP est la voie standard — et ils doivent partager une échelle, qu’aucun format ne déclare. Si le scan est en millimètres et que le STL a été exporté en pouces, l’alignement convergera vers quelque chose de plausible et de faux, donc vérifiez une dimension connue sur les deux avant de faire confiance à une carte de couleurs.

PLY est le format dans lequel arrivent les scans 3D parce qu’il porte la couleur par sommet, et c’est ce qui fait qu’un mesh de photogrammétrie ressemble à l’objet dont il vient. Rien de tout cela n’apparaît ici, parce qu’un STL n’avait pas de couleur à donner.

L’exception officieuse mérite d’être nommée : une poignée d’outils encodent une couleur de quinze bits dans les deux octets d’attribut à la fin de chaque enregistrement de triangle STL, selon deux conventions mutuellement incompatibles. Ces octets ne sont pas lus. Il n’y a aucun moyen de dire quelle convention un fichier utilisait, et deviner mettrait des couleurs fausses sur un mesh que quelqu’un est sur le point de mesurer.

Si la destination est un slicer ou un service d’impression, ne convertissez pas — ils veulent du STL ou du 3MF, et le support PLY dans ce monde est inégal. Si la destination est un visualiseur de navigateur, glTF est la bonne cible et PLY la mauvaise.

Convertissez quand l’étape suivante est un algorithme : un calcul de distance, une décimation, un remaillage, un remplissage de trou, un volume ou une surface, un alignement contre des données scannées. Toute la valeur de l’étape est dans le soudage et le format que l’outil attend, et cela tourne entièrement dans votre navigateur sans téléversement, ce qui compte quand la géométrie de référence est une pièce non sortie de quelqu’un.