Zobrazit předchozí téma :: Zobrazit následující téma |
Autor |
Zpráva |
Juraj
Založen: 06. 12. 2007 Příspěvky: 189
|
Zaslal: 25. září 2008, 07:27:17 Předmět: 3D Teren z výškové mapy |
|
|
Opět zakládám další topic a doufám že z vás vymámím nějaké informace
Konkrétně mi jde o možnosti optimalizace terenu. Abych trochu popsal v jaké jsem nyní fázi a více Vám tím přiblížil co vlastně chci.
Takže můj terén si načítám podle výškové mapy, která je uložená v *.raw souboru (obrazku). Pomocí stupně šedi určuji výšky v jednotlivých bodech. Nyní mi první verze terénu vytvoří trojúhelníky a to tím stylem že na jeden pixel z RAW souboru vytvořím 6 trojúhelníků. Tímto jsem otestoval funkčnost a nyní přecházím na optimalizaci. (nepopisuji zde zjistovani texturování terénu a ostatní nyní nepodstatné věci). Celý tento (zatím malý) terén renderuji.
Jak jsem snad rozumně popsal, vytvořím síť trojúhelníků podle vstupnícho rawu, bez ohledu na to jak je daná plocha např rovná a i přez to složená z několika set trojúhelníků. Nyní tedy potřebuji provést optimalizaci "surového" terénu.
Nastíním zde mnou vymyslený postup:
1) Celý terén projdu a pokusím se na rovných plochách zredukovat počet trojuhelníků
2) Začnu renderovat pouze tu část kde se nachází kamera
3) .....
Nyní co od vás vlastně chci, potřebuji pozměnit popř. navrhnout jak nyní dále effektivně optimalizovat terén, nebo jáký krok před mojí posloupnost vsunout. Můj cíl není vytvořit terén s 3000FPS , ale vytvořit herní terén který bude možno použít ve strategii a nezabere mi moře času. |
|
Návrat nahoru |
|
|
nou
Založen: 28. 07. 2007 Příspěvky: 1047
|
Zaslal: 25. září 2008, 07:49:14 Předmět: |
|
|
1. implementovat quad/octet tree to ti tu ae uz radily
2. su dve jednoduche metody na redukovanie trojuholnikov.
-vymazat vrchol - pre kazdy vrchol si vypocitas delta error ktory vznikne ak by tam dany vrchol nebol. a postupne zacnes odstranovat vrcholy s najmensim delta error
-vymazdat hranu - vyratas dlzky kazdej hrany a tu vymzes tym ze zlucis dva vrcholy do jedneho.
duha metoda je myslim lahsia na implementaciu ale prva myslim dava krajsie vysledky. _________________ Najjednoduchšie chyby sa najtažšie hľadajú. |
|
Návrat nahoru |
|
|
]semo[
Založen: 29. 07. 2007 Příspěvky: 1526 Bydliště: Telč
|
Zaslal: 25. září 2008, 07:58:10 Předmět: |
|
|
A výsledek chceš mít jako pravidelnou síť, nebo nepravidelnou?
Na pravidelnou se dá použít tohle:
http://www.gamedev.net/reference/articles/article1936.asp
Už je to trochu starý, ale pořád by to asi mělo být ok. Neni to těžký udělat, implementoval sem to.
Na nepravidelnou zkus tohle:
http://graphics.cs.uiuc.edu/~garland/papers/scape.pdf
Rovněž jsem implementoval, je to super algoritmus, ale trochu se možná zapotíš. Jinak samozřejmě určitě existuje nějaký offline nástroj, který ti z tý pravidelný sítě tuhle nepravidelnou udělá. Jeden takovej sem naprogramoval, kdybys chtěl, dám ti ho i se zdrojákama.
Když už bys měl takhle nepravidelnou síť, tak další postup by byl rozřezat ji do čtverců, na kterých půjde dělat frustum culling. Dynamický lod by ale nebyl možný (pokud bys nechtěl potit krev), což by v strategii nemuselo vadit - bude-li kamera shlížet shora.
resumé: máš-li kameru, která se nedívá pořád do dálky, tak použij nepravidelnou síť bez lodování. Získáš ji z tý heightmapy třeba v nějakým 3D studiu, nebo vlstním optimalizačním nástrojem. Bude pak trochu těžší zjišťovat výšku na terénu, ale to můžeš z tý původní heightmapy.
Pokud chceš i dynamický lod, implementuj to co sem odkazoval nahoře, je to pro začátek jednoduchý a účel to splní stoprocentně (i když by se jistě dnes našly lepší metody http://vterrain.org/LOD/). _________________ Kdo jede na tygru, nesmí sesednout.
---
http://www.inventurakrajiny.cz/sipka/
Aquadelic GT, Mafia II, simulátory |
|
Návrat nahoru |
|
|
Juraj
Založen: 06. 12. 2007 Příspěvky: 189
|
Zaslal: 25. září 2008, 12:05:34 Předmět: |
|
|
to nou:
Ano vím že jsem už nějaké rady dostal, nezapoměl jsem je, jen jsem zatím pracoval na nečem jiném, nyní se to tedy snažím schrnout, abych si předem ujasnil jak postupovat.
Ještě další podprobnosti, nebudu potřeboval zobrazování různých detailů, nevím jak to správně nazvat. Prostě kamera se bude pohybovat po terenu, ale nebude se nijak zásadně měnit její vzdálenost od terénu, takže nebudu potřebovatl několik detailu terenu. |
|
Návrat nahoru |
|
|
rezna
Založen: 27. 07. 2007 Příspěvky: 2156
|
Zaslal: 25. září 2008, 12:11:27 Předmět: |
|
|
Juraj napsal: |
Ještě další podprobnosti, nebudu potřeboval zobrazování různých detailů, nevím jak to správně nazvat. Prostě kamera se bude pohybovat po terenu, ale nebude se nijak zásadně měnit její vzdálenost od terénu, takže nebudu potřebovatl několik detailu terenu. |
ano LoD tu padl a ze asi asi nebude potreba - Level of Detail |
|
Návrat nahoru |
|
|
rezna
Založen: 27. 07. 2007 Příspěvky: 2156
|
Zaslal: 25. září 2008, 12:13:08 Předmět: |
|
|
Juraj napsal: |
Ještě další podprobnosti, nebudu potřeboval zobrazování různých detailů, nevím jak to správně nazvat. Prostě kamera se bude pohybovat po terenu, ale nebude se nijak zásadně měnit její vzdálenost od terénu, takže nebudu potřebovatl několik detailu terenu. |
ano LoD tu padl a ze asi asi nebude potreba - Level of Detail |
|
Návrat nahoru |
|
|
Juraj
Založen: 06. 12. 2007 Příspěvky: 189
|
Zaslal: 25. září 2008, 12:36:51 Předmět: |
|
|
rezna napsal: |
Juraj napsal: |
Ještě další podprobnosti, nebudu potřeboval zobrazování různých detailů, nevím jak to správně nazvat. Prostě kamera se bude pohybovat po terenu, ale nebude se nijak zásadně měnit její vzdálenost od terénu, takže nebudu potřebovatl několik detailu terenu. |
ano LoD tu padl a ze asi asi nebude potreba - Level of Detail |
Aha díky za vysvětlení, nějaké pojmy zatím neznám.. |
|
Návrat nahoru |
|
|
Juraj
Založen: 06. 12. 2007 Příspěvky: 189
|
Zaslal: 1. říjen 2008, 11:53:29 Předmět: |
|
|
Tak nyní mám dotaz trochu z jiného soudku, jelikož už jsem se dostal na loadování větších terénů než dříve, zajímalo by mě jak je to sapměťovou náročností.
Pokud načtu kompetně celý terrén, který obsahuje 3 328 200 trojúhelníků zabírá mi v paměti cca 500MB. Jedná se mi o to, zda je to hodně, normálně nebo málo.
Popř zda se mám zaměřit na to abych paměťi bral méně..
ps: pokud nahrávám vertex a index Buffer, pokud ho vytvořím znovu, vymaže se paměť kterou zabíral? Nebo se musí nějakým příkazem uvolnit, hlavně z hlediska directx.
př.
Když použiju takoveto opakování, paměťová náročnost stále roste a nijak se neuvolní..
kód: |
cyklus treba 3x
' create buffer
Me.vrBuffer(i) = New VertexBuffer(GetType(TerrainVertex), ArrSquare.Length, frmMain.dev, Usage.WriteOnly, 0, Pool.Default)
Me.vrBuffer(i).SetData(ArrSquare, 0, LockFlags.None)
konec cyklu
|
|
|
Návrat nahoru |
|
|
Augi
Založen: 28. 07. 2007 Příspěvky: 782 Bydliště: Čerčany
|
Zaslal: 1. říjen 2008, 12:38:27 Předmět: |
|
|
Ad paměťová náročnost terénu - chtělo by to znát strukturu vertexu (tedy asi structu TerrainVertex), abychom viděli, jestli tam někde zbytečně neplýtváš. Když neplýtváš a pořád se Ti zdají paměťové nároky příliš velké, přichází na řadu komprese. O tom by Ti něco mohl napsat VladR nebo Egosie.
Ad uvolňování: O M F G ! To je snad ve druhé lekci každé slušné učebnice nějakého .NET jazyka. Cokoliv, co implementuje rozhraní IDisposable, se musí uvolnit, jakmile to není potřeba, pomocí metody Dispose(). VertexBuffer toto rozhraní implementuje. |
|
Návrat nahoru |
|
|
Marek
Založen: 28. 07. 2007 Příspěvky: 1782 Bydliště: Velká Morava
|
Zaslal: 2. říjen 2008, 11:48:07 Předmět: |
|
|
Juraj napsal: |
Tak nyní mám dotaz trochu z jiného soudku, jelikož už jsem se dostal na loadování větších terénů než dříve, zajímalo by mě jak je to sapměťovou náročností. |
Pro začátek implementuj quad-tree nebo kd-tree, na nějaké úrovni toho stromu udělej fixní pravidelnou mřížku a tím si vymezíš sektory. Načteš jenom ty, co jsou v blízkosti pozorovatele, budeš za běhu načítat ty, ke kterým se pozorovatel přibližuje, a uvolňovat ty, od kterých se vzdaluje. Nic lehčího snad ani není.
Juraj napsal: |
Pokud načtu kompetně celý terrén, který obsahuje 3 328 200 trojúhelníků zabírá mi v paměti cca 500MB. Jedná se mi o to, zda je to hodně, normálně nebo málo. |
To je nějaká strašná blbost, to nemůže brát 500MB. Nejspíš nepoužíváš index buffer, potom to vychází 13 floatů na vertex. Máš tam asi pozici (3), normály (3), koordináty (2) = 8 ... ani bez index bufferu asi nedám 500MB, jseš prostě kouzelník. Spíš tak 300MB a s index bufferem by to bylo asi pod 100MB, spíš tak 70-80, při využití úspornější reprezentace dat (half-float, unsigned char, komprese) by to šlo ještě níž. _________________ AMD Open Source Graphics Driver Developer |
|
Návrat nahoru |
|
|
Juraj
Založen: 06. 12. 2007 Příspěvky: 189
|
Zaslal: 2. říjen 2008, 11:52:40 Předmět: |
|
|
Díky za vaše postřehy. Jelikož jsem neměl vůbec žádnu představu, neveděl jsem kde a co uspořit. Zatím je to přeci jen v stavu vyvýjení, takže tam budu mít nějaké zbytečné proměné, projdu tedy trukturu vertex bufferu a jeho části, asi taky provedu optimalizaci bodů.
ps: index buufer používám, ten zabírá málo, hlavní část je ve vertex bufferech. |
|
Návrat nahoru |
|
|
Marek
Založen: 28. 07. 2007 Příspěvky: 1782 Bydliště: Velká Morava
|
Zaslal: 2. říjen 2008, 12:05:03 Předmět: |
|
|
Juraj napsal: |
ps: index buufer používám, ten zabírá málo, hlavní část je ve vertex bufferech. |
Jo? A kde se teda vzalo těch 500MB? _________________ AMD Open Source Graphics Driver Developer |
|
Návrat nahoru |
|
|
Augi
Založen: 28. 07. 2007 Příspěvky: 782 Bydliště: Čerčany
|
Zaslal: 2. říjen 2008, 14:44:09 Předmět: |
|
|
To, že používá index buffer, přece neznamená, že tam má furt duplicitní vertexy Ale ne, fakt je to divný... |
|
Návrat nahoru |
|
|
Juraj
Založen: 06. 12. 2007 Příspěvky: 189
|
Zaslal: 2. říjen 2008, 15:44:27 Předmět: |
|
|
Tak teď jsem to testoval a jsem z toho trochu zmatenej. Jednou se mi stalo že využití paměti bylo cca na 160MB. Poté jsem to pustil znovu a využití paměti vylítlo prapodivných 620MB. Opravdu nevým co to má být, vžy se spouští ta samá věc a v kódu jsem také nic neměnil.
Nenapadá Vás něco, krom toho že tam asi mam "nepořádek"? |
|
Návrat nahoru |
|
|
Marek
Založen: 28. 07. 2007 Příspěvky: 1782 Bydliště: Velká Morava
|
Zaslal: 3. říjen 2008, 11:29:24 Předmět: |
|
|
Aha... myslel jsem velikost meshe samotného, ne celé aplikace. Potom děláš špatně něco jinýho nebo používáš např. grafický Intel driver, který konzumuje volnou paměť sakra rychle. _________________ AMD Open Source Graphics Driver Developer |
|
Návrat nahoru |
|
|
|