Fusion360 és a nagy projektek

Bár később akartam írni a Fusion360-ról, de mivel beakadt nálunk egy igen nagy volumenű munka, ezért megosztom a tapasztalatokat, amit a munka során szereztem.

Fusion360 a hobbistáknak

Sajnos azt kellett tapasztaljam, hogy bár az F360 nagyon jó alkalmazás, de vannak még korlátai. Mivel ez egy progresszív webalkalmazás szépen felöltöztetve WebGL motorral, ezért esetenként érződik rajta a motorjának a tökéletlensége. Bár nagyon erős igénybevétel volt ez a projektünk, mert a teljes nyomtatandó tárgyat 3.9M poligon írta le, azért az ember elvárná, hogy ezzel az alkalmazás megküzdjön, úgy ahogy más alkalmazások teszik.
Első érdekesség az FBX import. Ez egy eléggé összetett formátum, amit az Autodesk saját magának készített, abból a célból, hogy könnyítse az átjárhatóságot az alkalmazások között.
Ettől függetlenül, sajnos a solid body-k nem jönnek át ezen keresztül se. Ami ugye egy 3DSMax export után jó lenne.
Ismét igazolódott a gyanúm, hogy nem mindent lehet egyből nyomtatni. Sajnos sokan azt gondolják a 3D nyomtatásról, hogy letöltöm a tárgyat, és ráeresztem a műanyagpumpát és kész is.
Ez nem így van. Amikor egy tárgyat készítünk elő nyomtatásra akkor sok szempont szerint kell megvizsgálni a végeredmény minőségének szempontjából az objektumot.
Mivel 900mm kőrátmérővel kellet nyomtatnunk, ezért értelemszerűen vagdosni kellett a tárgyat, ahol lehetett. Ez miatt sajnos egyből illesztéseket kellett csinálni, amivel a szétdarabolt elemek a megfelelő ponton tudnak találkozni.
Egy ilyen megoldásnál következik be a lapvágási hiba, ami a tárgyak rossz előkészítéséből adódik. Sajnos bizonyos poligonokat nem lehet csak úgy vagdalni, ahogy szeretnénk, ahogy azt már leírtam. Bármennyire a XXI. századot éljük a matekot nehéz felülbírálni.
A lapvágási hibák akkor jelentkeznek, amikor egy tárgy úgy van megrajzolva, hogy a poligonok itt ott össze vissza állnak és ezek miatt a poligon normálok és a poligonok síkja nem felel meg a leképzéshez. Ilyenkor a program, nem tud mit kezdeni a poligonnal, és nem vágja el rendesen, és ott hagyja, vagy eleve nem vágja el a tárgyat, hanem meg kér kedvesen, hogy javítsam a hibás poligonokat. Ami ugye 4M poligonnál elég sok lehetőséget rejt ahhoz, hogy ne találjam meg melyik volt a ludas.
Innentől adta magát, hogy a teljes tárgyat újra kell rajzolni amennyire lehet.
Ez volt az a pont, ahol elkezdtünk időben csúszni.
Bár később kiderült, hogy van alternatív megoldás, amivel a poligonok számát még tovább tudjuk növelni, de még az is jobb, mint beleragadni egy teljes újrarajzolásba.
Sajnos a később már akkor volt, amikor kész voltam a 80%-al, és pont a kényesebb részekkel.
Egyébként azért kellet újrahúzni mindent egy CAD-ben, mert az alap objektumot egy olyan ember csinálta, aki renderhez szokott, nem nyomtatáshoz. Ez abban mutatkozik meg, hogy vannak olyan tárgyak, amik tömör testnek tűnnek, de nem azok sajnos, csak le vannak fedve egy poligon síkkal, aminek nincs térbeli kiterjedése. Na és itt jön a baj, mivel a slicer nem látja a nulla vastag poligonmezőket, ezért pont nem csinálja meg a pályákat hozzá.
Na ha ilyenből van egy marékkal a kapott objektumnál, akkor lehet rajzolgatni. 
A sok normálvektor és lapvágási hiba mellett.
Az újrarajzolás se úgy megy mint a mesében. Két változat van, az egyik, hogy a betöltött test vonala mentén végigmegyek, és szépen megrajzolok mindent. A másik az, hogy türelmesen kivárom, hogy az F360 BRep-et csináljon a Mesh-ből, amit előtte TSpline-ba alakítottunk a poligonokból, vagy másból. Már innen is látszik, hogy több ponton elvérezhetünk. Természetesen így is tettünk. Ha már a négyszögletes felületek mellé beesett egy háromszög, akkor nem konvertált sehova a drága F360.
Szóval rajzolgattunk. Ami akkor kezdett bosszantóvá válni, amikor az ember rajzol, és tutorial videókat is néz, hogy miként lehetne gyorsítani a rajzolást. Aztán egyszer csak az F360 bejelenti, hogy akkor Ő most küld egy crash reportot és leköszön. Persze mentegetek, meg van backup is meg minden. De akkor is. Miért.
Hát azért, mert ez a szerencsétlen a chrome motorját használja, ami ugye már másképp fut amióta 64bit-es lett. Az eredmény kézenfekvő. A saját levelezéseim, FB és a YT nézegetés megette a chrome-ot, 3-4Gb volt az általa felhasznált memória. Erre néha beizgult az F360, megette a saját 6-7 gigáját, és már el is fogyott a gépemből a 16Gb memória. Jött a pukk. De úgy mint a hikari express, mert a chrome is leköszönt, uppsz-al. Szóval, vigyázni kell, mert ha nem akarjuk, hogy óránként bedőljünk, akkor a chrome-ot be lehet csukni a munka idejére. Nem is baj, de akkor is. Milyen ez már.
Na ez a gondja a hibridnek, nem beszélve a WebGL-es dolgokról. 
Mivel ez JS-ben van(pontosabban ECMA script-ben) ezért ott is a memóriaproblémák lépnek fel, de úgy, hogy nem is látjuk a szerencsétlent belülről.
Ugye azt kell tudni, hogy a javascript nem ismeri a deallokációt a memória irányából. Van egy garbage collectora, ami arra van, hogy takarítson a memóriából, amikor már kell. De nagy helyfoglalások esetén a GC nem kedves hozzánk, amikor töröljük a tárgyat. Lefordítva, ha betöltök egy nagy tárgyat, ami felemészt 1Gb memóriát, akkor ha törlöm a tárgyat, a javascript motor nem adja vissza a memóriát a rendszernek azonnal, csak majd egyszer, ki tudja mikor. Így gyorsan le lehet darálni akár 32Gb RAM-ot is. 
A másik gond a WebGL-el, hogy míg a natív appok belenyomják a grafkártyába a tudást, addig a WebGL még egy réteget képez, és bárhogy is nézzük, ez eszi a vasat. Ezért az a tárgy, amit egy modellező alkalmazás vígan forgat akár 4M poligonnal is, hibátlanul, és csak 2Gb-t kér ezért a rendszertől, addig a WebGL-nek ez 4-5Gb és akadozik rendesen, mert ugye nem erre van kitalálva. Bár a lehetőségeihez mérten gyors, de nem eléggé.
Leszámítva ezeket a kellemetlenségeit az F360-nak, egész jól használható munkára. Csak figyelni kell, mert csal.
Másik észrevételem az volt, hogy rapszódikusan kapcsolgatta ki és be a grid-et, meg a gridsnap-et. Főleg akkor amikor betöltöttem a tárgyat, és a méretezési hibák miatt(a 3DSMax mi a péklapátért menti a tárgyakat km-es léptékben) szétesett teljesen a megjelenítés, a rács, a tengelyek és minden. Amikor ránéztem a tárgyra, akkor tudatosult bennem, hogy 1500km széles a tárgy. Nem csoda, hogy az F360-nak felakadtak a szemei. 
Szóval észnél kell lenn az importálásnál, mert ellövi a UI-t.
A másik vicces dolog az importálás. Van amit erőből megcsinál az alkalmazás. Ilyen az .obj kiterjesztés, ezt behúzza csont nélkül. De az FBX-et már felküldi a felhőbe, és amennyi ideje van, úgy konvertálja. Volt hogy egy egyszerű kis tárgyat 12 percig konvertált, és volt hogy az egész 4M poligont, egyben 3 perc alatt megcsinálta. Gondolom a hobbista/startup license nem élvez prioritást a fizetősökkel szemben. Az, hogy az FBX import nem lokálisan van megoldva, megdöbbentő volt. 
Természetesen a méretezési problémánál, már el is számolta magát az alkalmazás, és se szó se beszéd, bizonyos kéréseimet nem teljesítette. Erre akkor jöttem rá, amikor már többedjére futottam neki egy átméretezésnek, és nem csinált semmit. Csak úgy tett, de eredménytelen volt. 
Ekkor mentettem, kilőttem az appot, újráztam, és láss csodát, működött. Szóval ha valami furát művel az F360, akkor azonnal újraindítás, mert elszarhatjuk a munkánkat.
A jó hír, hogy a backup rendszer kiválóan működik. Bármilyen crash volt, visszajött minden. Nem volt igazi adatvesztésem.
Másik érdekessége az appnak, hogy szó nélkül megcsinálja amit kérünk. Beleszaladtam abba a vicces helyzetbe, hogy duplikáltam egy body-t, és bent maradt mindkettő. Majd az STL exportnál nem szedtem objektekre, hanem egybe tolattam ki. Aztán a slicer megette, majd azzal a lendülettel a szeletelésnél el is hasalt a tárgyon. Én meg néztem, hogy ez mi. Miért is feküdt ki a program, amikor minden jó. Hát azért, mert a két teljesen egyforma tárgyat a slicer valami miatt képtelen volt megérteni, és egy kedves figyelmeztetés helyett pukkant egyet, és elment az eventviewer-be írogatni pár exception-t.
Hogy miért van ez. Azért mert a két teljesen megegyező tárgy, egy azonos térben kétszer képződik le, akkor a slicer nem veszi ki duplikált pontokat és poligonokat, hanem nekifekszik a baromságot megvalósítani.
Igazán az F360 is figyelmeztethetne, hogy barátom, az általad megadott térben pontra megegyező tárgy van kétszer, ugyan ott. Biztos ezt a baromságot akarod? De most nem teszi, majd egyszer biztos.
A másik dolog meg az, amit nem árt tudni a slicerekről, hogy a legtöbb slicer a multiplatform oldalán feláldozza a sebességet és a működési stabilitást. Ez alól van pár kivétel. De a legtöbb ilyen alkalmazás valam miatt python-ban vagy valami más scriptben íródik. Azt ugye nem kell mondanom, hogy a scripteket nem véletlen hívjuk így, mert azok nem igazi programok. Épp ezért lassabbak is és sajnos hamarabb köhögnek fel olyan hibákat, amit egy natív alkalmazásban megoldhatunk, még akkor ha jön is az a fránya kivételkezelés. A script alapú alkalmazások nem mindig tudnak mit kezdeni bizonyos hibákkal. Pont a felépítésükből adódóan. 
Összegezve, mert már nagyon elléptem a témától. A Fusion360 használható munkára. De oda kell figyelni, hogy mit importálunk és mit exportálunk. Illetve a feldolgozáskor, mit is akarunk pontosan. Nem árt előkészíteni egy már ismert natív alkalmazással az átadott objektumot, hogy ne hasaljon el rajta a Fusion360. 
Továbbra is használni fogom, mert ténylegesen alkalmas kisebb projektekre, sőt még akár nagyobbakra is, csak ne legyen benne importált tárgy.
Mindezek mellett, egyébként nem volt gondom, mert amikor valami szabályosat kellett csinálni, akkor szó nélkül tette a dolgát, a saját szabályait követve. 
Továbbra is ajánlom, ha nincs más, amit jobban lehet szeretni.