3D engine - razeni objektu pred vykreslenim

[vaseo]

Hledam idealni reseni pro vykreslovani objektu ve scene pro 3d engine. Jde o DX9 s obecnymi, castecne dynamickymi objekty.
Co je v planu:

1. view frustum culling - na zaklade bounding volume hierarchie
- vybere objekty k vykresleni z BVH stromu

2. vytvoreni/update(?) datove struktury s hierarchii vykreslovanych objektu podle:
a. transformaci - scene graph (potomci dedi transformacni matici)
- minimalizace nasobeni trans.matic a jednoducha sprava pomoci matrixstack
b. parametru - textur, shaderu atd
- minimalizace prenastavovani parametru a stavu dx9 device

3. zvlast kategorie pruhlednych objektu - razene podle aktualni hloubky

Je mi jasne, ze nepujde vse najednou. Je mozne tohle nejak elegantne dat do datove struktury (jake?) s rozumnou slozitosti vytvoreni/updatu?

[OndraSej]

Pro razeni objektu ve scene se - podle jeji slozitosti - pouzivaji bud ruzne mrizky (pravidelne rozkrychlovani), nebo stromove struktury. Doporucuji googlit BSP tree (binary space partitioning tree) nebo Octtree.

Vsechny tyhle struktury svym zpusobem definuji usporadani objektu a jsou na vytvoreni i manipulaci pomerne efektivni.
_________________
http://trionteam.net

[Augi]

No imho je už BSP trošku out, dnes spíš letí Octree, příp. různé variace na quad tree.

Já osobně bych se vydal cestou 1 kombinovanou s 2a. Tedy mít scene graph, který je založen na dědění transformací - toto dědění jde od zpoda nahoru. Nody ve scene graphu by pak měly ještě třeba bounding spheres, který by se naopak dědily od zpoda (tedy na základě bouding spheres potomků vypočtu bouding sphere předka). Aby dynamické objekty nezpůsobovaly časté přepočítávání transformačních matic a bounding spheres, tak bych je umístil jako leafy co nejvýše ve scene graphu.

Před vykreslováním bych prošel celý strom tak, že bych se pustil do zpracování potomků aktuálního nodu jen tehdy, pokud by byl aktuální node vykreslen (na základě kolize bounding sphere vs. kamera). Zpracovávané objekty bych si strkal do nějakých struktur vhodných pro vykreslení - např. dvě dynamická pole - jedno pro neprůhledné a druhé pro průhledné objekty. Neprůhledné objekty bych pak seřadil od nejbližšího po nejvzdálenější a průhledné opačně (vzhledem ke vzdálenosti od kamery).

[vaseo]

BSP jsem nikdy neprisel na chut, quad/octtree je skvelej, ale pro obecne rozmisteny objekty ma nevyhodu, ze nektere objekty lezi na rozhrani vice bloku.
Vcelku jsem si oblibil BVH, ktery je imho nepravem opomijen. Vyhodou je, ze strom konci vzdy v listech prave s jednim objektem, nevyhodou je prekryvani bounding volumes jednotlivych uzlu, ale to ve vetsine pripadu neznamena zadne zpomaleni.

Diky za radu, taky mi prijde nejlepsi kombinace scene grafu s BV. Problem muze nastat, kdyz se transformacni hierarchie bude naprosto lisit od BVH. Tzn. kdyz treba transform root bude nejmensi objekt a uzly vetsi az list treba obrovskej skybox, takze se bude prochazet vsechno, i kdyz kamera zachycuje jen rozek skyboxu.
Alespon ze jen prochazet a ne vykreslovat - do kazdeho uzlu dam krome testu BV zdedeneho od potomku (jak jsi navrhl) jeste vlastni BV jen daneho objektu v uzlu a to se bude pred kreslenim testovat zvlast.

[Marek]

Myslim, ze tema je vicemene vyreseny, ale mam par poznamek:
1) Obrovskej skybox? Rozek skyboxu? Skybox je pozadi na zadni orezavaci rovine (idealne implementovany pomoci jednoho trianglu a ne pomoci krychle), zadnej rozek neni viditelnej, tak jakej rozek? Myslim, ze nemusis testovat, jaka cast skyboxu je viditelna, pixel culling vyresi karta za tebe efektivneji, spis dodrz poradi kresleni, jak rekl Augi, a snaz se snizit pocet vertexu.
2) Jenom to s temi scenegraphy moc neprezen. Doporucuju precist clanek Scene Graphs - just say no
_________________
AMD Open Source Graphics Driver Developer

[vaseo]

no jasne, to byl priklad jakoze velikyho predmetu jasne, ze nebudu testovat skybox na rozky, jde o to, ze by cela vetev stromu az ke koreni byla testovana, protoze i ten nejmensi (korenovy objekt) by prebral obrovsky BV potomka - toho skyboxu. extremni priklad uznavam.

zajimavy clanek, ubezpecil me, ze varianta 2b je hloupost. On scene graph umi uzasny veci, ktery nemusi byt videt ani na druhy pohled, ale nese s sebou i nevyhody popsane v clanku (muze narust do obrovskych rozmeru), tak je to vzdycky ze.

[frca]

[Marek]

Skybox nahrajes jako cubemapu a tu namapujes na trojuhelnik, ktery pokryva celou obrazovku, asi nejak takhle:



Jeho souradnice muzes zadat v clip-space, osu Z nastavis na zadni orezavaci rovinu. Texturove koordinaty spocitas tak, ze vezmes kazdy vertex v clip-space a vynasobis ho matici (projection*modelview)^-1. Omrkni ATI SDK, skoro v kazdem jejich demu maji skybox implementovany prave takhle.
_________________
AMD Open Source Graphics Driver Developer

[xtopi]

a v čem je výhoda udělat skybox jako jeden trojúhelník? jestli so to pak ještě skybox dá nazývat .. Protože skybox jako takovej má 8 vertexů, a transformace 5 vertexů navíc je v celý scéně úplně zanedbatelný číslo. Nebo to má ještě dalši důvod?

[posila]

Ja teda vyhodu vidim v tom, ze kdyz se to dobre udela, nejsou videt ty obavane "rohy" skyboxu.

[Marek]

Kdyz se pouzije cubemapa, nebudou videt ty "rohy kostky", protoze mapovani bude radialni a ne planarni jako u 2D textur. Mohli jste si vsimnout, ze nejsou videt zadne hrany - na hranach se totiz pixely musi pocitat 2x - vzdycky pro oba sousedici trojuhelniky. Nevim, proc to tak je, tvrdi to borci z AMD.
_________________
AMD Open Source Graphics Driver Developer

[nou]

no na skybox ktory je robeny ako klasicka kocka pomoze glTexParameteriv(GL_TEXTURE_2D ,GL_TEXTURE_WRAP_S, GL_CLAMP); plus este aj _T hranu. a ziadne hrany nevidim.
_________________
Najjednoduchšie chyby sa najtažšie hľadajú.