STL naar 3MF omzetten

3D Systems publiceerde STL in 1987 voor een machine die driehoeken aannam en niets anders, en het formaat is daar eerlijk over: geen eenheden, geen kleur, geen materialen, geen namen, geen onderdelen, geen gedeelde vertices, geen metadata. Alles wat de printwereld erna toevoegde — schaalconventies, platen met meerdere onderdelen, instellingen per object — leeft buiten het bestand en moet gereconstrueerd worden door wie het opent.

3MF, gepubliceerd in 2015, zette die dingen in het bestand. Eenheden worden vastgelegd, objecten staan apart, kleur en materialen hebben een plek, en het geheel is een OPC-pakket met een manifest in plaats van een ruwe bytestroom. Een STL omzetten geeft je meteen de verpakking en de eenheden. Het tovert geen kleur of onderdelen tevoorschijn die nooit vastgelegd waren, en geen converter kan dat.

STL slaat elke driehoek op als drie onafhankelijke vertices zonder enige indexering. Een kubus — twaalf driehoeken — komt aan als zesendertig vertex-records terwijl acht aparte posities zouden volstaan. Dat is geen eigenaardigheid van een bepaalde exporteur; het is het formaat.

De omzetting voegt ze samen: coördinaten worden afgerond op zes decimalen om een sleutel te vormen, en elke driehoekshoek op dezelfde positie klapt samen tot één gedeelde vertex. Zes decimalen zit ver onder elke printbare tolerantie en ver boven het laatste-bit-verschil dat twee aangrenzende driehoeken routinematig hebben in een float. Wat eruit komt is een echt geïndexeerd oppervlak, wat waarom een manifold-check op de 3MF een bruikbaar antwoord geeft waar dezelfde check op de STL elke rand als grens meldt.

De resources-sectie van de 3MF bevat één object en de build-sectie één item. Dat is geen vereenvoudiging — een STL heeft echt geen manier om te zeggen dat zijn driehoeken drie aparte lichamen vormen, dus is er niets om op te delen, en een verdeling verzinnen op basis van connectiviteit zou een modelleerbeslissing zijn en geen omzetting.

Bevat je STL wel meerdere losstaande schillen, dan heeft elke slicer een opdracht Split to Parts of Split to Objects die ze na import vindt op basis van connectiviteit. Dat daar doen is dezelfde bewerking met een voorbeeld erbij. Wil je de onderdelen in het bestand zelf vastgelegd hebben, dan moet de bron een formaat zijn dat ze had — een OBJ met groepen, of een glTF met meerdere meshes.

De 3MF wordt geschreven met unit="millimeter" in zijn model-element en de coördinaten gaan onaangeroerd door. Strikt genomen stelt de converter een eenheid vast die de bron nooit verklaarde. In de praktijk is dit het minst riskante geval van die vaststelling in de hele 3D-matrix, want de printwereld behandelt STL-getallen al dertig jaar als millimeters en elke slicer importeert ze zo.

De winst is dat de aanname geen aanname meer is. Een 3MF die millimeter zegt importeert op dezelfde grootte in PrusaSlicer, Cura, Bambu Studio en Microsoft 3D Builder zonder dat een van hen zijn eigen huisconventie toepast. Het enige geval om op te letten is een STL geëxporteerd uit CAD in inches, die al op 1/25e grootte zou importeren en dat nu doet met een eenhedenverklaring erbij.

Elk driehoeksrecord in een binaire STL eindigt met een veld van twee bytes dat de specificatie ongebruikt laat. Twee conventies groeiden in dat gat — één van VisCAM en SolidView, één van Materialise Magics — die een vijftienbits RGB-kleur per driehoek coderen. Geen van beide maakt deel uit van STL, en geen twee gereedschappen zijn het erover eens welke van de twee een gegeven bestand gebruikt.

De lezer hier neemt de twaalf bytes vlaknormaal en de zesendertig bytes vertexdata van elk vijftigbyterecord en raakt de laatste twee nooit aan. Een gekleurde STL zet dus stilletjes om naar een kleurloze 3MF. 3MF heeft een echt kleurmodel en zou het resultaat kunnen dragen; raden welke van twee incompatibele conventies een bitpatroon produceerde is geen gok die een converter namens jou zou moeten maken.

Op basis van rekenkunde, niet het beginwoord. De voor de hand liggende test — begint het bestand met "solid"? — is fout, want de kop van tachtig bytes van een binaire STL kan alles bevatten en meerdere schrijvers zetten "solid" erin. Bestanden die zo falen lijken te parseren en leveren niets op.

Een binaire STL is precies 84 + 50n bytes voor het driehoeksaantal in zijn kop: tachtig bytes kop, vier voor het aantal, dan vijftig per driehoek. Niets anders landt toevallig op dat getal. Klopt de lengte, dan wordt het bestand als binair gelezen; anders wordt de tekst gescand op vertexregels. Beide paden komen bij hetzelfde samengevoegde model uit.

De STL-kant is exact en makkelijk te checken: een model van 100.000 driehoeken is 5.000.084 bytes, altijd, wat de vorm ook is. Die voorspelbaarheid is het enige waar het formaat werkelijk goed in is, en het is ook waarom STL-bestanden zo veel groter zijn dan de geometrie erin rechtvaardigt — driekwart van die bytes zijn herhaalde coördinaten.

De 3MF slaat elke samengevoegde vertex eenmaal op als XML-element en elke driehoek als drie geheeltallige verwijzingen, en deflate-comprimeert daarna het geheel in het ZIP-pakket. Uitgebreide markup comprimeert uitstekend, en het samenvoegen van vertices heeft het meeste van de redundantie al weggehaald voordat de compressie begint. Het resultaat is modelafhankelijk, en voor typische printbare geometrie is het comfortabel kleiner dan de STL waar het uit kwam.

Drie items in een ZIP: [Content_Types].xml die de inhoudstypen voor .model en .rels verklaart, _rels/.rels met één relatie die naar het model wijst, en 3D/3dmodel.model met de geometrie in de 3MF-kernnaamruimte. Die structuur maakt het een OPC-pakket, dezelfde conventie die DOCX en XLSX gebruiken.

Het is een modelbestand en geen projectbestand. Er zijn geen printinstellingen, geen filamenttoewijzingen, geen platindeling en geen thumbnail, want dat zijn slicer-eigen uitbreidingen en geen onderdeel van de geometrie. Je slicer past het profiel toe dat je hebt geselecteerd en laat je daarna zijn eigen rijkere 3MF opslaan.

Gaten blijven gaten, omgeklapte driehoeken blijven omgeklapt, zelfoversnijdingen blijven, interne wanden blijven, en nul-oppervlaktesnippers blijven. Niets hier inspecteert de topologie verder dan samenvallende vertices samenvoegen, en een mesh die als STL een slicer-check faalde, faalt die als 3MF met dezelfde melding.

Wat wel verandert is de klasse fouten veroorzaakt door ongedeelde vertices, wat elke STL door constructie heeft. Na het samenvoegen is een oppervlak dat geometrisch gesloten is ook topologisch gesloten, dus reparatiegereedschap en manifold-checks in Blender, Meshmixer of je slicer werken op de mesh die je bedoelde in plaats van op zesendertigduizend losse driehoeken. Dat alleen al maakt een reparatiesessie korter.