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

Az elmúlt napokban a fizikai engine (PhysX) terhelésével / terhelhetőségének növelésével foglalkoztam vagyis hogyan lehet több száz dinamikus fizikai objektumot szerepeltetni egy jelenetben.
A jelenetben statikus trimeshek - melyek egy összetett belső tér részei voltak - és dinamikus konvex testek szerepeltek ez utóbbiak száma 400-600 között mozgott. A cél a láthatóan nem mozgó objektumok kiszűrése és inaktiválása volt.

Első gondolatként az API beépített függvényeit nézi át az ember és meg is találja az IsSleeping (vagy hozzá hasonló) utasításokat. Ezek azonban a gyakorlatban legtöbbször nem válnak be több ok miatt is. Számos paraméter befolyásolja - amelyek jelentésével tisztában kell lennünk pl. küszöbértékektől, az altatás típusától, a szimuláció léptetése - és szinte mindig az tapasztalható, hogy hiába tűnik mozdulatlannak a tárgy azonban mégsem kerül altatásra.

Második próbálkozásként próbáljuk figyelni a sebességeket (lineáris és anguláris) ill. ezek csökkenését. Itt már jelentkezhet az a probléma, hogy bár az anguláris sebesség zérus a test még tovább akarna forogni, mert csak pillanatnyilag került egyensúlyi helyzetbe. Ezt a helyzetet elhanyagolva sem sikerül azonban a kívánt hatást elérni.

Harmadik lehetőség lehet az elmozdulás és anguláris sebesség vizsgálata. Az elmozdulás vizsgálata már közelebb visz minket a lehetséges megoldáshoz, de az anguláris sebesség még most összezavarja a képet.

Negyedik lehetőségként tehát adott, hogy az elmozdulást kell vizsgálnunk, de hogyan vizsgáljuk az orientációt. Lehet vizsgálni az orientációt kvaternió formájában azonban érdemesebb kihasználni, hogy az API-tól lekérdezhető ugyanez világ koordinátában lévő mátrixként is.
Ennek segítségével az elmozdulást és elforgatást egyetlen vizsgálatba lehet sűríteni és az eredmény magáért beszél: csak azon tárgyak lesznek aktívak, amelyek láthatóan mozognak. Ebből következik, hogy az engine sok, egymástól független tárggyal terhelhetővé válik hiszen feleslegesen tárgyakat nem vonunk be a szimulációba.

És még mielőtt arra gondolnánk, hogy ez a vizsgálat mennyire lehet költséges vegyük figyelembe, hogy jóval olcsóbb, mintha felesleges objektumok terhelnék a fizikai engine-t.

Ezen a héten egy teljesen új képességgel bővült az engine nevezetesen az útkereséssel. Első terveim között egy egyszerű waypoint rendszer kiépítése szerepelt, amelyet természetesen külön szerkeszteni kellett volna.
Szerencsére ennél már létezik jóval hatékonyabb és automatikusan elkészíthető alternatíva, amit navigation meshnek hívnak. Ennek az elkészítéséhez elérhető egy ingyenes és nyílt forráskódú könyvtár, ami recast névre hallgat - http://code.google.com/p/recastnavigation/
(ez pedig egy jó összefoglaló miért érdemes waypoint helyett navmesht használni - http://www.ai-blog.net/archives/000152.html)

Egy egyszerű háromszöghalmazból képes elkészíteni a navigation mesht, amire az alábbiak jellemzők:

• mindig konvex poligonokból álló mesht készít
• ezekhez a poligonokhoz tárolja a szomszédosság információt
• vagyis egy gráfot épít fel, amelynek pontjai az egyes konvex poligonok
• lehet szabályozni, hogy milyen típusú felületek vegyen figyelembe - amin lehet járni, mászni, lépcsőzni stb

A navigation mesht mint gráfot felhasználva A* algoritmus segítségével gyors útvonalkeresésre használhatjuk. Az A* algoritmus egy szemléletes leírása rácshoz: http://www.policyalmanac.org/games/aStarTutorial.htm

A legnagyobb problémát azonban az út elkészítése jelenti az A* segítségével kapott poligonlistából. Az utat egy egyszerű pontsorozattal tudjuk ábrázolni - e pontsorozat előállítása okozza az igazi fejtörést...

Némileg viszontagságos a címben szereplő témakör implementálása mivel számos helyen egybefonódnak a problémák.

1. probléma

A triggerelésnél azt szeretnénk, hogy a triggerrel kapcsolatba szereplőt / szereplőket regisztráljuk. A probléma onnan ered, hogy a PhysX shape-re lebontva hívja meg a triggerelés eseményt vagyis ha egy szereplő több shape-ből áll akkor a triggerelés annyiszor fog meghívódni ahány shape-t tartalmaz az actor. Mi pedig azt szeretnénk, hogy egy frame-ben csak egyszer történjen egy trigger - szereplő kölcsönhatás.
Mondhatnánk azt, hogy ha egy triggert már aktiváltunk az adott frame-ben akkor többet nem lehet. Ezt kizárja azonban a 2. probléma.

2.probléma

Ez már nem kapcsolódik a PhysX-hez ez már a játék engine-ből következik. Ez pedig nem más, hogy egy frame-ben több szereplő is hathat a triggerre.
Emiatt regisztrálnunk kell minden egyedi szereplő - trigger kapcsolatot. Azonban ha ennél még árnyaltabb triggerelést szeretnénk - nevezetesen regisztrálni a szereplő ki-, belépését és ott tartozkódását akkor találkozunk a 3. problémával ( a belépést és ott tartózkodást már most is tudnánk kezelni azonban a kilépést nem hiszen ekkor már nincs szereplő - trigger kapcsolat).

3. probléma

Bár a PhysX képes ezt a 3 állapotot közölni velünk az 1. probléma miatt nem célszerű használni (másrészről ez a tulajdonság így nem lesz fizikai engine függő!).
Ahhoz, hogy a trigger - szereplő kapcsolat ezt a 3 állapotát tudjuk kezelni szükségünk van arra, hogy ezen kapcsolatok

• létrejöttét / létrejöttének idejét tároljuk - ez lesz a belépés esemény
• ha a kapcsolat nem az adott frame-ben jött létre akkor figyelni, hogy az adott frame-ben is született volna-e egy ilyen
• ha igen, akkor csak frissítjük ezt a kapcsolatot - ez az ott tartózkodás esemény
• ha nem, akkor a szereplő kilépett a triggerből vagyis ez az kilépés esemény és ilyenkor törölni lehet a kapcsolatot.

Van azonban egy 4. probléma is...

4. probléma

Előfordulhat olyan eset, amikor még létezik egy olyan trigger - szereplő kapcsolat, amelyben a szereplő már a jelenetből törölve lett. Ezt bonyolultabb módon referenciákkal vagy egyszerűbben késleltett törléssel küszöbölhető ki (hiszen max. egy frame-mel ezelőtti keletkezett kapcsolat esetén fordulhat elő ez).

Ezt a 4 problémát megoldva kapunk egy a játékokban látott triggerelési rendszert - lehetséges, hogy van több probléma is, de azokkal egyelőre nem szembesültem :]

Mivel képekben már nem nagyon tudom mutatni a fejleményeket (és sokak unszolására:3) a jelenlegi állapot (egy részét) bemutató videó:

A 3D enginek egyik központi kérdése saját modellek ill. jelenetek felhasználása. Az ehhez szükséges munkamenet általában úgy történik, hogy a felhasználni kívánt modellt elkészülése után egy exportálás következik amit végül egy importálás zár.
Ennek során az engine-nek rendelkeznie kell az általa támogatott formátum minél teljesebb körű támogatásával valamint a modellezéskor ill. exportáláskor figyelembe kell venni az engine importálójának igényeit.

Érezhető és tapasztalható is, hogy ezek igen kényes műveletek lehetnek és sok fejfájást okozhatnak mind a modell készítésekor és exportálásakor. Általában a nem animált modellek kevesebb fejfájást okoznak szemben az animált modellekkel.
Csak néhány a leggyakoribb problémákból:

• a modellező és engine eltérő koordinátarendszere - melyik tengely jelenti a függőlegest
• a méretarányok ritkán egyeznek meg a két alkalmazásban
• csontvázas animációkor a méretaránybeli eltérést a csontváznál és az animációnál is figyelembe kell venni
• a modellező által használt modell geometria / topológia leírás nem feltétlen illeszkedik az engine-hez
• általában egy engine kevesebb és nem ugyanolyan material feature-t használ, mint egy modellező program
• a material animációkhoz használt scriptek nehezen (vagy egyáltalán nem) alkalmazhatók egy engine-ben
• külön formátum lehet szükséges statikus és animált modellekhez.

Kézenfekvő megoldásnak tűnik saját exporter készítése az engine-hez azonban ehhez szükséges a támogatni kívánt modellező programok SDK-inak ismerete és az exporterek karbantartása. Ezek elkészítése és tesztelése azonban rendkívül időigényes lehet - az adott program támogatni kívánt képességeinek függvényében.

Létezik egy formátum, amely eredetileg azért született, hogy a különböző modellező programok közötti információcserét megkönnyítsék ill. egységesítsék - innen ered a file formátum neve is: Digital Asset Exchange (magát a törekvést COLLADA-nak nevezték el) - azonban ez egyéb 3D alkalmazások számára is vonzóvá vált (hiszen
mindezen nehézségek egy csapásra kezelhetővé válnak egy "mindent leírni képes" formátum megszületésével).

Egy xml alapú leírónyelvről van szó, amely biztosít egy szabványos / közös nyelvkészletet, de ezen felül tetszőleges bővíthető saját, nem-standard elemekkel. Mivel rengeteg tulajdonság leírására képes, ezért felépítése meglehetősen szövevényes.
Ebből következik, hogy csak akkor érdemes a támogatása ha ezen tulajdonságokat valóban ki is tudja használni az engine.

Folyt. köv.

Az elmúlt hetekben megpróbálkoztam ezzel az igen ígéretes technikával. A lényege röviden a következő.
Adott két különböző, de nagyjából hasonló csontváz. Konkrétan eltérő a csontok száma, a csontok helyzete azonban a felépítés hasonló, mint pl. két emberi mocap csontváz esetében.
Az egymásnak funkcionálisan megfelelő csontok összerendelése után kiszámítható csontonként egy járulékos transzformáció, amely az egyik csontvázon végrehajtott mozgást képes átvinni a másik csontvázra.

Sajnálatos módon túlzottan sok információt nem találtam róla pedig néhány engine tartalmazza ezt a feature-t ill. a 3D modellező programokban is megtalálható.

...és hogy miért ígéretes a motion retarget?
A csontvázas animációhoz három dolog szükséges:

• egy virtuális csontvázra
• egy, a csontváznak megfelelően elkészített modellre
• animációkra.

Ezek közül az első kettőt elég egyszer elkészíteni utána tetszőleges animációt készíthetünk hozzá. Azonban az animáció készítése nem egyszerű feladat. Ráadásul ha saját mocap animációt szeretnénk használni - akár előre felvettet akár realtime - akkor annak a csontváza nagy eséllyel nem fog megegyezni az adott modellhez tartozó csontvázzal. A motion retarget ezt a különbözőséget hidalja át. 
Eme technika nehézsége abból fakad, hogy egymásnak megfeleltessük a funkcionálisan azonos csontokat - ez az a lépés ami jócskán megnehezíti az automatizálást.

Megjegyzés:

Mocap animációk elterjedt formátuma a BVH. Rengeteg ingyenesen elérhető és jó minőségű csomag található neten. Ezek felhasználásához legtöbbször elengedhetetlen a motion retarget használata.

Csak egy kép miatt :]

A ShaderX7-ben található egy elsősorban elvi leírás a Crysis-ban található SSAO működéséről és egy némileg használható forráskód hozzá. A játék engine-jében használt shader megtalálható itt: http://www.pastebin.ca/953523 .

Most pedig következzen pár kép az általam megvalósított verzióból.

A deferred shading position reconstruction része igen kulcsfontosságú lépés hiszen meglehetősen számításigényes művelet (mátrix transzformáció) is lehet - arról az esetről nem is szólva amikor egy külön float buffert használunk a pozíció részére.

Az OpenGL által használt depth buffer segítségével megoldható a kérdés.

Az alábbi képlet segítségével közvetlen a depth bufferből származó átszámolható lineáris, világban értett értéktartományba (a kamera közeli és távoli síkja közé):

a = (FAR) /(FAR - NEAR);
b = (FAR * NEAR) / (NEAR - FAR);
z_linear = b / (z_buffer_value - a)
Ezek után egy egyszerű MAD utasítással kiszámolható a fragment világbeli pozíciója.

Korábban már volt erről szó most azonban azt hiszem elegendő tapasztalatot gyűjtöttem a témáról.

 Mint a mellékelt képen látható a legproblémásabb (omni) shadow map egyik variációjáról van szó.

Mindössze két előnye van:

• két textúra szükséges hozzá, amelyeket be lehet csomagolni akár egybe is
• kétszer kell hozzá maximum renderelni egy mesht.

Hátrány:

• Az árnyékfogadókra per-fragment érdemes számolni az árnyékolást - deferred shading esetén ez adott.
• Az árnyékvetőknek hi-poly modelleknek kell lenniük (adott esetben geometry programot is használhatunk ennek céljából) különben nagyon hamar találkozunk a paraboloid vetítés lineáris interpolációja által okozott (meglehetősen csúnya) torzítással. Megtehetjük, hogy a lo-poly modelleket, mint amilyen általában a környezet (nagy felületek) kihagyjuk az árnyékvetésből, de annak sajnos a vizuális hatás látja kárát.

Valószínűleg az utóbbi hátrány az oka annak, hogy a gyakorlatban a (virtual) cube shadow map terjedt el kivéve talán a konzolokat ahol ennek relatív kicsiny memóriaigénye miatt az (utólagos) tesszellálás mégis megéri - a VCSM memóriaigénye közel 4x akkora, mint a dpsm-é.