Convertir GLB en PLY

La raison pour laquelle cette paire existe est une discordance entre la distribution et le traitement. GLB a gagné comme la façon de remettre un modèle à quelqu’un : un seul fichier, pas de fichiers joints, matériaux emballés, visualisable dans un navigateur avec un simple élément. PLY a gagné dans le monde du traitement de géométrie des décennies plus tôt, et trimesh, Open3D, MeshLab, CloudCompare et PyTorch3D le traitent tous comme le format qui n’a pas besoin d’explication.

Donc une collection arrive en GLB et la première chose que quiconque en fait est convertir. Ce qui compte à ce moment-là n’est pas la fidélité à la source — personne n’allez faire de rendu avec ça — mais savoir exactement ce que le chargeur verra : combien de sommets, si la surface est d’une pièce, et si le fichier fera cinq mégaoctets ou cinquante.

PLY a un bloc `element vertex` et un bloc `element face`. Il n’a aucune notion d’objet, de groupe ou de nom, donc un GLB contenant un corps, un couvercle et une poignée est fusionné : les listes de sommets sont concaténées et les indices de face de chaque mesh sont décalés du nombre de sommets déjà écrits.

La géométrie est identique et la structure est partie. L’analyse en composantes connectées retrouvera tout de même les trois pièces — `trimesh.Mesh.split()` et le Split in Connected Components de MeshLab fonctionnent tous les deux sur le résultat — mais les noms ne reviennent pas, et deux pièces qui se touchent sont maintenant des régions adjacentes d’une surface plutôt que deux objets. Si l’identité des pièces compte pour ce que vous faites, OBJ est le format qui la garde.

L’en-tête lit toujours `format ascii 1.0`. Il n’y a pas d’option binaire et aucun réglage pour la changer, donc chaque coordonnée est écrite en chiffres décimaux et chaque face comme une ligne commençant par le chiffre 3. PLY est défini comme texte ou binaire et ce convertisseur n’écrit que le premier, ce qui vaut la peine d’être su parce que les résumés de format — y compris celui de ce site — décrivent PLY comme un format binaire.

En pratique cela veut dire que le fichier est plusieurs fois plus gros que la forme binaire équivalente : une coordonnée float32 occupe quatre octets compactés et environ dix à quinze caractères écrits. Tout le monde le lit, `head -20` vous montre l’en-tête, et un diff entre deux exports est lisible. Si vous avez besoin de la forme binaire, MeshLab et trimesh l’écrivent tous les deux, et un seul réenregistrement fait la conversion.

Certaines sources sur ce site sont soudées à l’entrée — un STL stocke trois sommets indépendants par triangle et produirait sinon un fichier quatre fois plus gros que nécessaire. Un GLB ne l’est pas : sa géométrie est déjà un tampon de sommets indexé, donc les positions et le tableau d’indices sont transportés tels quels.

Cela veut dire que le nombre de sommets dans le PLY correspond aux nombres d’accesseurs de la source, ce qui est exactement ce que vous voulez quand la conversion est une étape d’une mesure plutôt qu’une livraison. Cela veut aussi dire que les doublons que la source contenait sont toujours là — une couture d’UV coupe un sommet en deux copies coïncidentes dans chaque exportateur glTF, et ces copies arrivent dans le PLY. Si un algorithme en aval a besoin d’un index étanche, faites la fusion avec une tolérance dans la bibliothèque plutôt que d’attendre du convertisseur qu’il l’ait faite.

Neuf lignes et pas davantage : le mot magique, le format, un commentaire de générateur, l’élément vertex avec son compte et trois propriétés float, l’élément face avec son compte et un `property list uchar int vertex_indices`, et `end_header`. Lire les deux comptes en haut du fichier est le recensement de triangles et de sommets le plus rapide disponible, et il n’a besoin d’aucune bibliothèque.

Ce que l’en-tête ne déclare pas, c’est quoi que ce soit d’autre. Pas de propriétés de couleur, pas de normales, pas de coordonnées de texture, pas de commentaires portant des unités ou la provenance, pas d’éléments définis par l’utilisateur. Un chargeur qui lit ce fichier apprend la géométrie et rien d’où elle vient, ce qui est bien pour une étape de traitement et mauvais pour une archive — alors gardez le GLB.

PLY est le format vers lequel on se tourne précisément parce qu’il porte la couleur par sommet, ce qui est la raison pour laquelle les scanners l’écrivent. Un GLB a souvent de la couleur à donner : un attribut `COLOR_0`, ou plus souvent une texture de couleur de base avec des coordonnées UV. Rien de cela n’est lu, et l’écriture n’émet que x, y et z.

Le résultat est donc une géométrie sans apparence, et si l’apparence est ce que vous alliez analyser — comparer des numérisations, vérifier une capture, évaluer un rendu de texture — c’est la mauvaise route et la réponse est une bibliothèque qui lit les deux attributs. `trimesh.load("model.glb")` vous donne le visuel autant que le maillage et exporte un PLY coloré directement. Pour du travail de géométrie pure, rien de tout cela n’importe et le fichier sobre est plus petit.

Le convertisseur parcourt le graphe de scène depuis la scène par défaut, compose la matrice de chaque nœud avec son parent, et applique le résultat avant l’écriture. Un GLB qui plaçait un mesh à quatre positions produit donc quatre jeux de sommets à quatre endroits plutôt qu’un mesh et quatre matrices.

C’est le bon comportement, parce que PLY n’a aucun moyen d’exprimer une instance, et c’est aussi à garder en tête quand les nombres semblent faux. Une boîte englobante calculée sur le PLY couvre toute la scène assemblée, pas le mesh source, et un modèle dont l’auteur a laissé la racine de scène translatée arrive loin de l’origine. Les deux sont des propriétés du GLB plutôt que de la conversion, et les deux sont à un `mesh.apply_translation(-mesh.centroid)` d’être réglés.

Ni GLB ni PLY ne porte d’unité. glTF est par convention écrit comme si une unité valait un mètre ; PLY ne fait aucune déclaration du tout, et les outils de numérisation qui l’écrivent travaillent généralement en millimètres. Rien dans la conversion ne rapproche cela, et rien ne le pourrait.

Pour un pipeline de mesure, c’est un risque réel plutôt qu’une note de bas de page, parce qu’un volume calculé sur des coordonnées non étiquetées est un nombre sans unité attachée. Établissez le facteur une fois, depuis une dimension que vous pouvez vérifier dans la source, et enregistrez-le à côté du jeu de données. Si la collection vient d’un générateur unique, le facteur est en général constant à travers elle, ce qui en fait un travail de cinq minutes fait une fois plutôt qu’une question par fichier.

Un dossier se convertit ici en une passe et revient en ZIP, ce qui est une façon raisonnable de traiter des dizaines de fichiers et une mauvaise façon d’en traiter des milliers. Le plafond gratuit est de 100 Mo par fichier et le travail se fait dans un onglet de navigateur, donc une grande collection est lente et, plus important encore, non reproductible — rien n’en est capturé dans un script.

Pour tout ce que vous exécuterez deux fois, `trimesh.load(path, force="mesh").export(out)` fait deux lignes, lit le GLB nativement, garde les couleurs par sommet si vous les demandez, et écrit un PLY binaire. Utilisez cette page pour ce qu’elle sait bien faire : convertir trois fichiers à la main pour voir à quoi ressemble réellement la géométrie avant de vous engager sur la façon dont les trois mille autres seront traités.

Dans cet onglet de navigateur. La conversion est du JavaScript simple sans module WebAssembly à télécharger, rien n’est téléversé, il n’y a pas de compte et pas de quota journalier, et l’onglet réseau pendant une conversion ne montre rien sortir. Vous pouvez le confirmer en filtrant les requêtes sur le domaine et en constatant que seul le téléchargement initial de la page apparaît avant l’instant où vous déposez le fichier.

Cela vaut la peine d’être vérifié plutôt que cru, et c’est important pour deux raisons qui se recouvrent ici : les jeux de données de recherche viennent fréquemment avec des conditions de redistribution, et un modèle scanné ou capturé d’un objet réel peut être une divulgation en soi. Aucune de ces questions ne se pose quand le fichier ne bouge pas, et la page peut aussi être consultée hors ligne une fois chargée si la machine n’est pas non plus connectée.