A jó hír, hogy bár nehéz a kérdéskör, de nem emészthetetlen. Igyekszem majd érthetően leírni, hogy ki kivel és mi mivel van.
A formátumok első lépése a 3D tervező alkalmazások objektum formátumai. Ha eltekintek a lithophane vagy térkép generálástól, akkor itt lehet kezdeni a sort.(Azért tekintek el most a 2D szürkeárnyalatos képekből generált térbeli tárgyaktól, mert annak is szentelek majd egy teljes bejegyzést később, mert izgalmas téma)
Aztán jönnek a 3D szeletelők által befogadható objektum formátumok.
Ez után még pár szó lesz a 3D szeletelők saját formátumáról.
Majd a sor végén a nyomtatók számára is emészthető puszta leírónyelvet használó formátum, ami a CNC vezérlés nyelvezetéből lett összerakva, vagyis inkább abból lett átalakítva, ráformálva a 3D nyomtatásra.
Részben már írtam ezekről, de most kicsit belenézünk jobban a téma feneketlen kútjának alja felé.
Amit a 3D tárgyakról mindenképp tudni kell
A mai tudásunk szerint a 3 dimenzióban egy felületet 3 pont által térben meghatározott terület adhat. Ennél kevesebből nehéz felületet csinálni. Több ponttal lehet.
De mi most csak a hárompontos úgynevezett poligonokkal fogunk foglalkozni. Ha bármit megtervezünk 3D-ben, akkor annak a legjobban lebutított változata a poligonokká alakított tárgy lesz. Amikor valamit CNC-vel vagy épp 3D nyomtatóval farigcsálnak, akkor annak az alapja a szépen megtervezett objektumból legyártott poligonos test.
 |
| Tervezés alatt, az alkalmazás nem a poligonokkal rajzol |
 |
| Amikor STL-be akarjuk menteni, akkor már ez lesz a végeredmény. |
 |
| Minden poligon normálvektora kifele mutat, vagyis nekünk megfelelően áll. |
 |
| Pár normált megfordítottam, így látható, hogy belelátunk az objektumba. Természetesen belülről látható, hogy a felület belülre mutat, mert meg van fordítva és a normálvektor befele mutat. |
Ezeket a normálokat lehet állítgati.
 |
| A normálok a poligonok közepén lévő szaggatott vonalak. Az irányuk jól látható. |
 |
| Amikor megfordítjuk őket, akkor már befele néznek, a vonalak ezt mutatják. |
A legtöbb program automatikusan egy algoritmus mentén ellenőrizve megteszi nekünk kérdés nélkül, hogy ne szembesüljünk a problémával, amikor nem ezzel akarunk foglalkozni.
A lent ismertetett formátumokkal ez úgy van kapcsolatban, hogy bár a tervezőprogramokban ívekkel dolgozunk, amikor azt STL formátumba mentjük, az alkalmazás le fogja butítani nekünk poligonokra. Itt még annyit kell tudni, hogy a lebutításnak vannak paraméterei. Vagyis meg lehet mondani, hogy mennyire legyen finom a felület, amit legenerál poligonokból az alkalmazás. A poligonszám növelésével lehet elérni finomabb felületeket, ami ugye szebb nyomtatási képet is ad.
 |
| A programokkal szépen lehet állítgatni a poligonok számával a felület minőségét. Balra a képen a lowpoly, jobbra pedig egy hipoly konverzió látható. |
3D CAD formátumok
Van a világban egy pár formátum, ami arra született, hogy bizonyos átjárhatóságot biztosítson az alkalmazások között. De minden alkalmazásnak, amivel 3D objektumot lehet létrehozni, általában van saját formátuma. Ezek a formátumok mindig a program belső tárolási logikájához igazodnak. Hogy erről miért kell tudni valamit is. Azért mert a formátumok kiterjesztéséből lehet következtetni az alkalmazásra amivel készítették. Vagy épp arra, hogy konvertálva lett-e az eredeti állomány. Sok esetben a konverziónál adatokat veszítünk, mert a célformátum nem biztos, hogy minden tulajdonságot át tud venni a forrás formátumtól. Ilyen például a lent ismertetésre kerülő STL is, ami nem tud olyan okosságokat tárolni mint egy 3DS vagy egy FBX állomány. A 3D formátumok sok esetben textúrákat, vagyis a felületet befedő rajzolatokat is tud tárolni, vagy az azokhoz létrehozott koordinátákat amit UV mappingnak hívnak manapság. Ez olyan nyomtatásoknál fontos, ahol több színnel, vagy teljesen színesben nyomtatják a rétegeket. Minden esetben a szeletelő programunk által preferált formátumokat részesítjük előnybe, és érdemes beszerezni olyan alkalmazást amivel átjárhatóvá tudjuk tenni a kreációinkat. Jó hír, hogy sok esetben ezzel már érdemben nem kell annyit foglalkozni, mivel a legtöbb 3D tervező programból lehet egyenesen menteni olyan formátumokat, amik a szeletelőnek azonnal megfelelnek. A 3D alkalmazások használatakor, érdemes mindig az adott alkalmazás saját formátumában is elmenteni a kész objektumunkat, hogy ha visszamenőleg módosítani kellene rajta, akkor azt bármikor megtehessük. Az általam nagyon kedvelt Fusion 360 egy tervezési idővonalat is használ, amivel bármikor visszaléphetünk egy tervezési fázishoz, és az ott végrehajtott módosításokat a program alkalmazza a később végrehajtott módosításokra is. Vagyis, ha tervezünk egy dobozt, aminek a falvastagsága 2mm és rájövünk a dobozterv végén, hogy ez bizony vékony vagy épp vastag, akkor a falvastagság meghatározásához vissza tudunk térni, és átírva az értékét, a program módosít minden utána következő feladatot ami ezzel kapcsolatban volt, és természetesen módosítható. Ezért érdemes követni a tervezési konvenciókat, hogy a tervünk már az elejétől ilyen módon befolyásolható maradjon. Ez a lehetőség főleg a CAD alkalmazások sajátja, így egy 3DS MAX-ban erre kevésbé van lehetőség. De mi ugye CAD-et használunk majd főleg.Szóval az alkalmazások kiválasztásánál fontos szempont kell legyen, hogy milyen általános formátumokat ismer, amit az általunk választott szeletelő is preferál. Minden más formátum arra való, hogy az eredeti objektumunkat tároljuk benne. Mivel ezekből rengeteg van, így nem állok neki kifejteni az összeset. Annyit nem árt tudni, hogy sok formátumnak két változata van. Egy bináris és egy szöveges, pont azért, hogy ha mégis a szövegszerkesztővel szeretnénk benne turkálni, mert annyira vágjuk a formátumot, akkor azt minden kötöttség nélkül megtehessük. Ilyen ok lehet az, hogy a textúrát ki akarjuk cserélni az objektumon, de mást nem akarunk változtatni rajta. Ha a formátum mondjuk XML akkor ezt minden gond nélkül megtehetjük egy szövegszerkesztővel. Ez néha nagy segítség.
Itt egy példa az COLLADA formátumban tárolt textúra elérési útvonaláról.
<library_images>
<image id="test" name="test">
<init_from>file:///F:/Temp/test.jpg</init_from>
</image>
</library_images>
Jól látható, hogy bármikor át tudjuk írni a kép nevét, miután már becsuktuk a szerkesztőt, ha épp másik képre akarnánk cserélni a meglévő textúrát. Tudom ez nagyon haladónak tűnik, de ideje megbarátkozni azzal, hogy az ilyen pici hack-ek jól jöhetnek esetenként.
3D slicerek által ismert/használt formátumok
Na ez nekünk a legfontosabb. Mert a megfelelően megválasztott formátum sokat segít a szeletelő alkalmazásba történő betöltésbe.A szeletelők és a 3D nyomtatós körökben az alap az STL formátum, amiről már írtam. De van egy másik preferált formátum is a 3MF, ami az STL-hez hasonlóan tudja a koordinátákat tárolni és hozzá matériákat és színeket is, ami a többfejes vagy színes nyomtatások alkalmával elengedhetetlen információ. De ott van a szintén nagyon sok helyen használt PLY formátum, ami nem más mint egy túlfejlesztett STL, mert ez a formátum is tudja a matériákat, textúrákat tárolni UV térképezéssel. Sokat lehet ezzel is találkozni.
Legtöbbször ezek a formátumok szöveges vagy XML formátumban hordozzák az adatokat. Ami azért jó mert olvasható és szerkeszthető a kis kezünkkel, mint fent már taglaltam. Igen, XML(ő is szöveges, csak van szép neve). Tudom, sokat hallottunk az elmúlt 20 évben ezt a három betűt, de sokszor nem tudjuk pontosan mit is jelent. Rémesen egyszerű, az XML szép neve eXtensible Markup Language, ami nem jelent mást mint azt, hogy a markup language vagyis a leíró nyelv egy bővíthető változata.
A HTML formátum is Markup Language, az ML ezt jelenti benne. De a HTML egy szabvány alapján működik, vagyis a <br> tag használata az értelmezőben történő feldolgozáskor egy újsort(break) generál a megjelenítésbe.
Na itt van az igazi különbség az XML és a többi ML között.
Az XML-be mi magunk határozzuk meg a tag-ek neveit. A feladatait is mi határozzuk meg, mert a visszaolvasás után a saját alkalmazásunk fogja kitalálni ismét hogy a tag-ünk mit jelent. Egy példával élve, létre lehet hozni egy olyan tag-et XML-ben hogy <sphere> ami azt jelenti hogy gömb, és amikor betöltjük a saját XML állományunkat akkor létrehozhatunk egy gömböt a tag értelmezésekor. Ez a formátumsajátosság ami a lelkét adja annak, hogy különböző 3D formátumok leírását ilyen formában tároljuk.
Egy példa egy lap tárolására XML formátumban:
<library_geometries>
<geometry id="Empty_Mesh_lib" name="">
<mesh>
<source id="Empty_Mesh_positions" name="position">
<float_array id="Empty_Mesh_positions_array" count="12">-1.5 -1.5 0 -1.5 1.5 0 1.5 1.5 0 1.5 -1.5 0 </float_array>
<technique_common>
<accessor count="4" offset="0" source="#Empty_Mesh_positions_array" stride="3">
<param name="X" type="float"/>
<param name="Y" type="float"/>
<param name="Z" type="float"/>
</accessor>
</technique_common>
</source>
<vertices id="Empty_Mesh_vertices">
<input semantic="POSITION" source="#Empty_Mesh_positions"/>
</vertices>
<polylist count="1" material="Plane">
<input offset="0" semantic="VERTEX" source="#Empty_Mesh_vertices"/>
<vcount>4 </vcount>
<p>1 2 3 0 </p>
</polylist>
</mesh>
</geometry>
</library_geometries>
Itt minden egyes tag mint a <mesh> a feldolgozó alkalmazásban nyer értelmet. Ha betöltjük egy böngészőbe, akkor az csupán szövegesen megjeleníti a tartalmat, de nem fogja tudni, mit kezdjen vele.
Ugyan ez a lap az STL-ben a következőképp néz ki:
facet normal 0.000000e+000 0.000000e+000 1.000000e+000
outer loop
vertex -1.500000e+001 -1.500000e+001 0.000000e+000
vertex 1.500000e+001 -1.500000e+001 0.000000e+000
vertex -1.500000e+001 1.500000e+001 0.000000e+000
endloop
endfacet
Látszik, hogy az STL lényegesen kevesebb információt tárol, nem annyira szószátyár mint a fenti Collada formátumból kiszeletelt részlet.
A legfontosabb dolog talán az, hogy melyik formátumot mire kell használni.
Ha egy színű nyomatban utazunk és egy fejünk van, akkor STL-nél több nem kell. Ha már kettő vagy több filamentszálat is bele tudunk szuszakolni a fejünkbe, mert alkalmas rá, akkor a PLY vagy a 3MF formátum lesz a barátunk. Mert ezek már színeket vagy texturákat is tárolnak az objektum mellett. A 3MF formátum is szerkeszthető, ne lepődjünk meg, hogy ha elsőre krix-krax nyílik meg a szövegszerkesztőbe. A kis huncutok ZIP-el betömörítik a formátumot, így ha a kiterjesztése után odaírjuk egy ponttal, hogy objektum.3mf.zip, akkor ki lehet nyitni a fájlt és lehet látni benne a szépen összerakott XML fájlokat, amiben már tudunk turkálni. Ne felejtsük el visszacsomagolni, ha végeztünk.
Legtöbbször erre nincs szükség, csak használjuk.
Egyéb slicer formátumok
Minden szeletelőnek van saját formátuma, amibe elmenti a szeleteléssel kapcsolatos információkat. Erre pont azért van szükség, hogy a szeletelő is vissza tudja tölteni a szeletelt tárgyhoz tartozó összes beállítást. Mint a 3D tervezőnél, itt is érdemes elmenteni egy beállított objektumot a szeletelő saját formátumában, mert később nem kell majd okoskodni a beállításokon, vagy méretváltoztatásokon, mert ugye azt is lehet piszkálni a szeletelőben. Van olyan eset is, amikor több tárgyat rakunk a tárgyasztalra nyomtatás céljából, ilyenkor egy mentés, és egyben meg van a teljes tartalom. Legközelebb nem kell megint összepakolni a készletet.A S3D esetében ezt .factory kiterjesztés mellett menti el az alkalmazás egy bináris állományba.
De ott a Cura, ami kis huncut, és 3MF formátumba ment, de ha belenézünk a fent említett technikával, akkor látjuk, hogy van egy saját könyvtára, amibe a saját beállításait mentegeti. A jó benne, hogy a 3MF formátumot függetlenül a hozzáadott Cura könyvtár nélkül is tudják értelmezni az egyéb feldolgozó programok. De ha Cura-ba töltöd vissza, akkor megkapod az egyéb beállításokra vonatkozó információkat is.
Javaslom, hogy ha egy tárgyat rajzolgatunk, akkor mindig mentsük el az adott alkalmazás saját formátumába is, bármilyen is legyen az. Nagyot nem tévedhetünk, csak a hely fogy, de abból van elég, pont erre a célra.
G-Code a végső állomás
Ha formátumról beszélünk akkor ez szintén egy text állomány, vagyis egyszerű notepad-ben szerkeszthető file. De a tartalma miatt hívjuk G-Code formátumnak.Már előzőleg írtam róla pár szót. Most kibővítjük ezt a tudást.
A G-Code egy szöveges állományban található, újsor/kocsivissza(CRLF manapság ENTER) karakterekkel elválasztott(soronként értelmezendő) leíró fájl.
Ennek a formátumnak is van szabványa és vannak dialektusai is, így nem biztos, hogy bármely G-Code mindenhol ugyan azt jelenti majd.
A soronként értelmezhető azt jelenti, hogy amikor az adatokat feldolgozzák belőle, akkor nem kell minden sort betölteni ahhoz, hogy elinduljon a feldolgozás. Soronként is lehet értelmezni és végrehajtani a feladatokat. Ezt azért találták ki, mert régen a NC/CNC(numerical control/computer numerical control vagyis számokkal irányított) szerszámgépeknek és marógépek vezérlésében lévő CPU-k alkalmatlanok voltak a memória kicsiny mérete miatt egy nagyobb feladat betöltésére, így soronként olvasták be a háttértárról(akkoriban még floppy volt a szép neve) a feladat lépéseit, és soronként is hajtották végre. Ezért alkalmas egy 8bit-es Atmel processzor is arra, hogy kinyomtassunk vele egy 100Mb-os 3D tárgyat, amikor a memóriája csupán 8KB vagyis 8192byte. Csak hogy értsük, ha elmentünk egy Word dokumentumot üresen, úgy hogy nem ütöttünk bele egy betűt se, alapból 11.5KB méretű.
Épp ezért a fájl szerkezete szépen tagolt ha akarunk olvashatunk is benne, mert a kódok nyitottak, tudhatjuk, hogy a slicer programunk mit generált, és akár hozzá is nyúlhatunk.
Ezért működik például az a csoda dolog is, hogy minden réteg között váltani tudunk bármilyen paraméteren, lásd a temptower-ek, ahol 10 rétegenként más a fej hőmérséklet beállítása.
Ezek miatt van minden slicer programban prescript és postscript hozzáadási lehetőség, vagyis olyan előre megírt parancsok sora, amit a nyomtatás megkezdése elé rak a program, illetve a befejezése után.
Vannak olyan programok, akik a rétegek között is engednek belepiszkálást.
Hogy mindez mire jó.
A prescript(start script) például arra jó, hogy mondjuk ha kalibráltuk a nyomdagépet, akkor a kalibrációnak megfelelő új koordinátarendszert leküldjük a nyomtatónak, hogy ne torzuljon a nyomtatás. Postscript(end script)-nek pedig lehet venni azt a beállítást, hogy a nyomtató, ha befejezte a nyomtatást akkor mondjuk húzzon vissza 3cm filamentet, hogy ne folyjon rá a nyomatra a kihűlő filament, és vigye le a tálcát vagy emelje fel a fejet a nyomatról egy adott pozícióba.
Ezeket a jópofaságokat a szeletelőprogramba is be lehet állítani legtöbbször, de akár kézzel is hozzáadhatjuk, bár ez inkább mazo dolog mint logikus.
Az is nagyszerű a G-Code formátumban, hogy van benne komment. Gondolom régen helyszűkéből nem nagyon használták(1.44Mb-s floppy lemezen nem volt túl gazdaságos kommentelgetni a sorok között) de most ez nagyon éli a virágkorát. Van olyan alkalmazás, ami kommentekbe menti a beállításit, és vissza is tudja onnan tölteni ha épp nem mentetttük el a projektet a szeletelő formátumában.
Érdemes azt is tudni, hogy bár butának tűnik a G-Code, azért érdekes dolgokat is tud. Ilyen a ciklikusság vagy épp a szubrutin(subprogram) hívás, ami elugrik egy külön sorra, majd ha ott végez akkor visszaugrik a főágra. Ezek ugye azért is fontosak, mert ha egy ciklust leírunk pár kóddal, akkor ha valamit 10x kell végrehajtani, akkor azt nem kell 10-szer a kódba írni. Ahogy a szubrutinok hívásának is ez a célja, ha mondjuk egy ciklus magból 10-szer kell meghívni egy feladatot, akkor nem kell 10-szer leírni azt.
A helyszűke régen sok okosságot tett hozzá az ilyen rendszerekhez.
Természetesen a 3D printerek is egy dialektusát használják a G-Code-nak, amit RepRap G-Code-nak hívnak. Nem akarok részletes leírást készíteni, mert az nagyon hosszú lenne és értelmetlen, de a linkek segítenek a megértésben, bár kell hozzá egy kis angol tudás, mert még senki nem fordította le magyarra a RepRap kódokat.
Tudom a fenti dolgok picit szárazak, de itt marad súgónak. Úgy gondolom, hogy mint mindenhez a 3D nyomtatáshoz se árt tudni alapokat, sok esetben használat közben ugrik be az embernek egy megoldás, ha ismeri a korlátokat vagy a lehetőségeket.
A következő bejegyzésem már több tettlegességet fog tartalmazni. Elkezdünk egy nyomtatást az elejétől a végéig. Egyelőre nem saját magunk által tervezett tárgyal de nyomtatunk.
Jön az élvezet, ami a tanulás gyümölcse!
Nincsenek megjegyzések:
Megjegyzés küldése