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
- a cpu oldalon extra számításokat igényelnek
- 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)
- 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.
- Vizuálisan észlelhető a váltás a részletességi szintek között ("ugrálnak a vertexek" az az ún. vertex popping).
- 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.
- Mindenképp szükséges cpu oldalon kiszámolni, hogy a terep adott részletét milyen részletességi szinten akarjuk megjeleníteni.
- 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ő!
- A crackeket ún. skirtekkel tünteti el, amely egy plusz háromszög szalag a tereprészlet szélén.
- 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!
- 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!
