Hála Geri kitartó segítségnyújtásának találtunk egy érdekes hibát az enginemben. Mint az kiderült több helyen is írják, hogy ha a rendereléshez küldött adatok közül egyik nem VBO-zott, akkor semmit sem szabad VBO-zva küldeni. A régebbi kártyák különösen érzékenyek (fps:600 -> 40) erre.
UPDATE!
Frissült a csomag: két exe található a csomagban két különböző fizikai engine-re épülve; egyik PhysX-et használ, a másik Bullet-et.
Ismét elérkeztem egy következő állomáshoz. Elmúlt időszakban a csontanimmal foglalkoztam és ez a demó ennek eredményét szeretné bemutatni. Sok próbálkozás után a CPU-n és szálban történő dupla bufferelt VBO nélküli megoldás mellett döntöttem.
Mr. Box (ahogy fpeti nevezte) most már kikerült a főszereplői státuszból helyette a Quake4 berserkerét láthatjuk (néhány részlet lemaradt róla, mert csak az első mesht csatoltam a szereplőhöz). A "pálya" egyik részén vannak a szereplők, a másikon a szokásos "meglepetés": ládák és hordók.
Mozgatás: még mindig a szokásos QWASD + egér, de az egér mozgatáshoz már csillapítás is társul.
Kamera közelítés/távolítás: 3/2 gomb.
Szereplők közötti váltás: TAB.
Ismert hibák: Az animáció messze áll a tökéletestől egyelőre "működik"; nálam néha fagyott (interpolátor túlcsordul):3
A szereplőknek nincs intelligenciájuk csak rohangálnak faltól-falig.
A fizika is csak "van" nincs kiegyensúlyozva.
Az editor fagy.
Config.ini:
vsync_enabled=true / false;
physics_accuracy=3; - fizika iterációk száma framenként
physics_hardwareEnable=false; - nincs hatással
window_depth=24;
window_fullscreen=true;
animation_fps=30; - az animációs szál frissítési frekvenciája - FONTOS! Két mag/CPU esetén ezt fel lehet venni 60-ra egyéb esetben érdemes ezt alacsonyan (30) tartani; jelenleg nincs egyszálas kód.
texture_quality= 2 - 0-low, 1-medium, 2-high, 3-ultra high, 4-oldschool
MODE=1; - jelenleg csak az ablak méretére van hatással ( window_width=800; window_height=600;)
Link: www.inspekcio.hu/indigo_illusions/demos/sakura_demo_2010_03_14.zip
Két klasszikus másolás-fáradtan hiba.
_cica* dorombol (_cica* cica)
{
_cica *new_cica = new _cica;
new_cica.Új (new_cica);
}
void Olvas (_cica *cica, _io *io)
{
cica->Ír (io)
}
Mindkettő után csak pislog az ember, hogy mitől kicsi a buffer avagy miért túl nagy a lefoglalni kívánt terület :3
Az elmúlt időben sokat foglalkozva a csontváz alapú animálással sokféle optimalizálási lehetőség felmerült. Legtöbbjük csak korlátozottan vagy speciális helyzetekben volt alkalmazható. Utolsó választásom a probléma többszálúsításra esett mivel manapság egyre inkább elterjedtté válnak a két- ill. többmagos cpu-k.
Ha teljesítményfokozásra szeretnénk használni a másik szálat akkor óvatosnak kell lennünk. Előfordulhat ugyanis, hogy a kétszálas megoldás lassabb lehet, mint az eredeti változat. Különösen igaz ez akkor, ha a két szálat szinkronizálnunk kell várakozás beiktatásával vagyis úgy tünik, hogy a szinkronizálás ezen formája teljesítményfokozás céljából mindenképp kerülendő (bár nem ástam magam mélyre a szálazás rejtelmeibe a szinkronizálás másfajta lehetőségeiért).
Azonban viszonylag egyszerűen kiiktathatjuk a várakozás szükségességét, ha a két szál által használt adatot dupla buffereljük. Mint legtöbb esetben ez itt is azt jelenti, hogy az egyik szál az egyik bufferból csak olvas, míg a másik szál a másik bufferbe csak ír. Amikor a másik szál végzett az írással (mivel gyakorta ez a lassabb művelet) akkor a buffereket felcseréljük. Így sosem fordulhat elő, hogy az írás alatt álló buffer kerül olvasásra. Megjegyzendő, hogy a bufferváltás csak egy utasításból állhat! Ellenkező esetben a bufferváltás közben bizonyos ideig ugyanazon buffert használhatja vagy ugyanazt az adatot láthatja a két szál (ezen hiba felismerése majdnem 2 órámba került).
Két gyakorlati alkalmazás az esetemben:
Ismét elérkezett az idő, hogy foglalkozzam a csontanimmal. Szerencsére a formátumom még mindig megállja a helyét, a kódom 90%-ban újrahasznosítható volt tehát a md5mesh/md5anim importáló gyorsan a rendelkezésemre állt.
Első dilemma
Azt mindenki tudja, hogy adott frame-hez tároljuk a csontok térbeli pozícióját és orientációját. Ennek azonban két változata lehetséges: mátrix alapú (későbbiekben M) ill. kvaternió + pozíció (későbbiekben QP) alapú. Az előbbi 12 floatot jelent az utóbbi 7 floatot. Interpoláláskor jelentkeznek a jelentős különbségek: M esetben egyszerű lineárisan interpolálni viszont az eredményt újranormalizálni kell. QP esetben - ami az ajánlott eset is - 3 floatot kell lineárisan interpolálni, a kvaterniót azonban szférikus-lineárisan kell interpolálni (avagy SLERP). A SLERP az első kritikus rész az animációban vagyis érdemes a SLERP implementációjára egy gyors megoldást keresni.
Második dilemma
Második kritikus rész a csont-vertex transzformálás. Ennek központi eleme, amikor adott vertexre alkalmazzuk a rá ható csontok QP-ját. Itt is két módszer lehetséges: közvetlenül a QP-t alkalmazzuk a vertexre vagy előbb a QP-t átalakítjuk mátrixszá. Tapasztalataim szerint az utóbbi a hatékonyabb. Megfigyelhető, hogy általánosságban gyakori az az eset amikor egy vertexre csak egy-kettő-három csont hat. Ezeket az eseteket külön érdemes kezelni, mert ez is sebesség kritikus rész.
Harmadik dilemma
A harmadikus kritikus rész már a rendereléshez tartozik. Tapasztalom szerint a vbo dupla bufferelése az esetek többségében nem kifizetődő - csak akkor mértem sebesség növekedést, ha legalább 4x rendereltem ugyanazt a modellt.
Konklúzió
Célszerű megoldani, hogy az adott animációs fázisban lévő modellt újrahasznosítsuk: rengeteg számolást spórolhatunk valamint nagyobb eséllyel kihasználhatjuk a dupla bufferelt vbo előnyeit is.
Sokáig nem gondoltam bele programozóként milyen is volt a 3D programozói világ gyorsítókártyák nélkül/kezdeti gyorsítókártyákkal. Mai szemmel nézve a különböző felületeken megjelenő effektek nem tűnnek bonyolultnak azonban a kezdetek kezdetén ez nem volt annyira egyszerű. Olyan effektekre gondoljunk, amely mellett/alatt még látszik az eredeti szín/diffúz textúra, mint pl. tükröződés, erőtér effekt, villám, decal stb. Gondoljunk bele ezekhez az effektekhez mire is van szükség: két vagy több különböző textúrára, amelyek ugyanazon felületen/modellen jelennek meg. Ennek megvalósítására két lehetőség kínálkozik: az ún. multitextúrázás ill. multipass rendering(többmenetes renderelés). A kezdetek kezdetén azonban még nem létezett az első megoldás így a második lehetőség jöhetett csak számításba. Azonban a multitextúrázás meglétének ellenére még ma is sokszor előfordul, hogy ugyanazon háromszögeket többször jelenítünk meg - ha nem elérhető elegendő textúrázó egység vagy egy különálló (és/vagy speciális) renderelési fázist igényel az adott effekt.
A megvalósítása az alábbiakat igényli.
A technika nagy hátránya, hogy
Megjegyzendő, hogy a hatás megbolondítható a glColorMask funkcióval vagyis ilyenkor bizonyos rétegek adott színcsatornát írhatnak felül.
Természetesen a multipass rendering kifejezést nem csak ilyen esetben használjuk. Gyakran előfordul, hogy egy renderelési fázis eredménye közvetlenül nem jelenik meg a színbufferben pl. offscreen renderelünk vagy stencil bufferbe.
Az árnyékvetés elve
Az elv egyszerű. Képzeljük el a fényforrást, mint egy kamera valamint a nézeti sugarakat fénysugarakkal helyettesítjük. Így a kamera közelsíkjában képződő képen a fényforrás által látott tér jelenik meg - a rendereléshez használt vetítést a fényforrás típusa határozza meg. Mivel a renderelés közben a mélység tesztet bekapcsoltuk a kapott végeredmény mélység buffere azt az információt fogja tárolni, hogy a fény terében lévő mely térbeli pontok esnek a fényforráshoz a legközelebb és azok milyen távolságra vannak tőle. Ezt a gondolatmenetet folytatva rájövünk, hogy hogyan is keletkezik ebből árnyék. A jelenetet még egyszer renderelve immáron az eredeti kamerából egy egyszerű összehasonlítással el tudjuk dönteni, hogy egy adott térbeli pont és a fényforrás között elhelyezkedik-e egy másik pont - ha ez a feltétel teljesül akkor az adott térbeli pont árnyékban van. Ehhez az összehasonlításhoz két dologra van szükségünk: az adott pont fényforrástól való távolságára és az előző menetben kapott mélység bufferre, amely szintén a fényforrástól mért távolságot tartalmaz. Ha az adott pont távolsága nagyobb, mint a mélység buffer megfelelő helyéről (lásd később) vett távolság érték, akkor az adott pont árnyékban van.
A renderelés tehát mindenképp két menetben zajlik.
Elsőként a fényforrás által látott teret rendereljük le és a vetítés során felhasznált mátrixokat és mélység buffert eltároljuk.
Második menetben a vertex feldolgozáskor két vertex transzformációt hajtunk végre (ne felejtsük, hogy a vetítés, amely egy a transzformációk közül mindössze vertexek és mátrixok összeszorzását jelenti):
A vetítések során kiszámolt Z koordináta (ha textúra koordinátában gondolkozunk akkor Z komponens helyett R komponens elnevezés az elterjedt) tartalmazza egyik esetben a kamerától való távolságot másik esetben pedig a fényforrástól való távolságot. Végül nincs más dolgunk csak a mintavételezés a mélység bufferből, a két távolságot összehasonlítani és ezt felhasználni a renderelésben.
Árnyékvetés texture environment combinerrel
Ez az árnyékvetés számos hátránnyal rendelkezik.
Árnyékvetés natív hardverrel
Szerencsére ez a megoldás az előző árnyékvetés összes hátrányát kiküszöböli.
Az OpenGL szempontjából nézve ez az alábbi extension-öket jelenti.
Mindkét technológiát az NVidia fejlesztette ki.
Az első változat ("mélységi teszt") a scissor teszthez hasonlóan működik viszont nem képernyőkoordinátákra, hanem mélység komponensre értelmezi a vágást: megadott zmin és zmax értékeken belül engedi át a fragmenteket. OpenGL alatt GL_EXT_depth_bounds_test / GL_NV_depth_bounds_test néven elérhető.
A második változat ("kétoldalas stencil teszt") a stencil tesztet gyorsítja fel - külön-külön megadható a stencil beállítás a GL_FRONT és GL_BACK orientációjú poligonokra vagyis stencilezéssel történő CSG műveletek egy lépésben elvégezhetők. Azonban fontos tudni, hogy a renderelés közben a fragmenteket duplázza a GPU így csak a vertexek többszöri elküldését váltja ki. Kötelező együtt használni a GL_EXT_stencil_wrap-pel mivel összetett CSG eljárásnál könnyen alulcsordulhatnak a stencil értékek. Az ehhez tartozó OpenGL extension sztring: GL_EXT_stencil_two_side.
Megjegyzendő, hogy hasonló képességet az ATI is kifejlesztett (GL_ATI_separate_stencil néven) azzal a különbséggel, hogy nem az összes stencil beállítás konfigurálható orientációnként. Az újabb ATI kártyák azonban már az EXT verziót is támogatják.
Ismét eltelt egy hét és ismét egy lépéssel közelebb a cél felé.
Az alábbi demó egy "valódi" helyszínt tartalmaz, két "főszereplővel" alias ládával, amelyek között "tab"-bal lehet választani. A "p" billentyű lenyomásával az újonnan implementált hullámfüggvények (eredménye) lesznek láthatók. A mozgás QWASD + egér.
A pályáról kirepülni nem tanácsos...
A renderelés most FPP-n keresztül történik tehát elvileg régebbi kártyákon is futtatható.
Sajnos a portál rendszer működése még nem tökéletes, de vizuális hibákat nálam nem okozott ellenben stack overflow-t igen. Ezen eset lekezelése során "potentially portal overflow" figyelmeztetés jelenik meg a konzolon.
A zip file elérhető innen: www.inspekcio.hu/indigo_illusions/demos/sakura_demo_2010_02_07.zip
Az esti órákban ismét tettem egy felfedezést. Az eddig is nyilvánvaló volt, hogy a Doom3/Quake4 engine portálokkal dolgozik az viszont kevésbé, hogy a .proc file-okból ezen információkat egyértelműen ki lehet nyerni.
Szerencsémre az ottani adatok teljes egészében felhasználhatók minimális konverzióval és kiegészítéssel az enginemben. Remélhetőleg a konverter elkészítése sikerrel jár és ez akkor jelentős mértékben megkönnyíti a tartalom készítést a további következményekről nem is beszélve... ^^
Ráadás, hogy kb. 20 perc alatt elkészült a szöveg parser és még kb. 10 perc volt az adatok beolvasása.
Megjegyzés: a Doom3 .proc file-ok egyszerűbb felépítésűek így a Quake4 .proc file-ok kicsivel más feldolgozást igényelnek.
