3D Teren z výškové mapy

[VladR]

Nejak ste sa tu rozbehli minuly tyzden

ad 500 MB : Postni sem ako vyzera tvoj vertex a aky velky IB pouzivas.
Kludne tam mozes mat nieo sprasene, co spotrebu pamate duplikuje, ale to si uz musis oddebugovat ty. Zacni to krokovat po troche a sleduj kedy ti spotreba vybehne.

Dalej, nemozes merat spotrebu tak, ze pozries task manazer. Odmeraj si to v kode, kolko ti to pole zabera. Dufam, ze to nie je <vector> a nereziduje cely cas v pamati aj po vytvoreni VB.

Pokial chces znizit spotrebu pamate terenu, tak najlepsia volba je pouzit Base Chunk a 2 streamy. Base Chunk obsahuje predratane XZ pozicie a UV(UV2) kazdeho vertexu. Tieto data su spolocne pre kazdy jeden chunk celeho terenu (samozrejme, musi byt teren podeleny na tieto chunky). To je Stream 0. Samotnu vysku vertexu potom mas v Stream1. Tym padom potrebujes iba 4 Bytes na vertex, co aj pri 1024x1024 cini len 4 MB. Velkost Base Chunk VB je zanedbatelna, lebo pri 128x128 zabera len okolo 0.5 MB. Oba streamy skombinujes vo vertex shaderi.

Este viac ide znizit spotrebu, ak heightmapu konvertnes do DXT1 (a patricne upravis shader). Potom ti zaberie len 0.5 Bytes na vertex vo VRAM, co je bezkonkurencne.

[Juraj]

Tak po drobném odmlčení jsem zase tu.

Ano jelikož je to stále mnou přepracovávaný terén z nějakého tutigu, je možné že zde mám více údajů zbytečně. Nyní to mám tak rozvrtané že mi terrén ani nenaběhne . Ale jakymle se dostanu k tomu slavnému rozčvetcování, debugnu to a podívám se na formát vertex bufferu.

Přikládám strukturu, aby jste to mohli odborný okem zkouknout, jak říkám je to ještě stále podle tutigu, takže tam bude asi více zbytečných věcí které by snad šli vypočítat v sharderech při renderu.

[VladR]

Cize 40 Bytes na vertex. To sa uz celkom rychlo nascita.

Ak budes potrebovat normalu na kazdy vertex a nechces to riesit cez normalovu mapu, tak aspon pouzi half, cim znizis spotrebu na 50%. Az budes mat spravene aj shadery, tak pouzi iba 1 Byte na kazdy koordinat normaly, cim sa dostanes na 25% spotreby (3 vs 12). Pokial sa ti 1 Byte zda malo oproti 4, tak si predstav, ze aj ten 1 byte na koordinat ti da 16.7 mil. roznych normal, co je akoze stale zbytocne vela.
Ja ak potrebujem normaly, tak ich spakujem do 2 Bytov, resp. si vypomozem nejakym inym bitom v inych vertexovych datach. 18 bitov na nx,ny,nz staci v pohode.
To len, az sa budes nudit a budes citit silne nutkanie s tou spotrebou RAM nieco spravit

[Juraj]

Jasně že tu potřebu mam

Nyní však musím kompletně dodělat zobrazení terénu podle kamery, co mi dalo celkem zabrat to vše rozdělit a poté se vrhnu na snížení potřeby ram..

Jen tak pro zajímavost je rozdíl jeslti používám třeba na nromálu Vector3, nebo bych mel x,y,z as byte? Já si myslím že ano, protože byte ma nižší maximum a tudíš by měl zabírat méně paměti.. Ale zase jsem někde četl, že .NET pracuje tak že dinamicky zvětšuje přidělenou pamět podle obsahu proměné. Víte někdo jak to je?

[VladR]

Tak to si pis ze je rozdiel medzi velkostou Byte a float Obvykle 4:1. Druha vec je, ze to v RAM musi byt nejako zarovnane, netusim ci to ide vypnut vo Visual Basicu (s neprijemnym dopadom na vykon, pravdaze).
Vid : http://msdn.microsoft.com/en-us/library/83ythb65(VS.80).aspx

Potom, ked vytvaras Vertex Buffer, tak tam tiez kazdy komponent musi byt nasobkom 4, cize aj ked pouzivas iba 3 byty, tak fyzicky zaberas vo VRAM 4 (ale potom vies ten volny pouzit na cokolvek ine, podla potreby).

Pravdaze, nestaci ti toto zmenit len tak, v deklaracii vertexu, na to musis mat nakodeny shader, ktory ti danu hodnotu 0-255 transformne do patricneho rozsahu.

[Quiark]

[VladR]

Ci on nahodou nema na mysli typ decimal ? Alebo to, ze kontajner sa dokaze dynamicky realokovat, ak sa do neho pridavaju elementy. To by musel jasnejsie popisat.

[Augi]

No ale hlavně já bych data (pokud s nima nepotřebuje pracovat na CPU) vůbec netahal přes nějaký svoje struktury vertexů, ale rovnou je zapisoval do vertex bufferu. Tzn. v nějakýho formátu si přečtu jeden vertex a ten hned strčim (patřičně upravenej) do vertex bufferu. Maximálně to dělat po nějakých chunkách, ale rozhodně ne nejprve natáhnout celé do paměti a překlopit do vertex bufferu. I když vlastně to by ani nemuselo tolik vadit...ale hlavně proboha si pak to pole vertexů nedržet, ale uvolnit ho!

[Crusty]

mno ale neni to zas na ukor vykonu porad ty VB nacitat a mazat ?
_________________
http://www.2ox.cz

[nou]

ak je raz vertex buffer vytvoreny tak ostane dostupny az dokym ho neuvolnim alebo este nestratim kontext. takze drzat si tie data v pameti je zbytocnost.
_________________
Najjednoduchšie chyby sa najtažšie hľadajú.

[Juraj]

Tak abych se taky pochlubil, dal jsem se do první fáze optimalizace vertex bufferu. Strukturu jsem zjednodusil a potrebne hodnoty vypocitavam privo v sharderech..

aktuální struktura

[Juraj]

[Augi]

Panebože, VertexBuffer v MDX má asi pět metod - to je vážně problém se na ně podívat? Pokud ano, tak věz, že lockování vertex bufferu tak, že je k němu pak přístup jako ke streamu, zajišťuje dvojice metod Lock a Unlock:
http://msdn.microsoft.com/en-us/library/microsoft.windowsmobile.directx.direct3d.vertexbuffer_methods.aspx

[Marek]