Volt nekem egy problémám a content pipeline-omban. Már ha azt a pár poligonhalmazt kontentnek lehet nevezni, amiket összebarmoltam Blenderben tesztelés gyanánt. Nekiveselkedtem pár éve és összekínlódtam egy 50kb-os python-scriptet, ami szépen működött, a Blender 2.4x-es verzóiban. 2.5-tel jött a nagy pofáraesés, az eredeti szkript minden sora minimum egy helyen dobott egy hibát, így dobhattam el az egészet. Mivel nem rajongok a pythonért, gondoltam az egyetlen ésszerű dolog, ha meglévő formátumot használok, ami tényleg jó ötlet, hisz egy népszerűbb formátumba minden 3d-s szoftver tud menteni, de milyen jó lesz.
Ránéztem hát az Autodesk által fémjelzett FBX formátumra, amihez még SDK-t is adnak, ami betölti a file-t, én meg csak kiírom saját formátumomba, minden van benne, ami valaha csak kellhet. Elég jól is ment a gyér dokumentáció ellenére is, csak az animációnál akadtam fönn azon, hogy a Blender (2.6.5) fbx exportere minden frame-et kiexportál, nem csak a keyframe-eket.
Ez annyit jelent, hogy ha van 2 keyframe-em, mondjuk 1-es és 100-as képen a időskálán, akkor 100 transzformációt ír ki minden csontnak. Ezt én erős túlzásnak tartom, és kiderült, nem is teljesen ennek kéne lennie, azaz az exporter nincs a helyzet magaslatán. De azt is olvastam, hogy ez az fbx formátumot amúgy is sokszor mocap adatok átvitelére használják, ahol kb minden képkockán változhatnak a transzformációk, azaz megszokott, hogy minden pillanatra van külön adat. Most mit lehet tenni, másodpercenként 25 képpel számolva egy 10 mp anim 250 keyframe, mondjuk 10 csontra 2500 mátrix lesz az engine-ben, kicsit sok, megjegyzem az fbx szögekben tárolja a forgatásokat.
Nekem ez egy kicsit sántított, így vettem egy nagy levegőt, és ’együltömben’ írtam egy másik szkriptet az újabb Blenderhez, ami nem 50 hanem 5kb lett. Simán kidumpolok mindent egy köztes text-fileba, semmi extra kód, csak face-data, skinning, és animáció.
Írtam egy szimpla c++ konzolos progit, ami ezt a köztes filet beolvassa és előállítja a végleges adatokat az engine-nek, és azt már emészthető formában file-ba írja. Ezzel azt értem el, hogy ahelyett, hogy minimalizáltam a Blender-függő kód mennyiségét, így sokkal könnyebb frissíteni, ha valami változik. A konverter progi meg nagyjából marad mindig ugyanaz, hacsak nem kerül be valami extra, de cpp-ben nem nagy ügy.
A köztes file kiterjesztése mra lett (m-raw rövidítve). A kész modelfile .m típusú, hasonló a régihez, de pár dolgot hozzáadtam. Pl a régi csak 1 textúrát tudott kezelni, ami nem volt túl jó ötlet így visszagondolva.
Így van most egy Blender -> szkrtipt(python) -> .mra(texfile) -> mraimporter(c++) -> .m(textfile) útvonalam.
Ezeken kívül van egy modelnézegető progi (mviewer.exe) és egy C-s dll, ami ’m’ fileokat olvas be, megkönnyítve bármilyen programban a használatukat.
