OpenGL - kostka, počet vertexů 8 vs 24

[petr]

dobrý den, potřeboval bych od vás trochu nasměrovat eventuelně odsouhlasit nebo vyvrátit můj "programátorský postup" při renderování geometrického primitiva.

U klasického příkladu kostky (z knihy OpenGL průvodce programátora) a úspory vertexů jsem se zarazil na jedné věci, pokud použiju úsporné volání 8mi vertexů je to v pořádku jenom v případě pokud mají všechny stěny například stejnou barvu (za předpokladu, že mezi volám nechci volat glcolor) a například tehdy generuji vertexy ručně zadáváním v programu (například pro testování). Ale pokud bych chtěl každou stěnu vykreslit jinou barvou a otexturovat jinou texturou (textura je vtomto případě o rozměrech 512x256 rgba a jednotlivé textury jsou poskládány v této pixmapě) - dejme tomu, že kostka je domek který má z každé strany jinou texturu a i jiné texture coord, tzn, že za těchto podmínek stejně musím definovat 24 vertexů - je to tak? Při použití 8mi vertexů by to přece nešlo - anebo ano?

Zdrojová data mám připravená v binárním souboru (vše ve floatech) ve formátu prokládaného pole GL_C4F_N3F_T2F_V3F (teď nevím jestli je pořadí správné) a za ním seznam (pole) vertexů které vykreslit. Tohle řešení se mi zdá elegantnějsší (bohužel však u velkých scén počet vertexů roste geometrickou řadou - v budoucnu do aplikace implementuju levels od details), nejenom proto, že mám vše po ruce v naprosto ideálně organizovaném seznamu, ale také proto, že mám dopředu vypočítané a normalizované normály pro každý vertex, nemusím se jimi vůbec zabývat za běhu programu tak jak je uvedeno v příkladech v knize OpenGL průvodce programátora.

Co vy na to?

[Augi]

Já bych se tolik nebál toho nárůstu počtu vertexů. Absolutní velikost vertexů a indexů bude stejně řádově menší než velikost textur...

[VladR]

Tvoje obavy su uplne neopodstatnene. Na to, aby si bol transform-bound potrebujes na dnesnych kartach cca 10 milionov vertexov na scenu.

A teraz riesis kocku s 24 vertexami Este stale mas rezervu cca 10M vertexov, tak nestresuj

Vo vseobecnosti, ak nejaky bod potrebuje mat rozne atributy (texturu, normalu, farbu) pre rozne plochy, tak logicky ten vertex musis pre dane plochy zduplikovat.

Konkretne - ak by si pouzil kocku, tak pri 8 unikatnych vertexoch by to znamenalo, ze kazdy roh by mal spolocne atributy pre vsetky 3 steny.

Co by pri takej texture zrovna vadit nemuselo, ale pri normale uz celkom hej

[Augi]

No ono by to šlo i vyřešit tím, že by měl v buffery pro pozice, pro normály, pro texcoords atd. a pak by to skládal. Sice by ušetřil místo, ale IMHO by to bylo pomalejší než mít vertexy pěkně předpřipravené...

[petr]

Tvoje obavy su uplne neopodstatnene. Na to, aby si bol transform-bound potrebujes na dnesnych kartach cca 10 milionov vertexov na scenu.
- přesně tohle jsem potřeboval slyšet. Ano řeším kostku, ikdyž ve své podstatě o ni nejde, ale podle mého by se mělo začít u nejjednoduššich věcí, které si odladím a vím, že budou stopro fungovat. Když "otexturovanou" kostu zduplikuju 10 000x a každou šachovnicově rozprostřu v prostoru, zároveň u některých vyměním texturu, tak by mi to už mohlo dát docela solidní krabicové "město" ... snad se to povede.

Díky moc za odpovědi.

[Casio]

Nedávno jsem řešil stejný problém. Taky mám knížku "OpenGL průvodce programátora", takže přesně vím, co myslíš. Taky jsem hledal řešení, jak se vyhnout duplikování dat a použít hezky úspornou 8 ver. kostku a přitom mít na každý stěně/vertexu jiný tex. coord ... No a řešení prostě není (nebo já ho aspoň neznám).
Na kostku používám 24 ver. a na každej z nich mám předpočítaný TexCoord, Normálu, Tangentu a Binormálu. A to je panečku kopií dat, ale co, 10M ver. na scénu mít tak rychle nebudu a když se podívám na velikosti dnešních RAM/VRAM pamětí, tak trochu plýtvání vem čert.
U spouty jiných geometrií se často ver. sdílí, takže s tím nárůstem to celkově není tak zlý. (Např. u terénů myslím, že není potřeba žádný duplikát vertexu.)

[ladik-BigBoss]

reseni by mozna bylo pres compute shader a 100% pres CUDA/OpenCL... jenze stoji to nestoji za to pokud vam to neurychli vedecky vypocet o mesic...

[VladR]

Pokial sa budu tie data mnohokrat opakovat, tak za predpokladu primarneho ciela uspory pamate, mozes pouzit streamy. Netusim OGL ekvivalent z DX SetStreamSource (), ale nemal by to byt problem dohladat.

Princip spociva v tom, ze si pripravis rozne bufery na pozicie, normaly a UV koordinaty. A tie, ktore su totozne (napr. UV koordinaty a normaly) ti staci mat raz v VRAM ulozene a menit iba stream pozicii pri renderovani.

Switchovanie streamov ma ale drasticky dopad na vykon a ak to budes robit 100 krat za frame, tak ti vertex throughput padne z 10M vertexov na 0.1M na scenu. Ale usetris VRAM

Preto je dobre si rozmysliet, ci tam uspora za tu stratu vykonu stoji

A ked uz chces riesit spotrebu VRAM, tak musis ist do shaderov a komprimovat data. Normalne ti treba 4 Bytes na float, cize na pozicu treba 4*3=12 Bytes, na normalu tiez 12 a na UV 8 Bytes. To je 32 Bytes na vertex.
Tych 32 Bytes vies znizit pri shaderoch na polovicu (16 Bytes) bez akejkolvek straty vykonu, kedze to vies dekomprimovat v jedinej instrukcii, takze to mas de facto free (proste si namapujes ten float na rozsah DWORDu 0-65535). To bolo v DX8.
Prave kvoli tomu v DX9 vznikli nove formaty dat, ktore to uz robia za teba (len maju trocha nizsiu presnost, co normalne nevadi).

DX9 ti to cele zjednodusuje, lebo ti dava moznost instancingu, ktora sa navonok tvari ako nieco naproste genialne, ale interne driver robi to, co som popisal vyssie, takze aj preto su vysledky vykonu pri instancingu take ubohe, ake su. Je to proste tool na zjednodusenie prace, ale max. vykon od toho necakaj - sam si to dokazes napisat manualne lepsie.


Co sa tyka toho mesta o 10.000 budovach, tak tam ti realne staci mat 1 stream pozicie/rotacie/VertexColor kazdej budovy (vo world space) a potom mat dalsi stream, kde budes mat Poziciu, UV a Normaly na jednu kocku. V shaderi si zoberies z prveho streamu offset budovy a priratas ho (MatTranslate) k zrotovanej (MatRotationY) pozicii vertexu z druheho streamu (kde budu pozicie logicky len okolo bodu 0,0,0 aby ich slo v shaderi zrotovat a translatnut).

VertexColor budes mat unikatnu na kazdu budovu (v nultom streame), cim dosiahnes slusnu variabilitu vzhladu mesta. Na zaciatok to vygeneruj cez rand (), neskor mozes pouzit nejake proceduralne algoritmy na noise, aby to vyzeralo lepsie.

Byt tebou, tak v dalsom kroku pridam do nulteho streamu aj index do textury (0-15) a napchal by som 8 kusov 512x512 textur do jednej velkej 2048x2048 (texture atlas). Z cisla indexu lahko ziskas riadok (0..3) a stlpec (0..3) a tak si odvodis UV koordinaty v ramci tej velkej 2048x2048 textury.

Tak ziskas obrovsku vizualnu variabilitu bez texture switch, co je obrovske plus, kedze texture switch ma logicky za nasledok novy DIP (DrawIndexedPrimitive) - cize CPU sa zbytocne nezahlcuje 100vkou kratkych volani DIP.


Tym padom dosiahnes max. mozny vykon - pouzijes jedine volanie DIP, v ktorom vykreslis tych 10.000 budov, aj ked budu mat roznu poziciu, farbu, rotaciu, texturu

Pri tom komprimovani a formate vertexu este daj pozor na to, aby bola vysledna velkost vertexu zarovnana na nasobky 16 Bytes, inak sa ti prepadne vykon kvoli cache misses.

Inak povedane, radsej nech ma vysledny vertex 32 Bytes, ako keby mal mat 26 Bytes.

[Marek]

Berte v úvahu, že když zavoláte 1x glVertex, tak grafická karta by za dobu volání té jedné funkce mohla zpracovat 100 vertexů. Pokud budete řešit blbosti jako jak vykreslit krychli na 8 vertexů, nikdy se nedostanete k reálným problémům. (BTW krychle se dá v DX10 vykreslit na 1 vertex, ale má to i svoje nevýhody)

VladR> Streamům v GL se říká Vertex Arrays. Určitě bych se nebránil kombinování streamů v RAM i ve VRAM. Problém je v tom, že dnešní GPU čtou jenom z VRAM, takže před renderingem musí proběhnout (pomalý) PCIe přenos (před G80 to možná bylo jinak). Nejsem si jistý, jestli je na DX10 hw stále vertex cache nebo se to čte přímo z VRAM (na nVidii bych řekl, že cache tam není a namísto ní se používá sdílená paměť multiprocesoru; na ATI se kód na fetchování vkládá na začátek vertex shaderu, takže tam to asi závisí na efektivitě řadiče paměti). Ve všech případech nicméně platí pravidla týkající se zarovnání.

Instancing bych nezavrhoval. Je to jediný způsob, jak na GPU protlačit více modelů na rendering a nedovedu si bez toho žádnou hru představit (jednotky ve strategii, NPC v RPG, vegetace...). Primární smysl instancingu byl přece snížit počet draw calls a tedy rozumně vytížit GPU.

Namísto texture atlases bych použil texture arrays (DX10, GL3) nebo možná i 3D texturu (DX9, GL2) - neztratím možnost opakování textur.

Zrovna instancing je třeba jediný způsob, jak plynule vyrenderovat 10000 krychlí (tj. nezahltit si CPU).
_________________
AMD Open Source Graphics Driver Developer

[VladR]

Ved ja instancing nezavrhujem ako taky - len jeho implementaciu, ktora ma znacne rezervy vo vykone a je teda nieco ako ekvivalent "glvertex3f" v OpenGL - je super, ze je to easy-to-use, ale naprd ak cez to chces pretlacit max.mozny pocet objektov (teraz sa nebavim o 100 jednotkach).

Preto preferujem manualny sposob instancingu, ktory si natweakujem podla potreby.

Netusim aka je implementacia na DX10 kartach, je mozne, ze tam je to optimalizovane. Ale ked som cital implementaciu instancingu na DX9 kartach od nVidie, tak som sa chytal za hlavu a behal este 10 minut po izbe, kym soto rozdychal

Tie 3D Textury su sice uz dnes pouzitelne, ale stale dost spomaluju (a vzdy vlastne budu), takze radsej by som tam pridal nejaky proceduralny noise, ktory zvysi tiez variabilitu.

[Marek]

Vím, že někdy je těžké přes instancing pustit víc jak 100 objektů na draw-call (aspoň já měl ten problém, když jsem měl vertex-shader-based instancing, tzn. bez podpory instancingu v 3D API), ale i kdyby to mělo být jen 100x méně draw calls, furt je to lepší než nic.

V DX10 a GL3.1 už je to dost použitelné. Je možno vyrenderovat tolik instancí na draw-call, že je lepší jejich matice dávat do textur, protože na to nestačí konstantní paměť.
_________________
AMD Open Source Graphics Driver Developer

[VladR]

Ty uz si sa hral s DX10 ? Vsimol som si, ze uz viackrat si odporucal riesenia pre DX10/GL3.
Kde na to beries cas ?

[petr]

VladR> ohledně zarovnání na 16B je tento GL formát prokl pole v pořádku: GL_T2F_C4F_N3F_V3F -> float = 4B -> 12*4=48 -> 48/16=3

[Marek]

[petr]

Eosie: zabalení barvy du 4xUINT nezní špatně, ale je otázka jestli to má cenu takhle rozbíjet když ji už mám připravenou v rozsahu 0.0 - 1.0, nicméně nad zarovnáním na 32B bez barvy zkusím pouvažovat; uvědomuji si, že všechny statické modely (trojúhelníky) mají barvu nastavenou na 0xFFFFFFFF (rgba), jen plochy "světel" (viz obr. - klik pro zvětšení) například u směrovek automobilu nebo semaforů ji mají nastevnou na příslušnou barvu (zelená, oranžová, červená) - textura je v tomto případě uložena ve formátu sgi inta (pouze odstíny šedi).



Ještě bych doplnil, že nepotřebuju dojit systém do krve; databáze se pohybují v desítkách tisích trojuhelníků, datová velikost textur v desítkách MB) Na obrázku je jedna z jednodušších scén, výhled zabírá cca 60-70% scény.