OpenGL efektivni kresleni terenu

[johnnash]

V OpenGL implementuju GeoMipMapping(http://www.flipcode.com/archives/article_geomipmaps.pdf).
V soucasne dobe premyslim jak efektivne renderovat bloky terenu.
Problem je, ze okolni bloky muzou mit rozdilne LODy.
V paperu je toto resene tak ze blok s vyssim LODem je na okrajich vykreslen s odpovidajicm LODem bloku s kterym sousedi(proste aby nevznikaly diry).
Vertexy mam ve VBO na karte, a ted otazka.
Je rozumne posilat a generovat odpovidajici indexy v kazdem framu nebo to mit predpocitane? Predpocitane indexy by zase zabrali furu mista...
Jak byste to resili?

[]semo[]

Polož si otázku, jestli máš dost paměti, jestli jo tak je to pohoda, nic neřeš a předpočítej to. Ty paměťový nároky můžeš zmenšit tak, že si dáš třeba pravidlo, že Lod N se může adaptovat maximálně na lody N-1 a N-2 a hned si vyřadil spoustu kombinací.

Já tohle kdysi řešil tak, že sem měl ty okraje vygenerovaný zvlášť a při adaptování sem to tak nějak poskládal. Vycházelo to většinou tak 2 drawcally na jeden adaptující čtverec (s použitím dalších optimalizací). Neni to ideální, ale zdálo se mi to jako takový rozumný kompromis. Detaily nebo zdroják můžu kdyžtak ukázat.

Kompletní předgenerování je nejrychlejší na render, ale bude vycházet na pěkných pár mega. S použitím nějaký rychlý šikovný komprese se dostaneš na rozumnější čísla, asi bych to dnes zkusil takhle.
_________________
Kdo jede na tygru, nesmí sesednout.
---
http://www.inventurakrajiny.cz/sipka/
Aquadelic GT, Mafia II, simulátory

[johnnash]

No stejne budu asi muset vyzkouset oboje co je rychlejsi.
Pak kdyztak postnu k cemu jsem dosel.

[Marek]

Pokud máš nějakou maximální rychlost kamery vůči terénu, že dokážeš určit, za jak dlouho se blok může přepnout na detailnější verzi, můžeš si dovolit mít celý terén na disku. Budeš načítat jen to, co kamera vidí nebo může vidět třeba za 10s (za tu dobu bys měl s přehledem stihnout načíst aspoň 300MB). V 3D API si vždycky jen namapuješ nový vertex/index buffer (glMapBuffer, v D3D myslím Lock) a do něj budeš načítat přímo z disku ve vedlejším vlákně, aby to nemělo vliv na fps. Tak můžeš celkem bezpečně udělat načítání detailnějších bloků z disku za běhu a uvolňování z paměti těch, co jsou příliš daleko. Dřív nebo později to stejně budeš muset takhle dělat, pokud to s terénama myslíš vážně, takže proč to neudělat dobře už na začátku.

Paměť se snaž trochu srazit, ale jinak se o ni moc nestarej, na disku je místa dost. Hlavně nic nekomprimuj, při načítání není na dekompresi čas, CPU má i tak dost práce se scénou.
_________________
AMD Open Source Graphics Driver Developer

[Augi]

Jedině mít data na disku zakomprimovaná takovým způsobem, že se dekomprese provede až na GPU...

[]semo[]

Eosie: nesouhlasím, myslím, že v tomto případě je lepší mít to všechno v ramce a zkomprimovaný. Dekomprese by ale mohla probíhat tak, jak navrhuješ načítání z disku, jenže by to nebylo načítání ale příprava index bufferu. Pod pojmem dekomprese si nepředstavujte žádnej Hardcore (zip a podobně), mluvím o pár instrukcích navíc).

Jiná věc je načítání výškových dat terénu (tedy vertexbufferu), to je jiná, tady bych souhlasil. Velikost a výkon indexů se dá ale odchytat tak, aby nebylo potřeba hrabat na disk.

EDIT: Augi, dekomprimovat indexy na GPU? To potřebuješ nějakej dost pokročilej shader model ne?
_________________
Kdo jede na tygru, nesmí sesednout.
---
http://www.inventurakrajiny.cz/sipka/
Aquadelic GT, Mafia II, simulátory

[Augi]

Jsem myslel třeba nějaké úsporné uložení pozice a normály...

[]semo[]

Jo ták, to máš pravdu. Měl jsem ale na mysli Index buffery.
_________________
Kdo jede na tygru, nesmí sesednout.
---
http://www.inventurakrajiny.cz/sipka/
Aquadelic GT, Mafia II, simulátory

[Augi]

Jasný - já právě myslel optimalizaci na jiný úrovni - rozhodně bych to nepodceňoval - myslim, že VladR něco takovýho používal...

[Mem]

[Marek]

Mem> On se mnou nesouhlasil jen v případě index bufferu. Dále, dnešní hry se musí vypořádat se streamováním terénu z DVD (Xbox, PS3), to je mnohem větší peklo. To všechno vůbec nevadí, vždycky se dá s přepnutím LODu počkat, než se data načtou. Udržet vysoké fps by neměl být žádný problém. Pak už je to jenom o granularitě bloků a prioritě načítání LODů. Z disku se dokonce načítají za běhu i textury (megatexture technology) a VRAM pak slouží jen jako taková texturová cache, to je mnohem víc dat než zabírá terén. A swap tu netahej, to je pro děti.

semo> Jestli jsou indexy v RAM a vertexy na disku, to už je docela jedno ne? Při renderingu je stejně potřeba obojí. Co se týče dekomprese index bufferu, snažil jsem se naznačit, že během načítání by nemělo CPU nic dělat (připravuje rendering, počítá fyziku, herní logiku atd). Přenos dat by měl být jenom HDD -> page-locked buffer v RAM -> VRAM s minimální asistencí CPU, to řídí jen první přenos. Druhý přenos řídí většinou GPU, které už si to z RAM pomocí DMA natahá samo.

Co se týče komprese vertex bufferu. Používat 8bit normalized typ pro jednotkový vektory, pro ostatní věci 16bit float, pokud to podporuje API. Pokud je podporováno, použít vertex texture fetch z DXTC/BC textur pro načtení některých dat vertexů (např. výška vertexu Y). Pokud je podporováno, vypočítat pozici v mřížce (X a Z souřadnice) z ID vertexu (tj. číslo počítaného vertexu dostupné v shaderu, např. gl_VertexID v OpenGL). Tohle jsou všechno jednoduché přímočaré věci. Existují i sofistikovanější metody, ale těm bych se spíš vyhnul, protože mohou věci víc komplikovat.
_________________
AMD Open Source Graphics Driver Developer

[Mem]

[]semo[]

Eosie: ano, když bude implementovat to streamování, může tam ty index dát taky. Pokud nebude, stále assertivně trvám na mojem řešní :). Dekomprese proběhne jednou za Xtej frejm, případně se může dekomprimovat postupně, nebo rovnou paralelně. Tak či onak, dekomprese těchto známých dat bude opravdu velmi rychlá. Odhaduju, že by to nemusel bejt ani dvojnásobek kopírování toho bufferu do VRAM v nekomprimované podobě.
Další věc je, že predikce lodů bude složitější na implementaci i výpočet, než predikce čtverců co budou vidět za chvíli. Takže se může stát, že tam skočí nějakej LOD a budeš muset hrabat na disk pro index buffer, zatímco bys ho mohl vytáhnout rychle z paměti.

EDIT: nejspíš půjdou dobře implementovat oba způsoby, ale tahle technická debata mě baví, je to lepší než ty sračky v popelnici :)
_________________
Kdo jede na tygru, nesmí sesednout.
---
http://www.inventurakrajiny.cz/sipka/
Aquadelic GT, Mafia II, simulátory