Convertir GLTF en PLY

PLY est sorti de Stanford en 1994 exactement dans ce but : un mesh avec un ensemble arbitraire et auto-descriptif de propriétés par sommet et par face, dans un en-tête qu’un programme peut lire sans rien connaître à l’avance. Ce design est pourquoi il est devenu la devise courante du balayage, de la photogrammétrie et du travail académique en géométrie, et pourquoi CloudCompare, MeshLab, Open3D et trimesh le traitent tous comme une entrée de premier ordre.

glTF a été conçu pour l’extrémité opposée du pipeline — livrer un actif fini à un moteur de rendu sur un réseau. Ses forces sont ce qu’un outil de mesure ignore : définitions de matériaux, empaquetage de textures, animation, mécanismes d’extension. Plusieurs de ces outils n’ont aucun importateur glTF du tout, et ceux qui en ont un le traitent comme un ajout tardif. Convertir est en général plus rapide que de se battre avec cela.

Il est délibérément minimal : le mot magique ply, puis `format ascii 1.0`, un commentaire nommant l’enregistreur, une déclaration d’élément vertex avec son compte, trois lignes property float pour x, y et z, une déclaration d’élément face avec son compte, une ligne property list uchar int vertex_indices, et end_header.

C’est le dialecte PLY le plus largement supporté qui existe. Un compte de faces en uchar avec des indices int est ce que presque tous les lecteurs supposent quand ils prennent des raccourcis, et des positions float plutôt que double garde le fichier à la moitié de la taille pour une précision dont aucun mesh ici n’a besoin. Si vous écrivez un parseur sur cette sortie, ces sept déclarations sont le contrat entier.

Chaque coordonnée est écrite en texte décimal, un sommet par ligne et un triangle par ligne. Un sommet qui occupait douze octets dans le buffer glTF en occupe ici vingt à soixante, donc attendez-vous à ce que le PLY soit plusieurs fois la taille de la géométrie dont il vient. Un modèle de deux millions de triangles est un gros fichier texte.

La compensation, c’est que rien n’y est ambigu. Le PLY binaire vient en variantes petit-boutiste et gros-boutiste avec des agencements de propriétés qu’un lecteur doit reconstruire depuis l’en-tête, et des hypothèses mal alignées là produisent des meshes qui se chargent comme du bruit. L’ASCII ne peut pas échouer de cette manière, et pour un fichier qui va entrer une fois dans un outil d’analyse, la taille compte rarement plus que la certitude.

Un fichier PLY contient un élément vertex et un élément face. Il n’y a pas de groupe, pas d’objet, pas de pièce. Le convertisseur fusionne donc tous les meshes qu’il a lus depuis la scène glTF en une seule liste, en décalant les indices de chaque mesh du nombre de sommets déjà écrits pour que les triangles pointent toujours au bon endroit.

La géométrie est inchangée et la structure est partie. Un glTF assemblé de douze pièces nommées devient une surface de douze coquilles déconnectées, et les noms partent avec la structure. Si ces divisions sont ce dont vous avez besoin en aval, OBJ est la cible qui les garde, et convertir en OBJ à la place ne vous coûte rien d’autre que ce que PLY aurait fourni.

La raison la plus citée d’utiliser PLY est qu’il porte du rouge, du vert et du bleu par sommet, ce qui est la façon dont un balayage par photogrammétrie porte son apparence sans texture. Le format le supporte et les lecteurs s’y attendent.

Ce convertisseur n’en écrit pas. La couleur dans un glTF vit dans les matériaux et les textures indexés par des coordonnées UV, et aucun de cela n’est lu ; il n’y a pas d’attribut de couleur de sommet à transporter à moins que la source en ait déclaré un, et cet attribut n’est pas lu non plus. La sortie est une surface sans couleur, ce qui est correct pour la mesure et faux si ce que vous vouliez était un export qui préserve l’apparence.

La scène est parcourue depuis sa scène par défaut, chaque matrice de nœud multipliée par son parent, et la matrice monde appliquée aux sommets. Les nœuds écrits avec translation, rotation et échelle séparées sont d’abord composés en matrice, selon la convention de quaternions que glTF définit.

Faire cela avant la fusion est ce qui rend la fusion sûre. Si les transformations restaient non appliquées, aplatir plusieurs meshes en une seule liste empilerait chaque pièce à l’origine et produirait une forme qui n’a aucun rapport avec le modèle. Cuire d’abord signifie que les nombres que vous mesurez dans CloudCompare sont les nombres que la scène glTF décrivait.

Un buffer d’indices, transporté verbatim. glTF stocke les triangles comme des indices dans un tableau de positions partagé, et la conversion préserve cette structure élément par élément plutôt que de la reconstruire — aucune fusion n’est appliquée sur ce chemin, parce qu’il n’y a rien à réparer. Un STL arrivant à la même destination doit d’abord être soudé, puisqu’il stocke trois sommets non partagés pour chaque triangle par construction.

Cette distinction décide si l’analyse que vous allez exécuter signifie quoi que ce soit. Vérifications de manifold, estimation de normales, courbure, distance géodésique, lissage laplacien et décimation supposent tous la connectivité. La seule réserve à emporter dans MeshLab est que les exportateurs dédoublent les sommets aux coutures d’UV et de normales, et que ces doublons survivent ici comme des entrées distinctes à coordonnées identiques, donc un passage Merge Close Vertices avant une vérification topologique est une bonne habitude.

Un .gltf qui garde sa géométrie dans un .bin séparé ne peut pas être lu, parce qu’un convertisseur mono-fichier ne suit jamais la référence ; le message le dit et suggère le .glb, qui contient tout en un seul endroit. Un fichier utilisant KHR_draco_mesh_compression s’arrête sur un message nommant Draco, dont le décodeur n’est pas embarqué ici.

Les primitives qui ne sont pas des listes de triangles sont ignorées. Le mode 4 de glTF est triangles ; les triangles étirés, éventails, lignes et points ne sont pas des surfaces que ce convertisseur peut transformer en faces, et un fichier ne contenant que cela signale qu’aucune géométrie triangulaire n’a été trouvée plutôt que de produire un PLY vide qui échoue silencieusement dans votre analyse deux étapes plus loin.

Si vous allez regarder le modèle plutôt que le mesurer, PLY est une mauvaise destination : pas de matériaux, pas de textures, pas de structure, et un fichier bien plus gros. Gardez le glTF, ou convertissez en OBJ si la visionneuse est ancienne.

PLY gagne sa place quand l’étape suivante est un algorithme de géométrie — décimation, remaillage, remplissage de trous, alignement contre un balayage, mesure de volume ou de surface, distance de Hausdorff entre deux versions de la même pièce. Pour ce travail, la platitude et l’absence de couleur sont sans importance, et avoir le mesh dans le format autour duquel l’outil a été écrit vaut plus que tout ce que la conversion laisse tomber.