OBJ naar STL omzetten

Deze omzetting is bijna altijd verplicht in plaats van een voorkeur. Een online printdienst vermeldt `.stl` bij de geaccepteerde formaten. Een CAM-pakket importeert meshes en importeert er precies één soort. Een fabrikant van machines schreef zijn software rond STL en heeft dat nooit herzien.

Discussiëren is zelden mogelijk en zelden de moeite waard. Wat wel de moeite waard is: zeker weten dat de STL die je aanlevert de juiste is, want een STL vertelt niets over zichzelf — geen eenheden, geen onderdeelnamen, geen materiaal, geen herkomst — dus elke fout erin blijft stil tot iets op de verkeerde grootte wordt gemaakt.

Een OBJ komt vaak met een metgezel: een `.mtl`-bestand met materialen, en een map met textuurafbeeldingen waar de `.mtl` naar verwijst. Niets daarvan wordt gelezen, want er is nergens in een STL plaats voor een materiaal, een textuur, een UV-coördinaat of een kleur.

Het gevolg is duidelijk: een model gekocht om zijn uiterlijk komt eruit als een egaal grijze vaste vorm, en dat is geen tekortkoming van de omzetting maar de definitie van het doelformaat. Gaat het om kleur, dan is 3MF het printformaat dat dat wel draagt.

OBJ organiseert geometrie met `o`- en `g`-regels, en een model van enige complexiteit gebruikt die — een romp, een deksel, een handvat, elk benoemd. Een STL heeft één lijst driehoeken van begin tot eind en geen begrip van een object, dus alle groepen worden in die volgorde geschreven.

De schalen blijven geometrisch gescheiden en de identiteit is weg. PrusaSlicer en Cura detecteren losse schillen bij het laden en bieden aan ze te splitsen op het platform, wat de indeling terugbrengt maar niet de namen.

OBJ-vlakken mogen elk aantal hoeken hebben, en STL-driehoeken hebben er precies drie, dus elk veelhoek wordt gesplitst. De methode is een waaier: hoek één wordt verbonden met elk opeenvolgend paar, zodat een vierhoek twee driehoeken wordt en een zeshoek er vier.

Dat is precies goed voor een convex vlak en het enige punt waar deze omzetting geometrie kan produceren die fout is in plaats van slechts vereenvoudigd. Een concave veelhoek gewaaierd vanaf een hoek buiten zijn eigen binnenkant levert overlappende driehoeken op. Modelleerpakketten leveren vrijwel altijd convexe vlakken, dus dit is zeldzaam.

Geen van beide formaten legt een eenheid vast. OBJ heeft geen veld ervoor, en het ecosysteem eromheen heeft geen conventie — een mesh uit een scantool is vaak millimeters, een uit een architectuurpakket meters. STL is hetzelfde, behalve dat elke slicer het als millimeters interpreteert.

De getallen krijgen dus een betekenis die ze niet hadden. Dat is de duurste manier waarop deze omzetting misgaat, en de controle kost tien seconden: laad de STL in een slicer, lees het begrenzingsvak, en vergelijk met een afmeting die je kent.

OBJ-vlakindices zijn één-gebaseerd, en het formaat staat ook negatieve toe, die achterwaarts tellen vanaf de meest recente vertex. Sommige exporttools gebruiken die vorm consequent omdat dat bestanden samenvoegen triviaal maakt.

Beide vormen worden opgelost terwijl het bestand wordt gelezen, in volgorde, wat de enige manier is waarop het kan: een negatieve index hangt af van hoeveel vertices op dat punt al waren gedeclareerd.

De lezer versmelt samenvallende vertices binnen elke groep, vergeleken op zes decimalen. Dat telt voor andere doelformaten op deze site — een OBJ omgezet naar glTF of PLY behoudt de gedeelde vertices en is daardoor veel kleiner — en het is onzichtbaar in een STL.

STL kent helemaal geen gedeelde vertices: elke driehoek draagt zijn drie hoeken onafhankelijk, dus een hoek gebruikt door zes driehoeken wordt zes keer geschreven, wat de bron ook deed. Het bestand is daardoor exact 84 + 50n bytes voor n driehoeken.

Vier dingen, in deze volgorde, en steeds in een slicer die je zelf bestuurt. Het begrenzingsvak, tegen een afmeting die je kunt verifiëren. Het aantal objecten, voor het geval het model uit meerdere onderdelen bestond en je er één bedoelde te sturen. Het manifold-rapport — PrusaSlicer en Cura signaleren allebei open randen bij het laden. En de gesliceerde voorvertoning op een paar hoogtes.

Dat laatste vangt dingen die de rest mist: omgekeerde vlakken die een holte maken waar vast materiaal hoort, een waaierartefact van een concave veelhoek, een interne schil waar niemand van wist.

Ga je zelf printen, dan is 3MF de betere bestemming en elke huidige slicer accepteert het: het declareert expliciet millimeters, houdt elke groep als eigen object op het platform, en is een gecomprimeerd pakket in plaats van vijftig bytes per driehoek.

Wordt het model bewerkt in plaats van gemaakt, bewaar dan de OBJ — die heeft de groepen, de materiaalverwijzingen en een tekstvorm die je kunt inspecteren, en niets daarvan overleeft een reis via STL.

In dit browsertabblad, door gewone JavaScript. Er wordt geen WebAssembly-module opgehaald, niets wordt geüpload, er is geen account en geen daglimiet, en het netwerktabblad tijdens een omzetting bevestigt dat.

Het gratis plafond ligt op 100 MB voor de invoer, en let op dat de uitvoer groter kan zijn dan de invoer bij een dicht model — een OBJ bewaart elke vertex eenmalig en een STL herhaalt hem per driehoek.