gondolataim elsősorban játékfejlesztésről

Manapság viszonylag könnyű elveszni a 3D adatleíró típusok között. Találhatunk bináris és szöveges formátumokat, statikus és animált modelleket leíró változatokat, egyszerű modell leírókat, de akár komplex jelenet leírókat is.
Egyes cégek / szervezetek próbálkoznak "szabványos" formátumok kialakításával, de a leggyakoribb modellezőprogramok saját formátumaival nehezen tudják felvenni a versenyt.

Az ASE formátum szöveges, statikus és animált adatot is tartalmazó jelenetleíró. Ebben a posztban az általam használt, lényeges elemeket emelem ki.

A formátum blokkokra osztja a tartalmat. Egy blokk * karakterrel kezdődik, egy típus jelöléssel folytatódik majd a blokkot egy { ... } páros zárja be. Természetesen a blokkok egymásba ágyazhatók ezzel egy hierarchiát adva a jelenetnek.

*MATERIAL_LIST - nevéből adódik, hogy a materialokat tartalmazza ez a blokk. Ebben szerepelnek  *MATERIAL blokkok, amelyek további  *SUBMATERIAL blokkokat tartalmazhatnak. A submaterialok külön fejtörést szoktak okozni mivel a gyakorlatban külön materialként szokás őket kezelni. A *MAP_XXXXX blokkok tartalmazzák, hogy hány és milyen textúrákból épül fel az adott material. Többek között itt találjuk a file hivatkozásokat is.

*GEOMOBJECT - ez tárol (legalább?) egy *NODE_TM és *MESH blokkot.
A *NODE_TM számunkra az egyik legizgalmasabb hiszen ez tartalmazza a meshen elvégzett transzformációkat: eltolás (*TM_POS), elforgatás (*TM_ROTAXIS és *TM_ROTANGLE - ez utóbbi radiánban értendő) és skálázás (*TM_SCALE). Az ezekből kiszámolt mátrix inverzével a mesh vertexeit beszorozva visszakapjuk a modellezés kiinduló meshét!
A *MESH blokk tartalmazza a geometriát (*MESH_VERTEX - pozíció, *MESH_TVERTEX - textúra koordináta, *MESH_VERTEXNORMAL - normál vektor) és a topológiát (*MESH_FACE és *MESH_TFACE). Fontos tudni, hogy minden egyes face-hez megadható, hogy az adott material melyik submaterialjét használja!

Engine szempontjából a formátum legnagyobb előnye, hogy transzformálva a *MESH-eket a kiindulási helyzetükbe az azonos mesheket felismerve könnyen megoldhatjuk az instance-olást és a modular level designt.

Az utóbbi idők 3D mániája lassacskán a játékokra is kiterjed ennek köszönhetően sok mai játékot (játék motort) felvértezték a sztereó renderelési képességgel.
A legegyszerűbb és legolcsóbb megoldás az anaglif változat hiszen mindössze egy egyszerű szemüvegre van csak szükség (leggyakoribb a vörös-cián színezésű lencsepár). Komoly hátránya a színek torzulása kiváltképp a vörös színé (emiatt megfontolandó a szürkeskálás megjelenítés).
Szintén passzív változat a polarizált szűrős szemüvegek alkalmazása, amelyeknél már nem tapasztalható különösebb torzulás.

Szoftver oldalon (tudomásom szerint) nincs túl nagy különbség a különböző változatok esetén. Az egyik legfontosabb tulajdonsága ennek a renderelésnek, hogy kb. duplájára nő a kirajzolandó háromszögek száma mivel mindent kétszer kell renderelni a bal és jobb szemnek megfelelően.
Lényeges szempont, hogy vetítéskor a két elterjedtebb verzió közül a párhuzamos tengelyű asszimetrikus perspektív vetítést (parallel axis asymmetric frustum perspective projection) használjuk.
Amennyiben elérhető hardveres sztereó támogatás akkor használjuk a natív bal és jobb oldali színbuffereket a rendereléshez.
Leggyakoribb esetben azonban magunknak kell megoldanunk a két oldal renderelését, amely nem több egy egyszerű offscreen metódusnál, amit egy post-process effekt követ. Ez az effekt additiven blendeli a két képet a bal oldalt piros, a jobb oldalt pedig cián szűrővel.

Végül következzen egy saját példa:

Lassan végéhez közeledik a következő demóra való felkészülés. Mivel a CEGUI támogatást eltávolítottam az engine-ből szükségem volt (ismét) fontok kezelésére.
Szokásomhoz híven számos lehetőséget végignéztem (természetesen glDrawPixels szóba sem jöhetett) míg végül az AngelCode egyik, teljesen ingyenes (többé-kevésbé folyamatosan fejlesztett) projektjénél értem célba.

Ez a projekt a textúra alapú fontkezeléshez ad segédeszközt. A program kétféle kimenetet szolgáltat: egy vagy több textúrát (PNG támogatás!) valamint egy szöveges vagy bináris leíró file-t. Ez utóbbi alapján lehetséges a textúra megfelelő felhasználása. Mindössze annyi a dolgunk, hogy a leíró alapján kiszámolt vertexeket a megfelelő pozícióba a megfelelő textúra koordinátával kirendereljük.

A textúra raszteres (bitmap) mivoltából fakadóan az eredmény nem alkalmas tetszőleges skálázásra (elsősorban nagyításra) a különböző méretű fontkészleteket külön-külön le kell gyártanunk.

Végül következzen a link: www.angelcode.com/products/bmfont/

Az enginem következő mérföldkőjéhez érkeztem az elmúlt napokban: 3D hangok kezelése OpenAL-lel.

Ennek az API-nak az implementációja a legtöbb rendszeren egy wrapperként jelenik meg (win alatt DirectSound3D) azonban egyes Creative kártyákhoz létezik natív támogatás is.

Az OpenAL API-ját az OpenGL-hez hasonlóan tervezték meg az elnevezések követik annak konvencióit. További hasonlóság a koordinátarendszer, amely mindkettő esetben ugyanaz.

Alapszintű használata nem különösebben nehéz mindössze pár függvény segítségével életre is kelthetjük viszont legalább egy .wav betöltőre szükségünk lesz.

A rendszerben a hangforrásokhoz( source) buffereket kell rendelnünk, amely bufferek a mi általunk megadott hanghullámot jelentik. A bufferek számára jelen ismereteim szerint nincs korlátozás ezzel ellentétben egyszerre (általában) max. 256 hangforrás használata lehetséges tehát mindenképp érdemes megoldanunk a hangforrások "újrahasznosítását".
 

A hangforrások 3D-ben tetszőlegesen elhelyezhetők (irány és pozíció) és ugyanígy a hallgató ( listener) helye és orientációja is tetszőlegesen megadható.
Ami még lényeges lehet, hogy a hangforrás pozícióját relatívan is megadhatjuk a hallgatóhoz képest (pl. háttérhang kezelésnél a hang mindig a hallgató helyében szól).

Az elmúlt közel két hónapban az engine alapvető változáson esett át.

Kezdődött mindez azzal, hogy a szerkesztőt akartam leválasztani és külön SDK-t kialakítani belőle aztán ugyanezt magával a motorral is szándékomban állt megtenni. Ezt követően rájöttem, hogy nincs értelme két különálló renderelést készíteni.

A végeredmény az lett, hogy

• a szerkesztőt teljesen egybeépítem a motorral, emiatt
• a módosítások közvetlenül kipróbálhatók élesben ehhez viszont
• minimálisra kellett szorítanom a "compile" időt ami a statikus modellek esetén jelentős volt, de ezt érvényteleníti a tény, hogy
• modular level design alapokra helyezem a környezet szerkesztését

valamint

• szinte teljesen platformfüggetlen az engine és editor - mindössze OpenGL szükséges hozzá
• az SDK pár függvényt tartalmaz csak, mert kezelése lua interfészen keresztül történik emiatt
• könnyen készíthető hozzá (grafikus) konzol.

Az engine logikailag már elérte a két hónappal ezelőtti állapotát azonban jóval letisztultabb ill. egyszerűbb a felépítése és kiegészült tárgy használattal.

Jelenleg a modular level design-ra történő felkészítés történik...

Az idó telik lassan két hónap telt el legutóbbi bejegyzésem óta amit talán svn verziószámokkal izgalmasabb kifejezni: 97 volt akkor és most 115.
Ez idő alatt bizony elég sok változás történt...

Villám

A második elem az effektek között. Szerencsére használni egyszerű, a renderelése pedig nagyszerű: hasonló a billboardhoz, csak itt egy szalagot kell beforgatni a kamera közeli síkjával párhuzamosan.

Decal

Egyelőre a szerkesztő tartalmaz decal készítőt, amely egyszerűen megvágja a teret egy tetszőleges téglatesttel és elkészíti a textúrázott háromszögeket.

Animáció

Foglalkoztam némi csontanimációval is: automatikus csontozás és BVH file-ok támogatása. Az idő hiánya miatt azonban nem került sor a befejezésre.

Térfelosztás

Átírtam direkten indexelhetőre a loose octreet miáltal még gyorsabb lett és megoldódott a front-to-back renderelés is.

Material

Kétoldalas és átlátszó felületek korrekt(!) kezelése általános szinten.

Tartalomkészítés

Ezen a téren történt a legtöbb fejlődés. Négy procedurális algoritmussal bővült a szerkesztő:

• barlang - az alapja egy sejtautomata,
• fa - az alapja a Weber-Penn-féle cikk
• terep - az alapja chunked LOD,
• felhő generátor, aminek az alapja a Niniane Wang-féle cikk.

Ezek mindegyike lassacskán SDK formát kap és hasonlóképpen a szerkesztő is. Ezzel lehetővé válik, hogy külső segítséggel (és gyorsabban) megoldjam a GUI körüli "problémákat" tekintve, hogy pályafutásom során nem igazán sikerült egy mások által is használható rendszert megalkotni (még a CEGUI-val sem) :)

Érdekes lehet még kiemelni a terep generáló azon tulajdonságát, hogy képes "lyukakat" kezelni az indoor elemek integrálását megkönnyítendő.

Sikerült találnom egy szimpatikus (pontosabban sok közül a legszimpatikusabb) flash alapú galéria kezelőt. Mostantól igyekszem oda gyűjteni a képeket.

www.inspekcio.hu/indigo_illusions/tiltviewer/index.html

A keddi napon egy nagy levegővétellel 5 óra alatt implementáltam a cascaded shadow map technikát. A módszer lényege egy rövid mondat: a CSM a PSM (perspective shadow map) diszkretizált változata vagyis nem folytonos igazítjuk a shadow map felbontását a vetítéshez, hanem 2-4 lépésben különböző textúrákkal. Az eredmény önmagáért beszél...:3

Az elmúlt napokban gondoltam, hogy a "klasszikusok" (Quake1-3) iránti tiszteletből megvalósítom a dinamikus (pont)fénykezelést hozzájuk hasonlóan.

A technika a következő.
Kigyűjti a fény hatáskörébe tartozó háromszögeket.
A látvány alapján valódi árnyalást nem alkalmaz (esetleg eldobálja normál alapján a szükségtelen háromszögeket?), hanem csak áttűnést számol egy meglehetősen agyafúrt módon. Az áttűnéshez a pontfény 2D textúráját használja fel és a háromszögek vertexeihez megfelelően kiszámolja a textúra koordinátákat úgy, hogy a végeredmény egy 3D áttűnésnek tűnjön.
A rendereléskor pedig decalként rajzolja ki ezen háromszögeket.
Én annyiban változtattam ezen, hogy az áttűnést 3D textúrával oldom meg.

A technika a fénytér szinezését ill. skálázását teszi lehetővé.

Megjegyzés:
Valószínű, hogy a Doom3 / Quake4 fénykezelési alapelve is ez volt ill. kiegészítették korszerű árnyalással.

Összefoglaló

Több hónapnyi munka után ismét elérkezett az engine a következő mérföldkövéhez. Számos funkcióval bővült és néhány aspektusban módosult a legutóbbi kiadás óta.

1. CEGUI használata.
2. Térbeli (statikus és dinamikus) triggerek kezelése, amelyekhez scriptek köthetők.
3. Fények kezelése (árnyalás nélkül).
4. Lens flare effekt.
5. A játék engine-t (teljesen) átfogó scriptnyelv: szereplőket, materialokat, kamerát, más scripteket, cinematic-okat stb. vezérelhetnek. A scriptek triggerekből vagy más scriptből indíthatók. A játék indításakor automatikusan lefut a 0. script.
6. A HSR algoritmus occlusion cull lett HZB-vel. A térfelosztó algoritmus pedig loose octree.
7. A szerkesztő képes tetszőleges modellt szétdarabolni és statikus környezetté konvertálni a HZB "igényeinek" megfelelően. Tehát szerkesztés nélkül egyben importálható a "pálya" nagy része.
8. A szerkesztő már használható annyira, hogy a 9. demót össze lehetett vele rakni.

Demo 9

Irányítás: Bal shift, WASD, egér.
Kamera távolítás, közelítés: 2,3.
Tárgyfelvétel, eldobás: N,M.
 

A demó az alábbi részekre tagolódik és kettő egymás után teljesítendő feladatot tartalmaz:

1. Bevezető animáció.
2. A "helyére" tenni a fehér homokóraszerű "amulettet". Ezzel aktiválódik az "oltár".
3. Átvezető animáció.
4. Megtalálni / megszerezni és az "oltárra" helyezni a 4 db kék "amulettet".
5. Játék vége animáció.

Az első két animáció ESC-cel megszakítható.
Kisebb hibákat tartalmaz a character controller ill. ha sok tárgy van a szereplő körül nem mindig azt veszi fel amit szeretnénk.

Ajánlott a vsync bekapcsolása (alapesetben ezen van a config), mert a "túl nagy" fps-re (egyik gépemen 999, másikon 5000) nem tudni hogy reagál a gpu.

Link:

www.inspekcio.hu/indigo_illusions/demos/sakura_demo_2010_09_12.zip