STL, OBJ vagy 3MF: melyik 3D fájlformátumot válassza?

Az STL-t 1987-ben írták a 3D Systems első sztereolitográfiás gépeihez, és a felépítése ma is ezt tükrözi. A fájl háromszögek egyszerű listája, mindegyiket egy lapnormális és három csúcspont írja le. Nincs közös csúcstábla, így egy hat háromszöget érintő csúcs hatszor szerepel. Mértékegység-mező sincs: a 25-ös koordináta jelenthet milliméterot, hüvelyket vagy métert, és szinte minden szeletelő milliméternek feltételezi. A szín, a textúra és az alkatrésznevek nem férnek bele az alapformátumba, éppen ezért olvassa ma is minden szeletelő, CAD-program és nyomtatási szolgáltatás.

Az STL két kódolásban létezik. Az ASCII STL mindent szövegként ír ki, olyan sorokkal, mint facet normal, outer loop és vertex 12.5 0 3.2, így szövegszerkesztőben megnyitva olvashatók a számok. A bináris STL 80 bájtos fejléccel és 4 bájtos háromszögszámmal kezdődik, majd minden háromszöget tizenkét 4 bájtos lebegőpontos számként és egy 2 bájtos attribútummezőként tárol: háromszögenként pontosan 50 bájt. Ez a szabály megkönnyíti a méret előrejelzését. Egy egymillió háromszögű modell binárisan körülbelül 50 MB, ugyanennek a hálónak az ASCII változata jellemzően négy-hatszor nagyobb, mert minden számjegy egy karakter.

Az egyszerűség egyszerre erősség és csapda. Az STL nem árulja el, hogy egy vagy három alkatrésznek szánták-e, hüvelykben exportálták-e, vagy a háromszögei valóban zárt testet zárnak-e körül. Ezt a szeletelő a nyers koordinátákból találja ki, és ha téved, az alkatrész 25,4-szer kisebb lesz, vagy hiányzik egy fal. Egy általad tervezett, egyszínű, milliméterben exportált alkatrésznél ez mind mellékes, és az STL marad az a formátum, amelyet a legkisebb eséllyel utasítanak vissza.

Az OBJ a Wavefront Technologiestól származik, melynek Advanced Visualizer szoftvere az 1980-as évek végén használta, és az 1990-es években terjedt el egyszerű szöveges formátumként, amelyet szinte minden 3D-program cserélni tudott. Az STL-lel ellentétben csúcslistát tárol, és indexekből építi a lapokat, így egy közös csúcs egyszer szerepel, a lapok pedig háromszögek, négyszögek vagy nagyobb sokszögek lehetnek. A v kezdetű sorok a pozíciókat, a vt a textúrakoordinátákat (UV), a vn a normálvektorokat, az f a lapokat tartalmazza. A csoportok (g) és objektumok (o) elnevezik az alkatrészeket, így az OBJ szerkezete megmarad a Blenderen, Mayán vagy ZBrushon át oda-vissza vitt fájlokban is.

A megjelenés az .obj fájlon kívül van. Egy mtllib sor megnevez egy .mtl kísérőfájlt, a usemtl sorok pedig anyagokat rendelnek a lapokhoz. Az .mtl fájl olyan színeket tárol, mint a Kd (diffúz), és textúraképekre mutat, például map_Kd wood.png bejegyzéssel. A textúrázott OBJ tehát legalább három fájl: a geometria, az anyagkönyvtár és egy vagy több kép, mind relatív útvonallal hivatkozva. Ha csak az .obj fájlt küldöd el, a fogadó szürke modellt lát. Ez a szétválasztás hasznos játék- és VFX-munkafolyamatokban, ahol a grafikusok a geometria érintése nélkül cserélik a textúrákat, és ez a leggyakoribb oka annak, hogy egy letöltött modell rosszul néz ki.

Az OBJ a méretarányban osztozik az STL vakfoltjában: puszta számokat tárol mértékegység nélkül. A legtöbb modellezőprogram métert vagy centimétert ír, a szeletelők viszont milliméterként olvasnak, így egy játékasset-boltból származó OBJ 10- vagy 1000-szeres eltéréssel érkezhet. Nyomtatáshoz az OBJ nem ad olyat, amit a szeletelő használna, kivéve néhány eszköznél a csúcsonkénti színt, ezért ha grafikai assetet kell nyomtatni, általában a legegyszerűbb a textúrákat a rendereléshez megtartani, a szeletelőnek pedig tiszta hálót küldeni. Fordítva, az STL OBJ-vé alakítása a legrövidebb út a nyomtatási modelltől a renderelési vagy játékos munkafolyamatig.

A 3MF-et 2015-ben a 3MF Consortium tette közzé, amelyet a Microsoft indított el a nyomtatási és CAD-iparág cégeivel. A .3mf fájl ZIP-archívum, ugyanaz a tárolóformátum, amelyről a ZIP, RAR és 7z összehasonlításában írtunk. Ha .zip kiterjesztésűre nevezed át, egy 3D/3dmodel.model XML-fájlt találsz benne a hálóval, egy tartalomtípus-fájlt, kapcsolatfájlokat, gyakran bélyegképeket és szeletelő-konfigurációt. Minden modell megadja a mértékegységét (mikron, milliméter, centiméter, hüvelyk, láb vagy méter), így az STL-t és OBJ-t kísértő méretarányprobléma egyszerűen nem lép fel. A színek, az alapanyagok, több objektum és azok elhelyezése a tárgyasztalon mind a specifikáció részei.

A specifikáció azt is megköveteli, hogy a hálók zártak (manifold) és következetesen tájoltak legyenek: minden élen pontosan két háromszög osztozik, és mind kifelé néz. A szabályokat követő exportálók nem tudják kiírni azt a nyitott, önmetsző geometriát, amelyet az STL gond nélkül hordoz. A támogatás a mai eszközök között széles. A PrusaSlicer, a Bambu Studio, az OrcaSlicer és az UltiMaker Cura olvassa a 3MF-et, a PrusaSlicer és a Bambu Studio teljes projektjét .3mf fájlként menti nyomtatási beállításokkal és festett színekkel, a Microsoft 3D Builder alkalmazása pedig Windowson közvetlenül megnyitja. A gyenge pont a régebbi firmware, a nyomtatófarmok portáljai és a CAD-importálók, amelyek még STL-t várnak; ezekhez alakítsd át a 3MF-et STL-lé, és fogadd el, hogy a kiegészítők lemaradnak.

A megfelelő formátum attól függ, hová kerül tovább a fájl, nem attól, melyik az újabb. Ha a következő állomás egy szeletelő, és az alkatrész egyszínű, az STL megfelel, és még mindig ezt érti minden fórum, modelltár és nyomtatási szolgáltatás. Ha a következő állomás egy renderelő, egy játékmotor vagy más grafikus modellezője, az OBJ megtartja az UV-kat, normálvektorokat és elnevezett csoportokat, amelyeket az STL eldob, szöveges alakja pedig megkönnyíti a hibák vizsgálatát.

A 3MF akkor éri meg, ha a fájl többet hordoz geometriánál. A Bambu Studióban festett többszínű nyomtatás, egy munkára elrendezett tizenkét alkatrészes tálca, hüvelykben tervezett alkatrész vagy egy projekt, amelyet ugyanazzal a rétegmagassággal és kitöltéssel akarsz újra megnyitni, mind 3MF-et igényel, mert ezt az információt itt más formátum nem tudja tárolni. Több célhoz a leggazdagabb változatot tartsd törzspéldánynak, és abból exportáld az egyszerűbbeket egy 3D modell átalakítóval ahelyett, hogy átalakításokat láncolnál.

A formátumnak tulajdonított meghiúsult nyomtatások és hibás importok többsége valójában a háló hibája, vagy abból ered, amit a fogadó program feltételezett róla. Az STL a legkitettebb, mert nem hordoz metaadatot a hibák elkapására; az OBJ-nál is gond a méretarány és a hiányzó fájlok; a 3MF a felépítése miatt a legtöbbet elkerüli, bár egy hanyag exportáló is írhat hibás hálót. Nyisd ki az alábbi sorokat, hogy lásd, milyenek az egyes hibák, és honnan erednek általában.

A méret a szerkezetből következik. A bináris STL háromszögenként fix 50 bájt, így exportálás előtt kiszámolható. Az ASCII STL minden csúcsot szövegként ismétel, és általában négy-hatszor nagyobb a binárisnál. Az OBJ minden közös csúcsot egyszer tárol, és indexszel hivatkozik rá, így egy tipikus zárt hálónál kisebb az ASCII STL-nél és nagyjából a bináris STL tartományában van, nagyobb, ha UV-kat és normálvektorokat is hordoz. A 3MF indexelt XML-t tárol, majd a ZIP-ben tömöríti, ezért ugyanazon geometriára általában a három közül ez a legkisebb.

Az alábbi értékek egy körülbelül 500 000 háromszögű zárt háló, például egy részletes figura jellemző adatai. A valódi fájlok a koordináták pontosságától és az exportálótól függően eltérnek, ezért tekintsd őket nagyságrendeknek, amelyek akkor hasznosak, ha egy nyomtatási szolgáltatás korlátozza a feltöltést, vagy a 3MF-ből exportált STL többszörösen nagyobb lesz.

Az átalakítás kiolvassa a háromszögeket az egyik tárolóból, és beírja egy másikba. Ami a célformátumban kifejezhető, átjön; ami nem, elvész. Ezért veszteségmentes a geometria szempontjából az STL–OBJ átalakítás, a 3MF–STL elveszíti a színeket, mértékegységeket és a tálca elrendezését, az OBJ–STL pedig a textúrákat és az alkatrésznevek. Az UltKit 3D-eszközeiben a további döntések egyértelműek: a Modell mértékegysége megmondja az átalakítónak, milyen méretarányt használ a forrás, a Függőleges tengely kezeli a játékmotorok és szeletelők közti Y-felfelé és Z-felfelé különbséget, az Egyesítés egy hálóvá pedig eldönti, hogy az önálló alkatrészek különállók maradnak-e.

Amit semmilyen átalakítás nem tesz, az a háló javítása. Ha egy STL-ben lyuk van, az abból készült OBJ-ban is ugyanaz a lyuk lesz, a 3MF-exportáló pedig vagy elutasítja, vagy ugyanúgy kiírja. A javítás külön lépés egy hálószerkesztőben vagy a szeletelő beépített javítójában, és érdemes egyszer, a törzsfájlban elvégezni, mielőtt bármi mást exportálsz. Ugyanez igaz a méretarányra: az átalakítás nem tudhatja, hogy egy alkatrész hüvelykben készült, hacsak nem mondod meg neki. A részletesség is így működik: az alacsony sokszögszámú STL alacsony sokszögszámú OBJ vagy 3MF lesz, ezért ha számít a minőség, exportálj újra a forrásmodellből.

Két másik formátum is előkerül, valahányszor ez a kérdés felmerül. A STEP (ISO 10303) háromszögek helyett pontos testeket és felületeket tárol, ezért ez a megfelelő formátum, ha az alkatrészt szerkesztésre vissza kell vinni a Fusion 360-ba, a SolidWorksbe vagy a FreeCAD-be. A GLB, a Khronos Group glTF 2.0 bináris alakja, egy fájlba csomagolja a hálót az anyagaival és textúráival méterben, és ez a formátum modell webes vagy Android AR-os bemutatására.

A cikkben tárgyalt három formátumra az alábbi táblázat célok szerint összegzi a választást. Ha két sor is illik, válaszd azt a formátumot, amely több információt hordoz, és az egyszerűbbet exportáld később; a 3MF-ből STL-be menni könnyű, az elveszett színek vagy mértékegységek pótlása viszont kézi munka.