GeoMipMapping

[perry]

Aktuálně se chystám implemtovat geomipmapping do svého terénu. Jen bych rád věděl, že jsem systém pochopil dobře

1) Mám vytvořeny jednotlivé chunky (využívám je v quadTree Cullingu) - takže např. terén dělený na 16 x 16 dílů (terén je 257 x 257)

2) pro bloky blíže kamery zvolím větší LOD -> určím vzdálenost středu chunku od kamery

3) asi bych si pro každý LOD udělal vlastní Index Buffer (IB) a kreslil podle příslušného IB
Aktuálně mám systém udělaný tak, že přepínám draw cally podle chunk. Tzn. že jeden chunk vykreslím jedním draw callem. Takže mám IB naplněný nikoliv po řádcích, ale speciálně si přepočítávám pozice indexů podle chunků.

4) Nějakým způsobem vyřešit praskliny mezi LODy - a tady mám trochu problém Napadlo mě třeba dynamicky upravit obsah Vertex Bufferu (VB), nebo změnit IB pro menší z LODů.. ovšem popravdě tady mám trochu mezeru ve stylu implementace.

Pozn: Pracuji s DirectX 9

[johnnash]

GeoMipMapping jsem delal takze napisu par postrehu.
Ad 1,2,3) Tohle mam vsechno stejne.
Ad 4) S timhle jsou fakt problemy, takze...
Rekneme, ze si definuju pro aplikaci maximalni LOD 4. Pak pro kazdy blok mam 5 IB ktere poslu na kartu, plus jeden sdileny IB(v pameti) ktery slouzi pro reseni okraju.
Do tech 5 IB predpocitam indexy tak, ze pri danem LODu vynecham vzdycky krajni vrcholy. Tohle je vsechno preprocessing.

Sdileny IB pak plnim pri vykreslovani podle aktualniho stavu. Je dulezite, ze kazdy blok vedle sebe muze mit ruzne LODy takze nejaky predpocitani by nebylo prilis realizovatelne.
Pred vykreslenim zjistim jake LODy maji sousedi aktualniho bloku a vygeneruju indexy do sdileneho IB.

Nevyhoda je, ze na kazdy blok vychazi 2 draw cally.
Jeste se to da usporit tak, ze pokud blok vedle sebe nema rozdilne LODy tak ho vykreslit na jeden draw call(coz muzeme protoze nevznikaji zadny diry).

Ad dalsi veci)
pokud budes pouzivat per vertex nebo per pixel osvetleni tak narazis pri zmene urovne LODu na dost viditelny zmeny(coz je pochopitelny).
Jediny zpusob jak se mi to podarilo vyresit bylo pouziti jedne velke normal mapy pro cely teren.

[perry]

[johnnash]

Jo sorry s tema IB jsem to blbe napsal, je to pro cely teren.
Ted kdyz na tim premyslim tak ten preprocessing by mel jit taky vpohode, uz si ani nevzpominam proc jsem ho zavrhnul.

[]semo[]

Taky jsem to programoval, použil jsem pro jeden LOD chunku vždy 1 centrální buffer index buffer a pak několik adaptujících ("šicích"), který uměly z LODu N adaptovat na LOD N+1. Nedávno jsem nad tim všim uvažoval a dneska bych to asi udělal jinak. Předpočítal bych pro každý lod všechny kombinace index bufferů a tak bych mohl kreslit každý chunk jednim drawcallem. Jen by se z nějaký matice zvolil ten správný index buffer. Takhle surově by to bylo náročný na paměť, ale dalo by se razantně optimalizovat:

1) zavést pravidlo, že LOD N se může adaptovat pouze na N+1 a N+2 (nebo jen N+1)

2) použít 16 bit a 8 bit integery

3) Zkomprimovat index buffery nějakou vlastní velmi jednoduchou kompresí, která vychází ze znalosti dat. Například centrální neměnná (neadaptující) část bufferu může být uložena parametricky. V případě požadavku na určitý index buffer, by se tento mohl rozkomprimovat (např. paralelně, nebo po částech přes několik snímků) a se spožděním použít. 1-5 framy zpoždění nevadí. Rozbalené buffery by zůstaly v nějaký cache. Předpokládám, že v praxi nebude potřeba mít stále všechny IB zobrazené.
Tenhle bod 3 bych zavedl až v případě nouze.

EDIT: a samozřejmě 4) použít triangle stripy
_________________
Kdo jede na tygru, nesmí sesednout.
---
http://www.inventurakrajiny.cz/sipka/
Aquadelic GT, Mafia II, simulátory

[perry]

Jaký může být výkonostní rozdíl mezi Stripy a Listy ? Zatím mám Listy, ale co jsem zkoušel kreslit, tak jsem zásadní neviděl (ale možná to bylo jenom tím, že jsem kreslil málo věcí)

[]semo[]

V tomto případě výkonostní ne, ale ušetříš tu paměť pro index buffery. Kdysi to prý šetřilo i výkon, protože se transformovalo míň vertexů, ale dneska zůstanou ty poslední ztransformovaný vertexy v cache, takže rozdíl neni (máš-li ty stejný vertexy v bufferu * nějak rozumně blízko u sebe).
Pasáž o výkonu ber s rezervou, moc jsem o tom nečetl.

EDIT: *chtěl sem říct indexy odkazující se na stejný vertex
_________________
Kdo jede na tygru, nesmí sesednout.
---
http://www.inventurakrajiny.cz/sipka/
Aquadelic GT, Mafia II, simulátory

[perry]

Napadlo mě to "šití" udělat takhle



Budu potřebovat navíc 1IB pro "šicí stroj". Přičemž se bude vždy usekávat z většího LOD (takže LOD 1 se vykreslí celý a v LOD2 se nahradí 1. řádka a sloupec šicím)

Přikláním se spíš k volbě b), protože nepotřebuju ten "šicí roh", ale nevím jak bude vypadat výsledek

[johnnash]

Tohle mi prijde moc komplikovany, jednodussi je urcite "sit" z vrcholu v bloku s vyssim detailem.
Mam to nejak takhle

[]semo[]

A já zas takhle :-)


Nechci vnucovat, ale máš pak krásně oddělený ty adaptivní a centrální buffery.
_________________
Kdo jede na tygru, nesmí sesednout.
---
http://www.inventurakrajiny.cz/sipka/
Aquadelic GT, Mafia II, simulátory

[perry]

[perry]

Takže nakonec jsem zvolil "kompromisní řešení" poskládané ze všeho možného




Nepotřebuju žádné "šicí" pásy, za cenu že generuju více trianglů na přechodu mezi 2 LODY (aka. mezi 2 LODy je vždy pás s kvalitou přibližně LOD 0). Generování indexů je poměrně snadné, jednoduchá rekurze.
Možná to není nejrychlejší řešení, ale odpadl problém s řešením šicích pásů (kdy bych musel na vykreslení volat více drawcallů, nebo mít více IB, nebo mít dynamické IB). Napotřebuju také informace o sousednícj LODech. Další výhodu vidím v tom, že LOD 12 klidně může sousedit s LODem 2 a nikde nebudou trhliny a nemusí se starat o N pásů.
Před vykreslením si chunky, které mi vrátí QuadTree qucik sortem seřadím podle LODu abych eliminoval přepínání IB a pak kreslím.

možná vylepšení:
1) Seřadit nejenm podle LODu, ale i podle sousednosti, abych na jeden draw-call mohl vykreslit třeba 3 za sebou ležící díly.
2) Pokud mám 3/4 terénu placku, snížit v rámci LODu počet trianglů tak, že "sloučím" triangly se stejnou výškou a vznikne mi místo např. 4 malých 1 velký
3) Místo QuadTree použít OctTree a uřezat i to, co je třeba za kopce a tudíž není vidět. Quad mi řeže jen na frustrum.

Případnou kritiku prosím směřovat do tohoto topicu