Terrain Processing on Modern GPU - Computer Graphics Group ...

Jedním možným řešením nedostatečného výkonu je vygenerování dočasné normálové mapy při
načítání dat. Otázkou je, k čemu by takové chování bylo. Ušetřili bychom sice nějaké místo na
disku, ale to nás dnes zpravidla tíží nejméně. My jsme se rozhodli proto vygenerovat normálovou
mapu ve fázi předzpracování současně s mapou reziduí. Vzhledem k tomu, že na tento proces
máme téměř neomezené množství času, zvolili jsme výkonově poměrně náročný postup, který
pro velké terény může trvat i několik hodin. Vychází ze stejného základu jako postup předchozí,
ale namísto aritmetického průměru normál okolních trojúhelníků se berou v úvahu jejich
prostorové úhly, které jsou použity jako váhy pro jednotlivé normály. Postup je navíc pro každý
vzorek několikrát opakován, přičemž při každé iteraci je zohledněno jinak velké okolí (použit
jiný parametr a jsou použity jiné vrcholy). Z takovýchto dílčích normál je opět spočítán vážený
průměr, pro který byly váhy hledány experimentálně, aby bylo dosaženo vizuálně dobrých
výsledků. Tímto postupem zohlední normála širší charakter terénu a ne pouze lokální chování,
zároveň dojde k jistému vyhlazení. Výsledek generování normál ukazuje Obrázek 4.12.
Výsledná normála je vždy vektor v trojrozměrném prostoru. Uchovávat všechny tři jeho
komponenty je však zbytečné. Když totiž vektor normalizujeme, můžeme původní normálu
rekonstruovat na základě pouze dvou složek a a vztahu
1.
Rovnice má sice dva kořeny, ale my víme, že je vždy kladné (to plyne z orientace terénu). Díky
tomu nám stačí uchovávat dvě komponenty. Na ty používáme stejnou blokovou kompresi jako na
mapu reziduí, pouze na každou složku zvlášť. Jedna normála je tak definována pomocí 8 bitů
(oproti původním 96). Ztrátovost komprese nás v případě normál většinou nezajímá. Ani prvotní
redukce 32bitové reprezentace komponenty do 8bitové není okem rozeznatelná.
4.5 Zpracování neomezeného terénu
Jedním z hlavních cílů, které jsme si v úvodu položili, bylo zobrazování potenciálně nekonečného
terénu, tedy takového, který nemůžeme celý najednou uložit do operační paměti. U některých
implementací dříve zmíněných algoritmů najdeme různá řešení. V (100) najdeme řešení pro LOD
nad obecnými daty, tedy nejen pro terén. Hoppe (18) rozděluje terén na čtvercové bloky a
vytváří progressive mesh nad každým blokem zvlášť. Původní implementace clipmap na texturu
terénu (51) využívala rozdělení na malé čtvercové bloky, které byly stránkovány do paměti celé
najednou, jakmile byla data vyžadována pro zobrazování. Díky progresivnímu načítání od nižších
úrovní detailu bylo vždy zajištěno, že jsou vždy k dispozici alespoň nějaká data pro zobrazování.
Rozdělení na čtverce využil i Pajarola (23) při výstavbě databáze složené z částí terénu, která
byla optimalizována pro rychlé zpracování požadavků na dvourozměrné souvislé úseky.
Lindstrom a Pascucci (37) navrhli řešení více zohledňující koherenci při čtení dat z disku i
z paměti, ve kterém využívají charakteru stromové struktury, která je procházena odshora. V
(101) najdeme jednoduché paralelizované řešení se zdrojovým kódem, které však nezajišťuje
včasnou dostupnost dat.
Protože od počátku uvažujeme kroky takové, aby bylo možné použít algoritmus do počítačové
hry, chtěli jsme se v našem řešení oprostit o těsnou vázanost na terén. Pokud má být takový
80