Convertire GLTF in PLY

PLY è uscito da Stanford nel 1994 esattamente per questo scopo: un mesh con un insieme arbitrario auto-descrittivo di proprietà per vertice e per faccia, in un header che un programma può leggere senza sapere nulla in anticipo. Quel design è il motivo per cui è diventato la valuta abituale della scansione, della fotogrammetria e del lavoro di geometria accademica, e perché CloudCompare, MeshLab, Open3D e trimesh lo trattano tutti come input di prima classe.

glTF è stato progettato per l’estremo opposto della pipeline — spedire un asset finito a un renderer su una rete. I suoi punti di forza sono le cose che uno strumento di misurazione ignora: definizioni di materiale, impacchettamento di texture, animazione, meccanismi di estensione. Diversi di quegli strumenti non hanno un importatore glTF affatto, e quelli che ce l’hanno lo trattano come un ripensamento. Convertire di solito è più veloce che lottare con questo.

È deliberatamente minimale: la parola magica ply, poi format ascii 1.0, un commento che nomina lo scrittore, una dichiarazione element vertex con il suo conteggio, tre righe property float per x, y e z, una dichiarazione element face con il suo conteggio, una riga property list uchar int vertex_indices, e end_header.

Questo è il dialetto PLY più ampiamente supportato che esista. Un conteggio di facce uchar con indici int è ciò che quasi ogni lettore presume quando prende scorciatoie, e posizioni float anziché double tengono il file a metà della dimensione per una precisione di cui nessun mesh qui ha bisogno. Se si sta scrivendo un parser contro questo output, quelle sette dichiarazioni sono l’intero contratto.

Ogni coordinata è scritta come testo decimale, un vertice per riga e un triangolo per riga. Un vertice che occupava dodici byte nel buffer glTF ne occupa da venti a sessanta qui, quindi aspettarsi che il PLY sia diverse volte la dimensione della geometria da cui è venuto. Un modello da due milioni di triangoli è un file di testo grande.

La compensazione è che nulla in esso è ambiguo. Il PLY binario arriva in varianti little-endian e big-endian con layout di proprietà che un lettore deve ricostruire dall’header, e assunzioni disallineate lì producono mesh che caricano come rumore. L’ASCII non può fallire in quel modo, e per un file che andrà in uno strumento di analisi una volta, la dimensione raramente importa più della certezza.

Un file PLY contiene un element vertex e un element face. Non c’è gruppo, oggetto o parte. Il convertitore quindi fonde ogni mesh letto dalla scena glTF in un singolo elenco, spostando gli indici di ciascun mesh del numero di vertici già scritti così che i triangoli puntino ancora ai posti giusti.

La geometria è invariata e la struttura è andata. Un glTF assemblato da dodici parti nominate diventa una superficie di dodici gusci disconnessi, e i nomi vanno con la struttura. Se quelle divisioni sono ciò che serve a valle, OBJ è il bersaglio che le mantiene, e convertire in OBJ invece non costa nient’altro che PLY avrebbe fornito.

La ragione più citata per usare PLY è che contiene rosso, verde e blu per vertice, ed è così che una scansione fotogrammetrica porta il suo aspetto senza una texture. Il formato lo supporta e i lettori se lo aspettano.

Questo convertitore non ne scrive. Il colore in un glTF vive nei materiali e nelle texture indicizzate dalle coordinate UV, e nessuno di quelli è letto; non c’è attributo di colore di vertice da portare attraverso a meno che la sorgente non ne abbia dichiarato uno, e anche quell’attributo non è letto. L’output è una superficie senza colore, il che è corretto per la misurazione e sbagliato se ciò che si voleva era un export che preserva l’aspetto.

La scena è camminata dalla sua scena di default, ciascuna matrice di nodo moltiplicata per il suo genitore, e la matrice mondo applicata ai vertici. I nodi autorati con traslazione, rotazione e scala separate sono composti in una matrice prima, seguendo la convenzione a quaternioni che glTF definisce.

Fare questo prima della fusione è ciò che rende la fusione sicura. Se le trasformazioni fossero lasciate non applicate, appiattire diversi mesh in un elenco impilerebbe ogni parte all’origine e produrrebbe una forma che non ha relazione con il modello. Cuocere prima significa che i numeri che si misurano in CloudCompare sono i numeri che la scena glTF descriveva.

Un buffer di indici, portato attraverso verbatim. glTF memorizza i triangoli come indici in un array di posizioni condiviso, e la conversione preserva quella struttura elemento per elemento anziché ricostruirla — nessuna fusione è applicata su questo percorso, perché non c’è nulla da riparare. Uno STL che arriva alla stessa destinazione deve essere saldato prima, dato che memorizza tre vertici non condivisi per ogni triangolo per design.

Quella distinzione decide se l’analisi che si sta per eseguire abbia senso. I controlli di manifold, la stima delle normali, la curvatura, la distanza geodetica, lo smussamento Laplaciano e la decimazione assumono tutti connettività. L’unica avvertenza che vale la pena portare in MeshLab è che gli esportatori dividono i vertici alle cuciture UV e normali, e quei duplicati sopravvivono qui come voci separate a coordinate identiche, quindi un passaggio di Merge Close Vertices prima di un controllo topologico è un’abitudine sensata.

Un .gltf che tiene la sua geometria in un .bin separato non può essere letto, perché un convertitore a file singolo non vede mai il secondo file; il messaggio lo dice e suggerisce il .glb, che ha tutto in un posto. Un file che usa KHR_draco_mesh_compression si ferma con un messaggio che nomina Draco, il cui decoder non è distribuito qui.

Le primitive che non sono liste di triangoli sono saltate. La modalità 4 di glTF è triangoli; strip, fan, linee e punti non sono superfici che questo convertitore possa trasformare in facce, e un file che contiene solo quelli riporta che nessuna geometria a triangoli è stata trovata anziché produrre un PLY vuoto che fallisce silenziosamente nell’analisi due passi dopo.

Se si sta per guardare il modello anziché misurarlo, PLY è una destinazione povera: nessun materiale, nessuna texture, nessuna struttura, e un file molto più grande. Tenere il glTF, o convertire in OBJ se il visualizzatore è vecchio.

PLY si guadagna il suo posto quando il passaggio successivo è un algoritmo di geometria — decimazione, remeshing, riempimento di buchi, allineamento contro una scansione, una misurazione di volume o area di superficie, una distanza di Hausdorff tra due versioni della stessa parte. Per quel lavoro la piattezza e l’assenza di colore sono irrilevanti, e avere il mesh nel formato attorno a cui lo strumento è stato scritto vale più di qualsiasi cosa la conversione scarti.