Che cos’è un file PLY?

PLY è un formato binario, che ha senso solo per un programma che lo conosce. Conserva forme e coordinate invece che pixel, quindi resta nitido a qualsiasi dimensione: un logo portato alla misura di un cartellone non perde nulla. Si usa per la scansione e spostare dati fra programmi.

L’estensione è .ply e il nome per esteso è Polygon File Format. Contano entrambi meno di ciò che il file può contenere, ed è di questo che parla il resto della pagina.

Stanford University lo ha pubblicato nel 1994.

A un formato rimasto leggibile così a lungo si può affidare qualcosa che vuoi ritrovare fra dieci anni.

È pubblicata per intero, quindi la si può implementare partendo dal documento invece che per osservazione: è per questo che il formato compare in così tanti programmi, ed è per questo che file scritti vent’anni fa si aprono ancora. Una specifica pubblicata però non è la stessa cosa di una esente da royalty: dove un formato incapsula un codec, le licenze sui brevetti restano una questione a parte che lo standard non risolve.

PLY conserva il suo contenuto esattamente. Risalvarlo non cambia nulla, quindi puoi aprirlo, modificarlo e risalvarlo quante volte vuoi senza accumulare danni: è questo che ne fa un formato di lavoro e non di consegna.

MeshLab, Blender e CloudCompare lo leggono, e così fanno quasi tutti i programmi dello stesso tipo.

Quando un file non si apre, il formato è raramente il problema: più spesso è il programma a essere più vecchio di lui. Convertire in qualcosa di più vecchio è la via d’uscita affidabile, ed è a questo che serve il resto di questo sito.

Nessun browser lo legge.

È di gran lunga il motivo più comune per convertirlo: non che il formato sia scadente, ma che il posto in cui vuoi mostrare il file non sappia leggerlo.

PLY è pensato per essere aperto e modificato. Tieni il file in questo formato per tutto il tempo in cui il lavoro va avanti, ed esporta da lì ogni volta che serve una copia finita.

Il PLY è stato scritto a Stanford a metà degli anni Novanta per dati di scanner a distanza, ed è ancora quasi sempre ciò che contiene. I programmi di fotogrammetria, gli scanner portatili e a luce strutturata, gli strumenti lidar e gli stessi modelli di Stanford lo parlano, perché è stato progettato proprio per la scomodità che questi apparecchi producono: milioni di punti misurati, ciascuno con le proprietà registrate dallo strumento.

Ciò che gli ha dato tanta vita è che le proprietà si dichiarano invece che essere fisse. L’intestazione elenca cosa porta ciascun vertice — posizione, colore, normale, confidenza, intensità, qualunque cosa quell’apparecchio misuri — e ogni lettore prende quello che capisce. Ecco perché un formato del 1994 può trasportare i dati di uno strumento fabbricato l’anno scorso.

L’OBJ colora una superficie proiettandovi sopra un’immagine di texture. Il PLY di solito fa qualcosa di più semplice: ogni vertice porta il proprio colore, misurato in quel punto.

Per una scansione questo è esattamente corretto, perché lo strumento ha misurato il colore campione per campione e comunque non c’è una superficie stesa su cui appoggiare un’immagine. Significa anche che la risoluzione del colore è quella della geometria: una mesh rada ha colore rado, e si guadagna dettaglio solo aggiungendo punti. È lo scambio rispetto alle texture, dove un modello a pochi poligoni può portare un’immagine molto dettagliata.

Questo genera confusione vera. Un PLY può essere un elenco di punti senza alcuna connessione fra loro — una nuvola — oppure una mesh vera e propria con facce che li uniscono. Entrambi sono validi, entrambi portano la stessa estensione, e un programma che si aspetta l’uno farà qualcosa di poco utile con l’altro.

Una nuvola aperta in un programma che vuole mesh appare come un tenue pulviscolo di punti o addirittura come niente. Non è corrotta: semplicemente non ci sono facce da disegnare. Convertire una nuvola in superficie è ricostruzione — Poisson o pivoting ball in MeshLab o CloudCompare — ed è un passaggio di elaborazione con parametri da scegliere, non un cambio di formato.

Come nell’STL, l’intestazione dichiara quale delle due codifiche segue. La versione ASCII si legge con un editor di testo e occupa circa quattro volte di più; quella binaria è ciò che scrive qualsiasi scanner reale.

Anche in binario questi file sono grandi, perché i numeri lo sono. Una scansione fotogrammetrica fatta con lo smartphone produce senza sforzo da due a cinque milioni di punti, e una scansione lidar di una stanza arriva a decine di milioni. A circa quindici byte per punto con colore, un rilievo di cento milioni di punti occupa un gigabyte e mezzo prima ancora di aver ricostruito nulla. È normale per questo formato e non un sintomo di esportazione errata.

L’output grezzo non è mai finito. C’è sfondo — il tavolo, il pavimento, la stanza — da ritagliare. Ci sono valori anomali, punti isolati fluttuanti dove lo strumento si è confuso con un riflesso o un bordo. E ci sono buchi dove lo strumento non è riuscito a vedere: sotto l’oggetto e dietro ogni sporgenza.

Poi viene la decimazione, perché una mesh da cinque milioni di punti è ingestibile in qualsiasi passaggio successivo, quindi il riempimento dei buchi, e solo allora c’è una mesh che vale la pena texturizzare o stampare. MeshLab e CloudCompare sono gli strumenti gratuiti per tutto questo. Lo scanner consegna misurazioni; trasformare misurazioni in modello è un altro lavoro, e il più lungo dei due.

Passare da PLY a STL è l’ultimo passaggio abituale, e scarta il colore — l’STL non ne ha — conservando la forma. Di solito è accettabile, perché una stampante monomateriale non avrebbe comunque potuto usare quel colore.

Il difetto da aspettarsi è la tenuta stagna. Le scansioni sono piene di buchi per natura: nessuno ha misurato sotto l’oggetto e manca dettaglio dove non c’era linea di vista. Uno slicer ha bisogno di un solido senza ambiguità, quindi i buchi vanno tappati e la mesh va rivista prima di scrivere l’STL. Saltare questo passaggio produce un file che lo slicer rifiuta o, peggio, uno che accetta e interpreta a modo suo.

Se il modello va in un motore di videogiochi o in un visualizzatore web, glTF: porta texture, materiali e una scena, ed è pensato per la consegna piuttosto che per la cattura. Se va in un programma di modellazione per continuare a lavorarci, l’OBJ è accettato in più posti. Se va su una stampante, l’STL.

Il PLY si guadagna il suo posto all’estremità della cattura, dove avere proprietà per vertice e un’intestazione estensibile è esattamente ciò che serve. Conservatelo come registro di ciò che è stato realmente misurato e generate da esso i formati di consegna: il percorso inverso, ricostruire misurazioni da una mesh decimata, non esiste.

Solo geometria. Ciò che passa sono i triangoli e dove stanno; non passano materiali, texture, coordinate UV, normali, colori per vertice, telecamere, luci, animazione o la gerarchia della scena. Un modello posizionato più volte in una scena torna con ogni copia cotta nella propria posizione, perché le trasformazioni dei nodi vengono applicate ai vertici. Tutto avviene nel browser, con un tetto di 100 MB per file.

Tre dettagli concreti, perché sono quelli che sorprendono. Quando la destinazione è PLY, la scrittura è sempre in ASCII. Sia in PLY sia in STL, tutte le mesh del modello vengono fuse in una sola e i nomi si perdono. E una nuvola di punti viene rifiutata invece che convertita: trasformare punti in superficie è ricostruzione, con parametri che qualcuno deve decidere, e farlo in silenzio significherebbe inventare una risposta.