Convertire STL in 3MF

3D Systems ha pubblicato l’STL nel 1987 per una macchina che accettava triangoli e nient’altro, e il formato è onesto su questo: nessuna unità, nessun colore, nessun materiale, nessun nome, nessuna parte, nessuna condivisione di vertici, nessun metadato. Tutto ciò che il mondo della stampa ha aggiunto dopo — convenzioni di scala, piani multi-parte, impostazioni per oggetto — vive fuori dal file e deve essere ricostruito da chi lo apre.

Il 3MF, pubblicato nel 2015, ha messo quelle cose dentro il file. Le unità sono dichiarate, gli oggetti sono separati, colore e materiali hanno un posto, e il tutto è un pacchetto OPC con un manifesto invece di un flusso di byte grezzo. Convertire un STL guadagna immediatamente il pacchettamento e le unità. Non conjura colore o parti che non erano mai state registrate.

L’STL memorizza ogni triangolo come tre vertici indipendenti senza alcuna indicizzazione. Un cubo — dodici triangoli — arriva come trentasei record di vertice dove basterebbero otto posizioni distinte. Non è una stranezza di un esportatore particolare; è il formato.

La conversione li salda: le coordinate vengono arrotondate a sei cifre decimali per formare una chiave, e ogni angolo di triangolo alla stessa posizione collassa in un unico vertice condiviso. Sei cifre sono molto sotto qualsiasi tolleranza stampabile e molto sopra il disaccordo sull’ultimo bit che due triangoli adiacenti hanno di routine in un float.

La sezione risorse del 3MF conterrà un singolo oggetto e la sezione build un singolo elemento. Non è una semplificazione — un STL non ha davvero modo di dire che i suoi triangoli formano tre corpi separati, quindi non c’è nulla su cui dividere, e inventare una divisione tramite analisi di connettività sarebbe una decisione di modellazione più che una conversione.

Se il vostro STL contiene diversi gusci scollegati, ogni slicer ha un comando Dividi in Parti che li trova tramite connettività dopo l’importazione. Farlo lì è la stessa operazione con un’anteprima allegata. Se volete le parti registrate nel file stesso, la sorgente deve essere un formato che le aveva già.

Il 3MF viene scritto con unit="millimeter" nel suo elemento modello e le coordinate passano invariate. In senso stretto, il convertitore afferma un’unità che la sorgente non ha mai dichiarato. In pratica è il caso meno pericoloso di questa affermazione in tutta la matrice 3D, perché il mondo della stampa tratta i numeri STL come millimetri da trent’anni.

Il guadagno è che l’assunzione smette di essere un’assunzione. Un 3MF che dice millimetro si importa alla stessa dimensione in PrusaSlicer, Cura, Bambu Studio e Microsoft 3D Builder senza che nessuno applichi una convenzione propria.

Ogni record di triangolo in un STL binario finisce con un campo attributo di due byte che la specifica lascia inutilizzato. Due convenzioni sono cresciute in quel vuoto — una da VisCAM e SolidView, una da Materialise Magics — codificando un colore RGB a quindici bit per triangolo. Nessuna delle due fa parte dell’STL, e due strumenti qualsiasi non concordano su quale un dato file usi.

Il lettore qui prende i dodici byte di normale della faccia e i trentasei byte di dati vertice da ogni record da cinquanta byte e non tocca mai gli ultimi due. Quindi un STL colorato converte in un 3MF senza colore, silenziosamente.

Per aritmetica, non per la parola iniziale. Il test ovvio — il file inizia con “solid”? — è sbagliato, perché l’intestazione di ottanta byte di un STL binario può contenere qualunque cosa e diversi scrittori ci mettono dentro “solid”. I file che falliscono in quel modo sembrano analizzarsi e non producono nulla.

Un STL binario è esattamente 84 + 50n byte per il conteggio di triangoli scritto nella sua intestazione: ottanta byte di intestazione, quattro per il conteggio, poi cinquanta per triangolo. Se la lunghezza corrisponde, il file viene letto come binario; altrimenti il testo viene scansionato per righe vertice.

Il lato STL è esatto e facile da controllare: un modello da 100.000 triangoli è 5.000.084 byte, sempre, qualunque sia la forma. Questa prevedibilità è l’unica cosa in cui il formato è genuinamente bravo, ed è anche perché i file STL sono così più grandi della geometria che contengono — tre quarti di quei byte sono coordinate ripetute.

Il 3MF memorizza ogni vertice saldato una volta come elemento XML e ogni triangolo come tre riferimenti interi, poi deflate-comprime il tutto dentro il pacchetto ZIP. Il markup prolisso comprime estremamente bene, e la condivisione dei vertici ha già rimosso gran parte della ridondanza prima che inizi la compressione.

Tre voci in uno ZIP: [Content_Types].xml che dichiara i tipi di contenuto per .model e .rels, _rels/.rels con una singola relazione che punta al modello, e 3D/3dmodel.model che contiene la geometria nel namespace core 3MF. Quella struttura è ciò che lo rende un pacchetto OPC, la stessa convenzione che usano DOCX e XLSX.

È un file modello piuttosto che un file progetto. Non ci sono impostazioni di stampa, assegnazioni filamento, disposizione piano o miniatura, perché quelle sono estensioni per slicer piuttosto che parte della geometria.

I buchi restano buchi, i triangoli invertiti restano invertiti, le auto-intersezioni restano, le pareti interne restano, e le schegge ad area zero restano. Niente qui ispeziona la topologia oltre unire i vertici coincidenti, e una mesh che ha fallito il controllo di uno slicer come STL lo fallirà come 3MF con lo stesso messaggio.

L’unica cosa che cambia è la classe di errore causata da vertici non condivisi, che è ogni STL per costruzione. Dopo la saldatura, una superficie geometricamente chiusa è anche topologicamente chiusa, quindi gli strumenti di riparazione in Blender, Meshmixer o il vostro slicer lavorano sulla mesh che intendevate.