Engine a univerzálnost - hlavně správa scény (stromy atd)

[perry]

Píšu si malý engine a snažím se aby byl hodně "variabilní".

Momentálně mám na radu Sema sepsaný scene management (už se to tu jednou řešilo).

Např. mám CollisionManager, který obstarává veškeré kolize modelů ve scéně. Obsahuje (zatím pouze lineárně) seznam objektů Collision (každý model má přiřazen právě 1 nebo žádný kolizní objekt, který se skládá z nekonečného množství bounding boxů nebo čehokoliv jiného)
Nebo GraphicsManager se stará o vizuální složku, AIManager se stará o AI atd.

Mám pár dotazů:
1) je lepší aby měl každý model svůj vlastní VertexBuffer, nebo je lepší udělat něco jako pole VertexBufferů (pro každý typ vertexů jeden VB v poli) a mít je globálně a model by si držel pouze index na vertex buffer v poli a offset. Takže bych ušetřil přepínání vertex bufferů při kreslení (co jsem četl, tak přepínání VB něco stojí)
2) Momentálně mám všechny objekty zarovnané na mřížku (takže třeba zeď vyplní 1 buňku a ta má true / false). Přijde mi to nějaké pochybné , ale zase se s tím v AI "dobře" pracuje... zajímalo by mě, jak se řeší tohle v reálných aplikacích... moc mi nepřijde, že by všechno bylo zarovnané na mřížku (nějaké kulaté budovy apod)
3) Mám budovy ve městě. Momentálně to mám udělané tak, že 1 typ budovy (třeba panelák) je 1 objekt a instací ho vykreslím třeba 100x... jenomže pak mám v jeho kolizní třídě nacpáno 100 bounding boxů ve spojáku. Když udělám zase každou budovu jako 1 objekt, tak to "zabiju" množstvím objektů (s tím že budovy lze libovolně bourat, takže instancování mi přijde jako dobrý nápad.. na grafiku posílám akorát pozice, tangenty, normály, binormály, apod. už jse tam nahrané)

To by bylo pro zatím vše Díky za názory.... nejde o nic kritického, jen mi to tak zajímá. Když už něco dělám, ať nedělám nějakou čuňačinu, kterou pak budu muset stejně přepsat, protože se to nebude "hýbat"

[Augi]

[perry]

Díky za odpověď

[Augi]

Jo, tak jsem to myslel, jen už jsem neměl sílu to rozepisovat, kdo drží pozici a kdo data

[]semo[]

K tomu jednomu velkýmu vertex bufferu mě napadá pár věcí:

1) Když nějaký objekt smažeš, vznikne v paměti díra. Tu můžeš přidělit jinýmu, novýmu objektu, ale pokud se tam nevejde, musíš alokovat jinde. Bude to prostě fragmentovaný. Třeba ale nebudeš chtít mazat objekty během hry.

2) Pokud budeš chtít některýmu objektu dynamicky updatovat geometrii, musíš locknout celý tento velký buffer, což může myslím dost zpomalit.

Na začátku píšeš, že chceš mít engine univerzální, hlasoval bych tedy proto, mít Vertex Buffery pro jednoduchost oddělené. Maximálně v nějakých speciálních případech - terén, statický objekty - implementovat sdílený vertex buffer přesně na míru daný situaci.

Napadá mě nakonec ještě jedno kompromisní řešení: mít sdílený vertex buffer v rámci jednoho "souboru". Dejme tomu, že v jednom 3D souboru budeš mít několik objektů, tak právě tyto objekty by mohly sdílet vertex buffer.
_________________
Kdo jede na tygru, nesmí sesednout.
---
http://www.inventurakrajiny.cz/sipka/
Aquadelic GT, Mafia II, simulátory

[perry]

[pcmaster]

Ja sa mozem vyjadrit k akceleracnym strukturam, ktore proste budes potrebovat v pripade, ze sa chystas kreslit viac ako malo objektov
V zasade mas 2 typy takychto hierarchickych struktur:
1) tie, ktore delia priestor (BSP strom, kD-strom, octree, uniform grid, ...)
2) tie, ktore delia objekty (Bounding Volume Hierarchy (BVH))
Ja ti odporucam naprogramovat si BVH, co ti podla mna do tvojho systemu pasuje najviac. Budes ho pouzivat na rapidne vyradovanie celych skupin objektov z vykreslovania -- tie, ktore sa nenachadzaju v pohlade nebudes kreslit. Ako hovorim, je jednoduchy na implementaciu, v porovnani s osatnymi dosahuje podobne vysledky a existuju aj sposoby ako ho stavat/updatovat nad dynamickymi objektami.
S tym samozrejme bude suvisiet aj struktura grafickych objektov, pretoze uz nebudes moct mat jediny draw call, kedze objekty/data budes musiet mat podelene v hierarchickej strukture.
Ak o tom chces viac, pytaj sa, lebo som nic este vlastne nepovedal
_________________
Off-topic flame-war addict since the very beginning. Registered since Oct. 2003!
Interproductum fimi omne est.

[]semo[]

Nechci mít za každou cenu pravdu, ale myslím, že pro perryho architekturu se hodí spíš způsob 1) :-)
_________________
Kdo jede na tygru, nesmí sesednout.
---
http://www.inventurakrajiny.cz/sipka/
Aquadelic GT, Mafia II, simulátory

[perry]

Na BVH jsem už koukal ale nějak rozumně mi tam nezapadl... Respektive nad jedním objektem (třeba to město) by fungoval docela rozumně v tom jak to mám napsané, ale 1 BVH nad všemi objekty už tam asi nedostanu.

Skupina 1) je jak psal Semo pro mě použitelnější. Přemýšlel jsem o Quad-Tree, který už vlastně mám napsaný pro terén

Teď jsem narazil ještě na jednu "překážku"... jelikož mám budovy (a sbírací bonusy) jako instance, tak abych je mohl kreslit / nekreslit, tak bych pořád musel updatovat instanční VB.


----
Plus zase stíny (reps. ono to platí pro libovolné odrazy. třeba i zpětné zrcátko v autě) Jak je ve finále "roztáhnout" přes všechny objekty ? Když terén, instance, modely mají každý jiný shader... když to vepíšu přímo do těch jednotlivých shaderů, tak to funguje, ale v některých případech mi dojdou registry a pak jsem skončil. Takže něco jako dorenderovat to jako druhý průchod do finální scény... prostě jeden shader který se aplikuje na celou hotovou scénu, jestli to jde...

[]semo[]

Stíny:
můžeš to vykreslit jako druhý průchod do textury a tu pak přes fullscreen quad přiblendovat, ale je to naprd. Budeš mít třeba i ve stínu odlesk slunce, jen bude ztmavený. Udělej si nějakou univerzální funkci do shaderů a vejdi se do registrů :-).
_________________
Kdo jede na tygru, nesmí sesednout.
---
http://www.inventurakrajiny.cz/sipka/
Aquadelic GT, Mafia II, simulátory

[perry]

Jak do systému nahodit zvuky ? Vytvořit zase class SoundManager a každému objektu třídu sound ? Stejně jako Kolize, Grafika apod. ? Přijde mi to jako ideální... s tím že do toho pěkně zapadne i svět.. jako 1 z komponent

[]semo[]

Ano, proč ne. Tak sem to dělal taky. Respektive byl SoundEmitor + SoundBuffer. SoundEmitor je to, co je umístěný v prostoru a vydává zvuk, který je nahraný v SoundBuffer.

Koukám, že se to vlákno celý pěkně zvrhlo :-). Měli bysme přestat, nebo nám to tu někdo z moderátorů pěkně přemoderuje :)
_________________
Kdo jede na tygru, nesmí sesednout.
---
http://www.inventurakrajiny.cz/sipka/
Aquadelic GT, Mafia II, simulátory

[Augi]

Jj, taky bych to udělal přesně takhle.

Semouši, myslím, že jsme ještě pořád hodně on-topic

[perry]

Jak se řeší texture management ? Momentálně si je načtu do paměti a mam je v různých proměných. Ale občas začínám narážet (LostDevice - nepraktická obnova; 1 textura použití vicekrát - problém s přístupem k souboru atd.)

[Augi]

No řešil bych to tak, že bych měl pro jedno jméno souboru a nastavení načítání jednu instanci třídy Textura.
Aby se textura uvolnila vždy, když ji už nikdo nepotřebuje, tak je vhodný tam udělat např. nějaký počítání referencí. Jakože když dáš načíst soubor s nějakým nastavením (např. generování mipmap), tak si nejdřív zjistim, jestli pro tenhle soubor a tohle nastavení už neexistuje vytvořená textura. Pokud ano, tak pouze inkrementuju počet instancí té textury a vrátím již existující instanci. V opačném případě vytvářím novou instanci textury.

Při uvolňování je pak třeba pouze dekrementovat ten čítač. Když spadne na nulu, tak se může textura "fyzicky" odstranit z grafárny.

Ohledně Lost Device - pokud nepracuješ s nějakou DXTexture apod., ale máš obálku ve formě vlastní třídy a tu DXTexture si držíš uvnitř, tak to není problém. V případě lost device TextureManager pouze projde všechny instance textur a ošéfuje to.