Convertire STL in PLY

Ogni altra coppia in questo insieme rinuncia a qualcosa. Il glTF perde i suoi materiali, l’OBJ perde il suo MTL, il 3MF perde il colore. STL in PLY perde le normali delle facce, e quelle vengono calcolate dall’ordine di avvolgimento da ogni lettore che ne ha bisogno e sono notoriamente sbagliate nei file prodotti da esportatori poco attenti.

Tutto il resto sopravvive perché non c’era altro. Un STL è una lista di triangoli senza colore, unità, nomi, parti o attributi. Un PLY scritto con x, y e z e una lista di facce contiene esattamente questo. I due formati concordano su cosa sia un modello, cosa rara in questa categoria.

CloudCompare, MeshLab, Open3D e trimesh accettano tutti il PLY come ingresso di prima classe, perché Stanford lo ha progettato nel 1994 esattamente per questo tipo di lavoro: un’intestazione autodescrittiva che elenca qualunque proprietà per vertice e per faccia serva a uno strumento di ricerca. La scansione e la fotogrammetria si sono standardizzate su di esso per lo stesso motivo.

Leggono anche l’STL, ed è lì che iniziano i problemi. Un STL si carica, si mostra e appare corretto pur essendo topologicamente inutile. Convertire non riguarda l’apertura del file; riguarda ottenere una mesh la cui connettività gli algoritmi possano usare con fiducia.

L’STL memorizza tre vertici indipendenti per ogni triangolo. Un cubo è trentasei record di vertice per otto posizioni. Caricatelo in uno strumento di mesh e chiedete se la superficie è chiusa e vi dirà che ogni singolo bordo è un bordo di confine, perché nessuna coppia di triangoli condivide un vertice — anche se la forma non ha buchi affatto.

La conversione arrotonda le coordinate a sei cifre decimali, le usa come chiave, e collassa ogni angolo alla stessa posizione in un unico vertice condiviso referenziato da tutti i suoi triangoli. Dopo, i controlli manifold, la stima delle normali, la curvatura, la decimazione, la levigatura e il riempimento dei buchi operano su adiacenza reale.

L’intestazione è quella conservativa: ply, format ascii 1.0, un commento che nomina lo scrittore, una dichiarazione element vertex con tre righe property float per x, y e z, una dichiarazione element face con una riga property list uchar int vertex_indices, e end_header. Poi una riga per vertice e una per triangolo.

Non viene dichiarato nient’altro — nessuna normale, colore, confidenza, qualità o proprietà personalizzata. È deliberato: un’intestazione che promette una proprietà che il file non può riempire è peggio di una breve, e ogni lettore che gestisce il PLY affatto gestisce questo dialetto.

Ogni record di triangolo da cinquanta byte in un STL binario inizia con dodici byte di normale della faccia. Quei dodici byte vengono saltati. L’informazione che contengono è completamente determinata dall’ordine dei tre vertici, quindi ricalcolarla è esatto piuttosto che approssimativo.

Non è una scorciatoia presa per comodità. Le normali STL memorizzate disaccordano con l’avvolgimento abbastanza spesso che diversi slicer e strumenti mesh le scartano per politica, proprio perché molti scrittori sbagliano il segno o la normalizzazione. Ricalcolare dall’avvolgimento dà una risposta coerente unica.

Ogni coordinata viene scritta come testo decimale, un vertice per riga, e ogni triangolo come un 3 iniziale seguito da tre indici. Un vertice che era dodici byte binari diventa venti-sessanta caratteri. Contro questo, la saldatura ha già rimosso circa cinque sesti dei record di vertice che portava l’STL.

I due effetti si compensano parzialmente e il risultato dipende dal modello. Ciò che è prevedibile è il lato STL: esattamente 84 + 50n byte per n triangoli, quindi una mesh da scansione di due milioni di triangoli è 100 MB prima della conversione e vale la pena decimarla prima.

La ragione più comune per cui avviene questa conversione è l’analisi di deviazione: una parte è stata stampata o lavorata da un STL, poi scansionata, e qualcuno ha bisogno della differenza. La distanza da nuvola a mesh di CloudCompare vuole il riferimento come mesh con facce, ciò che questo produce, e la scansione come punti.

Due aspetti pratici. I due set di dati devono essere allineati prima — una selezione grezza di coppie di punti seguita da ICP è la via standard — e devono condividere una scala, che nessuno dei due formati dichiara. Se la scansione è in millimetri e l’STL è stato esportato in pollici, l’allineamento convergerà su qualcosa di plausibile e sbagliato.

Il PLY è il formato in cui arrivano le scansioni 3D perché porta il colore per vertice, ed è ciò che fa sembrare una mesh fotogrammetrica l’oggetto da cui proviene. Niente di ciò appare qui, perché un STL non aveva colore da dare.

L’eccezione non ufficiale vale la pena nominarla: alcuni strumenti codificano un colore a quindici bit nei due byte attributo alla fine di ogni record di triangolo STL, in due convenzioni fra loro incompatibili. Quei byte non vengono letti. Non c’è modo di sapere quale convenzione abbia usato un file.

Se la destinazione è uno slicer o un servizio di stampa, non convertite — vogliono STL o 3MF, e il supporto PLY in quel mondo è irregolare. Se la destinazione è un visualizzatore da browser, il glTF è l’obiettivo giusto e il PLY è quello sbagliato.

Convertite quando il passo successivo è un algoritmo: un calcolo di distanza, una decimazione, un remesh, un riempimento di buchi, un volume o area di superficie, un allineamento contro dati scansionati. Tutto il valore del passaggio sta nella saldatura e nel formato che lo strumento si aspetta, e gira interamente nel vostro browser senza caricamento.