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

Nemrég az ati bizonyította, hogy az emberi hülyeség mindig fokozható. Lássuk most ezt:

2=6
3=7
print 2+3Első ránézésre furcsa, másodikra hülyeségnek tűnik, harmadikra már nullával osztunk pedig ez szintaktikailag helyes. Az eredmény pedig dark basic vagyis 13. Ezután már mindenki sejtheti honnan a programnyelv neve...

Nemrég kaptam a hírt Geritől, hogy:

linux alatt az új ati driverrel van pár wgl ext

Szemmel látható tehát az ati driverek fejlődése a multiplatform opengl témakörében, ami egyben talán az ati üzenete is a felhasználók számára: sose adjátok fel, mindig van hova fejlődni! Kiváncsian várjuk mikor sikerül az atinak ledönteni a linux és windows között lévő határvonalat és kirukkolnia egy hibrid driverrel; mint tudjuk mindig az első lépés a legnehezebb... és az már megtörtént...

Na, de mielőtt ebből bármit is bárki komolyan venne esdekelve imádkozzunk egy bugmentes ati opengl driverért....

Számtalanszor kutattam már domborzatkezelés után, párat sikerült is élesben kiprobálnom, de legtöbbször csak demókon legeltettem a szemem. Végeredményül azt mondhatom, hogy egyik lassabb volt, mint a másik vagyis kevésnek éreztem a teljesítményt ahhoz, hogy csak egy egyszerű terepet látok magam előtt.

Felmerül a kérdés, hogy miért... A válasz egyszerű, hiszen mindigy ugyanaz: vagy a cput vagy a gput terheli le túlzottan az adott technika. Vizsgáljunk meg elméletben egy brute force terep renderelőt vagyis jelenítsük meg az egész terepet. Józan ésszel viszonylag gyorsan rájövünk, hogy ez nem járható út, mert nagyon gyorsan leesik a teljesítmény. De mi is okozza a teljesítmény esését...

Itt is két dologra gondolhatunk: a vertexek számára ill. a megjelenített fragmentek számára. Ez utóbbi jelen esetben nem annyira számottevő hiszen ritka az olyan terep, amikor több hegy egymás után kitakarja az egész képernyőt (persze nem lehetetlen a szituáció). A terep legtöbbször a képernyő felét - két harmadát tölti ki. A nagy gond tehát a vertex szám vagyis az elküldött vertexek számát kell csökkentenünk, ami elméletileg a minőség romlásával jár együtt (elképzelhetjük e megoldás ellentétét is, amikor a cpu segítségével mindig a legkevesebb vertexet használjuk fel. Gyorsan belátható, hogy ez nagyon gyorsan a cpu erőforrásainak kimerüléséhez vezet).

Ha azonban figyelembe vesszük azt, hogy minél távolabbi egy alakzat annál kisebb területet foglal el a renderelési képe és kevesebb részlet lesz belőle látható (extrém távoli esetben egy alakzat már csak egy pontnak tűnik). A kevesebb részlet szerencsére kevesebb vertexet is igényel vagyis az elméleti minőségromlás gyakorlatilag észrevehetetlen lesz. Ezt a jelenséget használja ki a terrain lod vagyis a terep távoli részeit alacsonyabb részletességi szinten jeleníti meg. Ezen technikáknak több hátrányuk is van. Nézzük talán a legfontosabbakat

1. a cpu oldalon extra számításokat igényelnek
2. a változó vertexszám és részletesség miatt a domborzat folyamatosan változik (emiatt adott tárgy pl eltünhet a domborzat alatt vagy épp lebeghet felette)
3. gyakorlatilag lehetetlen per-vertex árnyalni

Alaposabban szemügyre véve a lod technikákat kiderül, hogy csoportjuk van: az ún. continuous lod ill. a discrete lod. A kettő alapjaiban különbözik, mert az első realtime generálja a különböző lod szinthez tartozó geometriai és topológiai információt az utóbbi viszont előre letárolt adatokat használ. Természetesen mindkettő igényel cpu oldali számításokat azonban a c-lod sokkal többet, mint a d-lod. Esetemben ezek rögtön ki is estek a mezőnyből (ide tartozik a ROAM, a diamond terrain, a c-bdam, néhány quadtreet használó technika stb). A d-lod már sokkal cpu barátibb hiszen jóval kevesebb számolást igényel (ebbe a témakörbe tartozik a chunked lod ill. számos geomipmap megoldás), de a c-loddal szemben van egy nagy hátránya, amelyet már a nevük is jelez. A c-lod egy folyamatos ebből eredően egy sima átmenet képez a különböző részletességi szintek között míg ez a d-lodnál hiányzik. Szokás szerint ez ismét problémákat vet fel.

1. Vizuálisan észlelhető a váltás a részletességi szintek között ("ugrálnak a vertexek" az az ún. vertex popping).
2. A különböző lodhoz tartozó terep darabok szélei nem illeszkednek egymáshoz és ún. crackek (törések, hiányok) látszódnak.

Most pedig nézzük, hogy az eddig felsorolt problémákat hogyan orvosolja a chunked lod.

1. Mindenképp szükséges cpu oldalon kiszámolni, hogy a terep adott részletét milyen részletességi szinten akarjuk megjeleníteni.
2. Ahhoz, hogy a vertex pop ne legyen feltünő két részletességi szint között a geometria interpolálására van szükség, amely azonban gpu oldalon is elvégezhető!
3. A crackeket ún. skirtekkel tünteti el, amely egy plusz háromszög szalag a tereprészlet szélén.
4. A domborzat megváltozását nem képes kiküszöbölni, de az alapvetően minden lod technikára igaz. Hozzá kell tennünk ez a jelenség csak távoli területeken jelentkezik viszont ott már z-fight hibákat okozhat!
5. Sajnos az árnyalásra nem ad megoldást, de viszonylag könnyen kitalálható, hogy mivel per-vertex alapon nem tudunk árnyalni (hiszen a vertexek száma és pozicioja folyamatosan változik), ezért a felület normáljait előre el kell tárolnunk egy texturában.

Nem esett szó még a domborzat textúrázásáról. Mivel legtöbbször (nagyon) nagy felületről van szó egy (nagyon) nagy textúra használata nem lehetséges. A chunked lod erre egy texture quad treet alkalmaz, ahol minden egy részletességi szintű terep részlethez tartozik egy textúra (ilyen elven tárolhatjuk az árnyaláshoz a normal mapeket is!). Hasonló probléma megoldására született az ún. megatexture is, amely egy nagyon nagy textúrának mindig csak az éppen szükséges részét tartja a memóriában és használja fel.

Végszó:

Olyan megoldást kerestem, amely minimális cpu igény mellett maximális teljesítményt és látványt tud nyújtani. Emiatt szerintem érdemes a chunked lodot vagy ahhoz hasonló technikát használni - nagyon jól optimalizálható (vbo, strip, interpolálás gpuval) és cpu oldalon nagyon kevés számítást igényel!

Mától új himnusz v ars poeticám van, nem igazán tudom minek nevezzem, mindenesetre magaménak érzem....

Nem nyílt soha út elém
Csábító szóból bizony volt elég
Bár volna jel, mely hozzám majd elér
Hol van a föld? Vár-e jövő rám még?

Pocahontas 2 - Where Do I Go From Here

Kicsit el van ferdítve, de a magyar szöveg is sokat mond az életről...

vagyis különös dolog a (dal)szöveg fordítás: visszabontani a mondatokat a mondanivalóig, a gondolatig és az alapján egy új szöveget készíteni, más szavakkal más rímekkel úgy, hogy a tartalom ne sokat változzon - igazi, emberi varázslat (már ha "jó" a fordítás)....

A mai estén megpróbálok némi rendet rakni az enginem grafikai része körül vagyis megpróbálok választ kapni azokra a kérdésekre, hogy mit, hogyan, mikor, miért (nem) és miért éppen úgy rendereljek. Mindehhez szükséges tisztázni, hogy mi is szükséges a rendereléshez. Az első válasz természetesen az, hogy valamilyen (térbeli) geometria adatra (modellre) van szükség. Önmagában a modell nem tud annyira részletes lenni (vagy túl sok adat kellene ahhoz), hogy tökéletesen visszaadja azt a látványt, amelyről az készült. A megfelelő hatás eléréséhez textúrát feszítünk a modellre vagyis egy megadott kép egy részletét ráillesztjük rendereléskor egy háromszögre. Némi fizikával megfűszerezve a témát, használhatjuk itt az albedó kifejezést (adott felület adott hullámhosszon vett elektromágneses hullám visszaverő képessége - vagyis milyen színűnek látjuk...): a felhasznált kép adott pontossággal tárolja egy felület albedóját.

Tehát kiindulási pontnak tekintsünk egy képet (image), amelyet egy pixel tömbként tömörítve vagy tömörítés nélkül tárolunk. Ezt a többnyire 2d-s pixel tömböt fogja a videokártya felhasználni a renderelés során textúraként, amelynek elemeit már texeleknek hívjuk. Szerintem azonban létezik egy köztes, "elméleti" állapota a textúrának, amelyet mapnek nevezünk. Ez már utal az adott textúra felhasználási módjára (maga a textúra ritkán utal a felhasználási módjára) ill. magára a renderelési technikára vagyis megadott funkciónak megfelelő adatokat tárol, megfelelő formában. Egy adott felületnek megfelelő map csoportot talán hívhatunk materialnak, mivel ugyanazt a felületet írják le, de eltérő szempontokból. Azonban azt, hogy mik ezek a szempontok a renderelési technika befolyásolja tehát célszerűbbnek látom a mapeket a renderelés alapján materialokba rendezni és utána azokat példányosítani felületek alapján.

Azt hiszem a legtöbb renderelési típushoz szükséges a felület albedóját leíró map. Hogy hogyan tároljuk az egy külön történet itt csak annyit érdemes megemlíteni, hogy manapság 3 csatornán (RGB) tároljuk. Talán ennek a mapnek létezik a legtöbb neve: a leggyakoribb a diffuse map, de találkozhatunk vele color mapként, diffuse albedo mapként és ritkán, de helytelenül decal mapként is.

Viszonylag egyszerű a felhasználása a mask mapnek közismertebb nevén alpha masknak. Ez egy olyan képnek felel meg, amelynek pixelei egy logikai változót jelentenek azaz eldönti, hogy azt a renderelés eldobja vagy sem. Elméletileg elég egy bit egy pixel tárolásához. Az alpha mask elnevezés onnan ered, hogy nagyon sokszor egy textúra alfa csatornájába töltik fel ezt a mapet (főleg hatékonysági szempontok miatt mivel a fenn említett eldobás így alpha testtel könnyen elvégezhető).

A mask mappel némileg rokonságban áll a transparency map ill. annak ellentéte az opacity map. Az előbbi egy felület átlátszóságát, az utóbbi a felülelet átlátszatlanságát tárolja intenzitás értékként.

Az egyszerűen felhasználható mapek közé tartozik még az emissive map más néven glow map. A felület színét módosítja oly módon, hogy hozzáadódva a diffuse maphez fénykibocsájtó tulajdonságot kölcsönöz neki. Általában RGB csatornákban tárolják, ritkán egy egycsatornás intenzitás értékként.

Létezik még ambient map, amely általában a modell elkészültekor készül el többnyire egy raytracer algoritmussal.

Most következzenek azok a mapek, amelyek felhasználása már bonyolultabb és nem ennyire egyértelmű. Elsőként említsük meg a height mapet félrevezető nevén bump mapet. Ez a felület síkjához mért magasság különbségeket tárolja intenzitásként. Használata sokrétű: készülhet belőle normal map, de felhasználható közvetlenül rendereléshez is.

A normal map a nevéből adódóan normál vektorokat tartalmaz, amelyek a felület normálvektorához képest relatívak vagy abszolút értelemben vett, a világban mért normálokat tárolhat. Relatív vektorok esetén már elegendő két csatorna is ehhez ellenkező esetben mindenképp három csatorna szükséges.

A specular map a felület fényvisszaverő képességét tárolja általában egy csatornán, de specular color mapként RGB csatornákon is tárolhat színt. Ebbe a témakörbe tartozik még a glossiness map, amely a felület simaságát veszi figyelembe bár én nem látom különösebb jelentőségét.

Valószínűleg bárki, aki 3d-s játékot vett párszor a kezébe és kutatott kicsit utána könnyen találkozhatott a "csontanim" kifejezéssel. Tudomásom szerint az első játék, amely ezt alkalmazta a half life első része volt. Összehasonlításul az addigi játékok ún. keyframe alapú animációt alkalmaztak vagyis minden lehetséges mozdulat előre ki volt számolva és így eltárolva. Az animálási folyamat mindössze egy lineáris (esetleg négyzetes) interpolációt igényelt két keyframe között. Ez a cpu számára nem jelentett túlzottan nagy terhet; hátránya abból eredt, hogy minden(!) lehetséges mozgásformát és (jobbára azok kombinációit is) le kellett tárolni. Köztes megoldást jelentett a quake3 modell formátuma, amely a modellt több részre (általában 3: lower, upper, head) osztott és ezek ún. tagekkel kapcsolódtak egymáshoz függetlenül szabadon kombinálhatóan.

Mint említettem az első áttörést a half life hozta, amely már szabad jobbra-balra forgást tett lehetővé úgy, hogy a modell egy egységes polygonháló volt és az animáció fázisait realtime számolta a cpu. Ehhez két dologra volt szükség, amely mindmáig a csontvázra épülő animáció alapját jelenti:

• egy, a biológia csontvázhoz hasonlóan felépített csontvázra, ahol a csontok egy hierarchia szerint kapcsolódnak egymáshoz
• az ehhez a csontvázhoz készült modellre, amelynek vertexei tárolnak plusz információkat: melyik csonthoz tartozik és mekkora arányban hat a vertexre az adott csont (ezen arányok összege értelemszerűen 100%). Amikor minden csont alaphelyzetben van, azt állapotot hívják base pose-nak.

A modell aktuális megjelenését valósidőben kell ki és újra számolni a csontok térbeli pozíciója, orientációja és hierarchiája alapján. Érdemes ezt ugy elképzelnünk, hogy magát a csontvázat animáljuk és számoljuk ki a térbeli helyzetét, majd ezt a csontvázat "alkamazzuk" a modellre. Ezt az "alkalmazást" nevezik vertex skinningnek, mert a hatása olyan, mint amikor a bőr mozog egy testen.  Mivel minden frame-ben újraszámolhatjuk a csontvázat ennek köszönhetően ez a technika széleskörű manipulációt tesz lehetővé. Egészen odáig, hogy fizikai szimulációt segítségül hívva inverz kinematikát is építhetünk rá. Ha jól tudom az első, ezt leginkább kihasználó játék a trespasser volt.

Animációtól ill. programtól függ, hogy egy vertexhez hány csont tartozhat. A half life esetén ennek értéke mindössze egy volt (hasonlóan a milkshape formátumához). A cpuk teljesítményének növekedésével folyamatosan nőtt ez a szám: a ghoul2 motor már max. négyet engedélyezett míg a doom3 engine motor már nem tartalmaz korlátozást.

A vertex skinningnek létezik hardveres implementációja (matrix palette skinning) (amelyet a vertex processor végez) hiszen ez a technika nagyszerűen általánosítható. Ha belegondolunk ez az animációs technika mindössze egy "mátrix halmazt" (matrix palette) és megfelelő "vertex - mátrix" súlyozott összerendeléseket igényel, amelyekből  - átadva ezeket a gpunak - vertex feldolgozáskor kiszámolható a vertex pozíciója.

Igen elvetemült formája a "csontanim" hardveres implementálásának az ún. render to vertex buffer (amelyet viszont a fragment processor végez). Ilyenkor a szükséges adatokat többnyire float textúraban tároljuk és egy elegendően nagy téglalap renderelésekor egy fragment programmal végeztetjük el az animálást, amely eredménye a color bufferbe kerül (vagyis itt is szükséges float pontosság).  Végeredményül ezt a buffert közvetlenül ( ún. superbuffer segítségével) vagy közvetett módon (fbo-pbo-vbo útvonalon esetleg vertex texture fetch, bár ez jelentősen lassabb) felhasználjuk, mint vertex buffert. Tudomásom szerint ez a technika nem igazán terjedt el a gyakorlatban.

ismét túlteng bennem a világérzés:

Úgy élj, hogy a képességeid ne a határaid, hanem a lehetőségeid legyenek...

Mai agymenésem a vertexenként elküldött adatmennyiség csökkentéséről szól. Ezen adatokat -az új terminológia alapján- vertex attribútumoknak hívjuk, amelyeket 4 db lebegőpontos számnégyes reprezentálja és legalább 9 db van belőlük. Míg a régi terminológiában minden egyes attribútum szerepe és neve meghatározott volt, az újban már csak index jelzi őket. Ezek az alábbiak: 

Megjegyzendő, hogy textúra koordinátákból annyi darab lehetséges, ahány texturázó egység elérhető.

A táblázatból látható tehát, hogy vertexenként 9*4 adatot tudunk elküldeni a gpunak, amiből 4-t mindig kötelező elküldenünk. Természetesen minél több adatot küldünk vertexenként annál lassabb futásra számíthatunk hiszen

1. az adatot el kell juttatni a vertex feldolgozónak
2. a vertex feldolgozónak el kell végeznie a szükséges műveleteket

ezért törekednünk kell ezek mennyiségének csökkentésére. Erre többféle módszer kínálkozik.

Az első esetben legegyszerűbb, ha csökkentjük a kirajzolandó háromszögek mennyiségét - low poly modellek használata - azonban ez jelentős mértékű minőségromláshoz vezethet.

Hatékonyabb módszer a háromszögek szalaggá történő rendezése, amikor a háromszögek számát nem csökkentjük csak a kirajzolásukhoz szükséges vertexek számát probáljuk meg csökkenteni.

Bizonyos esetekben még tovább csökkenthetjük az adataink számát

• ha "becsomagoljuk" őket. Ehhez viszont szükséges a vertex program megléte, amellyel a kicsomagolást el tudjuk végezni. Például: vertexenként elküldünk egy pozíciót (xyz) egy színt (rgb) és egy textúra koordinátát(st). Ez összesen 8 db számot jelent vagyis ez a 3 adat pontosan elfér 2 attribútumban három helyett! A kitétel csak annyi, hogy a 0. attribútumot mindenképp használnunk kell, de hogy melyik adatot hova és hogyan pakoljuk az már tőlünk függ.
• ha csökkentjük a bitek számát, amelyen tároljuk az adatainkat. Például: a vertex pozíció néha elég shorton (2byte) tárolni, de a -1.0...1.0 ill. 0.0....1.0 tartományba eső adatok tárolására sokszor elegendő egy byte is!

A második eset optimalizálására maga a gpu kínál fel egy lehetőséget ún. vertex cache néven. Működése a vertexindexeken alapul vagyis csak indexelt vertexek renderelése esetén kerül sor a felhasználására. A gpu a vertex cache-ben képes bizonyos számú, már feldolgozott vertexet az indexek alapján tárolni és ha ismételten ugyanolyan indexű vertexet küldünk el a gpunak akkor az itt tárolt adatot fogja újra felhasználni megspórolva a feldolgozást.

Természetesen a vertexindexek megfelelő sorbarendezésével mi is sokat tehetünk a vertex cache optimális kihasználása érdekében - megtehetjük ezt akár háromszög szalaggal is és így nemcsak a vertexek számát, hanem azok feldolgozásához időt is csökkentjük, de optimalizált háromszög lista is alkalmas e célra.

Tudomásom szerint még öt hardver szintű vertex optimalizálási technika létezik.

1. Az első az ún. vertex buffer object, amikor minden statikus információt (vertexek és vertexindexek) feltöltünk a video memóriába így ezen adatok elérésének ideje drasztikusan lerövidül. Animált, dinamikusan változó vertex adatok esetén javasolt a dupla bufferelt vbo. Ilyenkor 2 vbot tartunk fenn a renderelés számára: az egyikbe beírjuk a friss adatokat, a másikból renderelünk majd a következő frameben felcseréljük a 2 vbot.
2. A vertex adatok átküldését optimalizálhatja a draw_range_elements, amely a függvénnyel megadott indexeken kívül eső vertexeket nem küldi el a gpunak.
3. A compiled_vertex_array esetén az adott vertex tömböt lezárjuk (lock) így azokat vagy a feldolgozott eredményeket a gpu "compile"-olni(?) tudja.
4. Néhány esetben előfordulhat, hogy ugyanazzal a vertex tömbbel, több geometriát is akarunk renderelni. Erre az esetre készült a multi_draw_arrays.
5. Instanced geometry, amelyet viszont még nem használtam...

Nem szabad azonban elfelejtenünk, hogy a vertex optimalizálás legalapvetőbb módszere a csak látható elemek renderelése (frustum cull, occlusion cull stb)!

- adott textúra átlagszínének kiszámítása hardveresen:

semmi mást nem kell tennünk, minthogy a textúra szűrését lineárisra állítanunk és lekérdeznünk a legmagasabb lod szintet - ilyenkor a textúra mérete 1x1 vagyis egyetlen texelt tartalmaz csak, ami a lineáris szűrés következtében az összes texel színének az átlagát fogja tartalmazni.

Ebből a színből számolhatunk fényességet vagyis egy kép fényességét ami pl. hdrhez kitűnő