Convertire GLB in PLY

La ragione per cui questa coppia esiste è una discrepanza tra distribuzione e processing. GLB ha vinto come modo per passare un modello: un file, niente sidecar, materiali imballati, visualizzabile in un browser con un singolo elemento. PLY ha vinto dentro il mondo del processing delle geometria decenni prima, e trimesh, Open3D, MeshLab, CloudCompare e PyTorch3D lo trattano tutti come il formato che non ha bisogno di spiegazioni.

Così una collezione arriva come GLB e la prima cosa che chiunque fa con essa è convertire. Ciò che conta a quel punto non è la fedeltà alla sorgente — nessuno renderizzerà queste — ma sapere esattamente cosa vedrà il loader: quanti vertici, se la superficie è un pezzo solo, e se il file sarà cinque megabyte o cinquanta.

PLY ha un blocco element vertex e un blocco element face. Non ha nozione di oggetto, gruppo o nome, quindi un GLB che contiene un corpo, un coperchio e un manico viene fuso: gli elenchi di vertici sono concatenati e gli indici delle facce di ciascun mesh sono spostati del numero di vertici già scritti.

La geometria è identica e la struttura è andata. L’analisi delle componenti connesse troverà ancora i tre pezzi — `trimesh.Mesh.split()` e Split in Connected Components di MeshLab funzionano entrambi sul risultato — ma i nomi non tornano, e due parti che si toccano ora sono regioni adiacenti di una superficie sola anziché due oggetti. Se l’identità delle parti conta per ciò che si sta facendo, OBJ è il formato qui che la mantiene.

L’header legge sempre `format ascii 1.0`. Non c’è opzione binaria e nessuna impostazione per cambiarla, quindi ogni coordinata è scritta come cifre decimali e ogni faccia come una riga che inizia con il numero 3. PLY è definito sia come testo sia come binario e questo convertitore scrive solo il primo, il che vale la pena saperlo perché i riassunti del formato — incluso quello di questo sito — descrivono PLY come formato binario.

In pratica questo significa che il file è diverse volte la dimensione dell’equivalente binario: una coordinata float32 occupa quattro byte compressi e circa dieci-quindici caratteri scritti. Tutti lo leggono, `head -20` mostra l’header, e un diff tra due export è significativo. Se serve la forma binaria, MeshLab e trimesh la scrivono entrambi, e un singolo re-save converte.

Alcune sorgenti su questo sito vengono saldate in ingresso — uno STL memorizza tre vertici indipendenti per triangolo e produrrebbe altrimenti un file quattro volte più grande del necessario. Un GLB non lo fa: la sua geometria è già un buffer di vertici indicizzato, quindi le posizioni e l’array di indici sono portati attraverso come sono.

Ciò significa che il conteggio dei vertici nel PLY corrisponde ai conteggi degli accessor nella sorgente, che è esattamente ciò che si vuole quando la conversione è un passaggio in una misurazione anziché una consegna. Significa anche che i duplicati contenuti nella sorgente sono ancora lì — una cucitura UV divide un vertice in due copie coincidenti in ogni esportatore glTF, e quelle copie arrivano nel PLY. Se un algoritmo a valle ha bisogno di un indice watertight, fondere con una tolleranza nella libreria anziché aspettarsi che il convertitore l’abbia fatto.

Nove righe e non di più: la parola magica, il formato, un commento generatore, l’element vertex con il suo conteggio e tre proprietà float, l’element face con il suo conteggio e un `property list uchar int vertex_indices`, e `end_header`. Leggere i due conteggi dalla cima del file è il censimento più veloce di triangoli e vertici disponibile, e non ha bisogno di alcuna libreria.

Ciò che l’header non dichiara è nient’altro. Nessuna proprietà di colore, nessuna normale, nessuna coordinata di texture, nessun commento che porti unità o provenienza, nessun elemento definito dall’utente. Un loader che legge questo file apprende la geometria e nulla su da dove viene, il che va bene per un passaggio di processing e male per un archivio — quindi conservare il GLB.

PLY è il formato a cui la gente ricorre precisamente perché contiene colore per vertice, ed è per questo che gli scanner lo scrivono. Un GLB ha spesso del colore da dare: un attributo di vertice `COLOR_0`, o più spesso una texture di colore base con coordinate UV. Nulla di ciò è letto, e lo scrittore emette solo x, y e z.

Quindi il risultato è geometria senza aspetto, e se l’aspetto è ciò che si stava per analizzare — confrontare scansioni, controllare una cattura, valutare una cottura di texture — questa è la strada sbagliata e la risposta è una libreria che legge entrambi gli attributi. `trimesh.load('model.glb')` restituisce sia il visivo sia il mesh ed esporta un PLY colorato direttamente. Per lavoro di pura geometria, nulla di tutto ciò importa e il file semplice è più piccolo.

Il convertitore cammina nel grafo di scena dalla scena di default, compone ciascuna matrice di nodo con il suo genitore, e applica il risultato prima di scrivere. Un GLB che collocava un mesh in quattro posizioni produce quindi quattro insiemi di vertici in quattro posti anziché un mesh e quattro matrici.

È il comportamento corretto, perché PLY non ha modo di esprimere un’istanza, ed è anche qualcosa da ricordare quando i numeri sembrano sbagliati. Una bounding box calcolata sul PLY copre l’intera scena assemblata, non il mesh sorgente, e un modello il cui autore ha lasciato la radice della scena traslata arriva lontano dall’origine. Entrambe sono proprietà del GLB anziché della conversione, ed entrambe sono un `mesh.apply_translation(-mesh.centroid)` via dall’essere risolte.

Né GLB né PLY porta un’unità. glTF è autorato per convenzione come se un’unità fosse un metro; PLY non fa alcuna affermazione, e gli strumenti di scansione che lo scrivono di solito lavorano in millimetri. Nulla nella conversione riconcilia quelle, e nulla potrebbe.

Per una pipeline di misurazione questo è un pericolo reale anziché una nota a piè di pagina, perché un volume calcolato su coordinate senza etichetta è un numero senza unità allegata. Stabilire il fattore una volta, da una dimensione che si può verificare nella sorgente, e registrarlo accanto al dataset. Se la collezione viene da un singolo generatore il fattore è di solito costante attraverso di essa, il che rende questo un lavoro di cinque minuti fatto una volta anziché una domanda per file.

Una cartella converte qui in un passaggio e torna come ZIP, che è un modo ragionevole per gestire decine di file e un modo povero per gestirne migliaia. Il tetto gratuito è 100 MB per file e il lavoro avviene in una scheda del browser, quindi una collezione grande è lenta e, cosa più importante, non ripetibile — nulla di tutto ciò è catturato in uno script.

Per qualunque cosa verrà eseguita due volte, `trimesh.load(path, force='mesh').export(out)` sono due righe e legge GLB nativamente, mantiene i colori di vertice se lo si chiede, e scrive PLY binario. Usare questa pagina per ciò in cui è brava: convertire tre file a mano per vedere come la geometria appare davvero prima di impegnarsi su come gli altri tremila saranno processati.

In questa scheda del browser. La conversione è puro JavaScript senza modulo WebAssembly da scaricare, nulla viene caricato, non c’è account e nessuna quota giornaliera, e la scheda di rete durante una conversione non mostra nulla uscire.

Questo vale la pena controllare anziché crederci, e importa per due ragioni che si sovrappongono qui: i dataset di ricerca arrivano spesso con termini di ridistribuzione, e un modello scannerizzato o catturato di un oggetto reale può essere una divulgazione di per sé. Nessuna delle due questioni si pone quando il file non si muove mai.