Convertir PLY en GLTF

PLY a été publié en 1994 par Greg Turk pour la communauté de recherche en graphisme, et le format a la forme des fichiers de cette époque : un en-tête texte qui déclare les propriétés, puis une longue liste de lignes où chaque sommet et chaque face est écrit comme une suite de nombres. Un humain peut l’éditer dans un éditeur de texte, ce qui est parfois exactement ce qu’il faut, et beaucoup plus souvent la seule raison pour laquelle un fichier en est encore un.

La conversion lit cet en-tête pour trouver le nombre et le type de propriétés, ignore les faces qui ne sont pas des triangles, et reconstruit une géométrie prête à être mise dans un glTF. Le format intermédiaire n’a que trois champs par primitive : positions, indices, nom optionnel. Rien de ce qui dépassait n’est porté.

glTF est un format en deux parties : un en-tête JSON qui décrit les accesseurs, les buffer views et les meshes, et un bloc binaire qui contient les données réelles. La version `.gltf` classique référence un fichier `.bin` séparé, ce qui pose un problème de distribution évident : envoyez le JSON sans le bin et rien ne charge.

Cette conversion écrit un `.gltf` qui embarque son buffer en data URI base64, donc un seul fichier contient tout. C’est la forme autonome du format, et c’est ce qui rend la sortie facile à envoyer, à charger dans une visionneuse, ou à passer à un pipeline sans se demander ce qu’il faut mettre à côté. C’est aussi légèrement plus gros qu’une paire .gltf+.bin parce que le base64 ajoute un tiers, et c’est le compromis connu du format.

Le module ne lit que les primitives en triangles. Les PLY qui contiennent des bandes, des éventails, des lignes, ou des points sont acceptés si la majorité de leur contenu est en triangles et ces autres primitives sont passées sans conversion. C’est ce qui fait que des maillages de recherche un peu anciens, qui ont parfois des quadrilatères mélangés à des triangles, se convertissent en général sans intervention.

Pour les polygones, la triangulation est faite en éventail : correct pour les faces convexes, faux pour les concaves. C’est documenté en clair dans le module, et c’est le comportement par défaut de toute triangulation en éventail. Pour un fichier qui contient des faces concaves, le maillage converti aura des triangles incorrects, et la correction se fait dans un outil de remaillage comme MeshLab ou Blender.

Un PLY peut porter un nuage de points sans aucune face. Le convertir en glTF en l’état demanderait de fabriquer des triangles là où il n’y en a pas, et c’est une reconstruction plutôt qu’une conversion. Le module le détecte et l’opération échoue avec un message en clair.

Si l’intention est de transformer le nuage en surface, c’est un autre outil : Poisson surface reconstruction, Ball Pivoting, Alpha Shapes. Le résultat est un maillage reconstruit à partir d’hypothèses sur la densité locale, et il n’est pas équivalent au fichier d’origine. Pour le transport du nuage tel quel dans une chaîne qui sait le lire, garder le PLY et le passer directement est la bonne réponse.

Si le PLY d’origine déclare des propriétés de couleur par sommet, le glTF portera une COLOR_0 par primitive, et la géométrie convertie arrive avec son apparence d’origine dans une visionneuse qui sait la rendre. C’est l’une des deux ou trois choses qu’un PLY peut porter au-delà de la géométrie et que ce pipeline accepte : couleur, et c’est à peu près tout.

Les normales, les UV, les poids de skinning, les clés d’animation ne sont pas lus. Si l’un de ces éléments compte pour l’utilisation, garder le PLY d’origine et l’exporter directement vers un glTF dans un outil qui les porte, comme Blender ou Houdini, est la seule façon de les préserver. Cette conversion déplace la géométrie d’un conteneur texte vers un conteneur JSON+binaire, et tout ce qui dépasse n’est pas transporté.

Chaque primitive du PLY peut être nommée, par mesh ou par groupe. Le glTF écrit déclare un mesh par primitive nommée du PLY, et un mesh par primitive anonyme reste anonyme. Un maillage composé de pièces distinctes arrive donc comme un glTF avec plusieurs meshes plutôt qu’un seul, et c’est ce qui permet à un viewer de les afficher séparément.

Cela compte plus que ça n’en a l’air. Dans un glTF, les noms sont à peu près la seule information sémantique qui survit d’une chaîne de conversion, et c’est ce qui permet à quelqu’un en bout de chaîne de réattribuer les matériaux aux bonnes pièces. Un PLY sans noms donne un glTF sans noms, et la distinction entre pièces est perdue ; nommer dans la source est presque toujours la bonne discipline.

glTF supporte une compression géométrique optionnelle appelée Draco, qui réduit la taille du buffer de manière spectaculaire pour des maillages denses. La conversion ne l’écrit pas, et elle refuse un PLY qui aurait été encodé en Draco en entrée. C’est documenté en clair dans le module et c’est une décision, pas un oubli : la compression ajoute une dépendance de décodage qui n’a pas lieu d’être dans une conversion qui vise la simplicité.

Pour des maillages légers, la différence est négligeable. Pour des scans lidar ou des scans 3D denses qui font quelques millions de triangles, elle compte. Le cas où Draco est la bonne réponse n’est pas le cas où cette conversion est la bonne réponse, et l’inverse est aussi vrai : envoyez le fichier vers un outil qui sait écrire Draco, et gardez cette conversion pour le transport et la visualisation.

Un .gltf avec un buffer embarqué s’ouvre dans Blender, three.js, Babylon.js, la Visionneuse 3D Windows, Aperçu macOS récent, et la plupart des visionneuses en ligne sans configuration. C’est l’inverse de la paire .gltf+.bin où chaque viewer doit retrouver le .bin à côté, et c’est précisément pour cela que la forme autonome a été préférée pour cette conversion.

Pour un usage en ligne, un `<model-viewer>` ou un three.js charge le fichier avec une seule requête HTTP et c’est terminé. Pour un envoi par messagerie, un destinataire double-clique et voit le maillage, ce qui est rarement le cas d’un .gltf qui a perdu son .bin. La portabilité de la forme autonome est ce qui justifie les 33 % de base64.

Aucune mise à l’échelle n’est appliquée. Les coordonnées du PLY sont écrites dans le glTF à la précision à laquelle JavaScript les imprime, et l’unité linéaire par défaut de glTF 2.0 est le mètre. Un maillage enregistré en millimètres dans le PLY arrive avec des coordonnées en millimètres dans le glTF, et c’est à l’application en aval de diviser par 1 000 ou de laisser la scène ajuster.

Pour un maillage de recherche, c’est souvent la cause de la scène vide. Une boîte englobante de 0,001 par 0,001 par 0,001 unité n’est pas un objet raté, c’est un objet qui est à l’échelle du micron dans une scène qui attend le mètre. Vérifiez la dimension de la boîte englobante dans la visionneuse et scalez explicitement si la valeur est aberrante.

Si la destination lit PLY, ne convertissez pas. MeshLab, CloudCompare, et la plupart des outils de recherche lisent PLY directement, et la conversion en glTF perd des champs que le PLY portait. Pour un maillage de recherche, pour un scan, pour un asset de simulation, le PLY est souvent plus riche que le glTF qu’on en tire.

Convertissez quand la destination ne sait pas lire PLY, quand le fichier doit être affiché dans un viewer web, ou quand le .gltf autonome est l’artefact à distribuer à des destinataires variés. La conversion est honnête sur ce qu’elle fait : elle transporte la géométrie et trois ou quatre attributs, et tout le reste est laissé au PLY d’origine.