Qu’est-ce qu’un fichier PLY ?

PLY est un format binaire, qui ne veut rien dire hors d’un programme qui le connaît. Il stocke des formes et des coordonnées plutôt que des pixels, donc il reste net à n’importe quelle taille — un logo porté à la taille d’une affiche ne perd rien. Il est utilisé pour la numérisation et l’échange entre programmes.

L’extension est .ply et le nom complet Polygon File Format. L’un et l’autre comptent moins que ce que le fichier peut contenir, et c’est le sujet du reste de cette page.

Stanford University l’a publié en 1994.

À un format resté lisible aussi longtemps, on peut confier quelque chose qu’on veut retrouver dans dix ans.

Elle est publiée intégralement : n’importe qui peut l’implémenter à partir du document plutôt qu’en l’observant, et c’est pourquoi ce format apparaît dans tant de programmes et pourquoi des fichiers écrits il y a vingt ans s’ouvrent encore. Une spécification publiée n’est pas pour autant libre de redevances : quand un format enveloppe un codec, les brevets sont une question à part, que la norme ne tranche pas.

PLY enregistre son contenu à l’identique. Le réenregistrer ne change rien : vous pouvez l’ouvrir, le modifier et le réenregistrer autant de fois que vous voulez sans accumuler de dégâts, et c’est ce qui en fait un format de travail plutôt qu’un format de livraison.

MeshLab, Blender et CloudCompare le lisent, comme la plupart des programmes du même genre.

Quand un fichier ne s’ouvre pas, le format est rarement en cause : le plus souvent, c’est le programme qui est plus ancien que lui. Convertir vers quelque chose de plus ancien est le contournement fiable, et c’est à cela que sert le reste de ce site.

Aucun navigateur ne le lit.

C’est de loin la raison la plus fréquente de le convertir : non pas que le format soit mauvais, mais que l’endroit où vous voulez montrer le fichier ne sache pas le lire.

PLY est fait pour être ouvert et modifié. Gardez le fichier dans ce format tant que le travail dure, et exportez depuis lui chaque fois qu’une version finie est nécessaire.

PLY a été écrit à Stanford au milieu des années 1990 pour des données de scanneurs à balayage, et c’est toujours ce qu’il contient surtout. Les logiciels de photogrammétrie, les scanneurs à main et à lumière structurée, les outils lidar et les modèles Stanford eux-mêmes le parlent, parce qu’il a été conçu exactement pour la chose maladroite que produisent les scanneurs  : des millions de points mesurés, chacun portant des propriétés que le scanneur a enregistrées.

La conception qui lui a permis de durer, c’est que les propriétés sont déclarées plutôt que fixées. L’en-tête énumère ce que porte chaque sommet — position, couleur, normale, confiance, intensité, n’importe quoi que mesure un instrument particulier — et les lecteurs prennent ce qu’ils comprennent. Un format de 1994 peut donc porter des données d’un instrument construit l’an dernier.

OBJ peint une surface avec une image de texture plaquée dessus. PLY fait normalement quelque chose de plus simple  : chaque sommet porte sa propre couleur, mesurée à ce point.

Pour un scan, c’est exactement ce qu’il faut, parce que le scanneur a mesuré la couleur par échantillon et qu’il n’y a pas de surface dépliée sur laquelle plaquer une image de toute façon. Cela veut aussi dire que la résolution de couleur est la résolution de la géométrie — un maillage grossier a une couleur grossière, et on ne peut ajouter du détail qu’en ajoutant des points. C’est le compromis vis-à-vis des textures, où un modèle à peu de polygones peut porter une image très détaillée.

Cela cause une réelle confusion. Un PLY peut être une liste de points sans aucune connexion — un nuage — ou un véritable maillage avec des faces qui les joignent. Les deux sont valides, les deux ont la même extension, et un programme attendant l’un fera quelque chose d’inutile avec l’autre.

Un nuage ouvert dans un programme qui attend un maillage apparaît comme une faible poussière de points ou comme rien du tout. Il n’est pas corrompu  ; il n’y a tout simplement aucune face à dessiner. Transformer un nuage en surface est une reconstruction — Poisson ou ball-pivoting dans MeshLab ou CloudCompare — et c’est une étape de traitement avec des paramètres à choisir, pas une conversion de format.

Comme pour STL, l’en-tête déclare quel encodage suit. L’ASCII est lisible et environ quatre fois plus gros  ; le binaire est ce que n’importe quel vrai scanneur écrit.

Même en binaire, ces fichiers sont gros, parce que les nombres le sont. Un scan par photogrammétrie au téléphone d’un objet produit couramment de deux à cinq millions de points, et un balayage lidar d’une pièce en produit des dizaines de millions. À environ quinze octets par point avec la couleur, un relevé de cent millions de points fait un gigaoctet et demi avant qu’une quelconque reconstruction ait eu lieu. C’est normal pour le format plutôt qu’un signe de mauvais export.

La sortie brute n’est jamais terminée. Il y a l’arrière-plan — la table, le sol, la pièce — qu’il faut recadrer. Il y a des valeurs aberrantes, des points parasites flottant là où le scanneur a mal jugé un reflet ou un bord. Il y a des trous là où l’instrument n’a pas pu voir, sous l’objet et derrière chaque porte-à-faux.

Puis la décimation, parce qu’un maillage de cinq millions de points est inutilisable dans tout ce qui est en aval, et le comblement des trous, et seulement alors un maillage qui vaut la peine d’être texturé ou imprimé. MeshLab et CloudCompare sont les outils libres pour tout cela. Le scanneur produit des mesures  ; transformer des mesures en modèle est un travail à part, et c’est le plus gros.

Convertir le PLY en STL est l’étape finale habituelle, et cela jette la couleur — le STL n’en a pas — tout en gardant la forme. C’est généralement acceptable, puisqu’une imprimante à un seul matériau n’aurait de toute façon pas pu utiliser la couleur.

L’échec à attendre, c’est l’étanchéité. Les scans sont truffés de trous par nature  : rien n’a été mesuré sous l’objet, et les détails manquent partout où l’instrument n’avait pas de ligne de vue. Un trancheur a besoin d’un solide non ambigu, donc les trous doivent être comblés et le maillage vérifié avant que le STL ne soit écrit. Sauter cette étape produit un fichier que le trancheur refuse ou, pire, un fichier qu’il accepte et interprète à sa manière.

Si le modèle va dans un moteur de jeu ou un visualiseur web, convertissez en glTF  : il porte les textures, les matériaux et une scène, et il est conçu pour la diffusion plutôt que pour la capture. S’il va dans un programme de modélisation pour être édité, OBJ est plus universellement accepté. S’il va à une imprimante, STL.

PLY gagne sa place à l’extrémité capture du pipeline, là où des propriétés par sommet et un en-tête extensible sont exactement ce qu’il faut. Gardez-le comme archive de ce qui a été réellement mesuré, et générez les formats de diffusion à partir de lui — l’inverse, reconstruire des mesures à partir d’un maillage décimé, n’est pas possible.