HTML

gondolataim elsősorban játékfejlesztésről

Elsősorban játékfejlesztés magyarul: az enginem fejlesztése során felmerülő problémák, ötletek, tévutak stb dokumentálása, amely számomra és talán mások számára is hasznos lehet később Másodsorban gondolatok szavakban...

Kapcsolat:
aalberik 'at' gmail 'dot' com

Haletető

Galéria

Címkék

Összes

Linkblog

Naptár

május 2024
Hét Ked Sze Csü Pén Szo Vas
<<  < Archív
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31

Occlusion cull - hierarchical z-buffer visibility

2010.07.02. 11:27 :: syam

Hosszú idő és sok-sok próbálkozás után úgy látszik megszületett...
Az occlusion cull-ról már írtam korábban, de repetitio est mater studiorum avagy ismétlés a tudás anyja.

Az occlusion cull elve nagyon egyszerű: a renderelésből eldobja azon elemeket, amik az adott látótérben nem látszanának, mert takarásban vannak. Azonban - mint általában - ezt mondani könnyű megoldani viszont nehéz.

Mint a 3D megjelenítésben használt algoritmusok egy részének, ennek is két nagy csoportja van: image space és object space. Általában az object space megoldások CPU igényesebbek így emiatt az image space megoldások az érdekesebbek. Összehasonlításul: árnyékok renderelésénél az object space megoldás a shadow volume az image space pedig a shadow map.

Az occlusion cull image space technikái közül egy 1993-ban publikált tűnt nekem igéretesnek a hierarchical z-buffer visibility.

 Az algoritmus két részből áll.

  • Lerendereljük a lehetséges occludereket egy z-bufferbe majd a z-bufferből ún. z-piramist építünk (minden szint az előző méretének a negyede). Nagyban hasonló ez egy mipmap piramishoz viszont nem átlagolással történik a kicsinyítés, hanem az átlagoláshoz felhasznált négy érték közül a legnagyobb kerül át az alacsonyabb szintre.
  • A megjelenítendő elemeket összevetjük a z-piramissal. Levetítjük az elemet a képernyőre és így a z-piramisra is. Majd a z-piramis azon helyeiről kiolvassuk a mélység értékeket, amelyekre az elem vetült. Amennyiben bármelyik érték nagyobb, mint az elem bármelyik pontja akkor az elem látható.
    A z-piramis hierarchizált voltából következik, hogy nem kell az egész z-buffert végigvizsgálni, hanem alulról (1x1 mérettől) felfelé haladva viszonylag kevés összehasonlítással eldönthető a láthatóság.

A teljesítmény...

Óvatosan kell bánni ezzel az eljárással.

  1. Ha hardveresen rendereljük az occludereket, akkor a z-buffert vissza kell olvasni glReadPixels függvénnyel, ami a leglassabb lépése az eljárásnak. Gyorsítására elméletileg két lehetőség adott: PBO és RBO. Az előbbi valójában tovább lassít, ha nem sikerül kihasználni a visszaolvasási időt (esetleg dupla bufferelni kellene?). Valódi lehetőségnek az RBO tűnik. Idézet a GPGPU programming cikkből:

    Downloading is getting fast - with FBO / RBO extensions, glReadPixels() is speeding up (forget about PBO – Pixel Buffer Object)

  2. Minél inkább kevesebbszer történik az z-piramissal az összehasonlítás annál jobb: a biztosan látható elemek esetén nem szabad használni.
  3. Azt tapasztaltam, hogy felesleges felépíteni / használni a teljes a z-piramist kis méretű (64x64) z-buffer esetén. 
  4. Ha a jelenet nem tartalmaz elég megjelenítendő elemet / nem elég összetett, akkor kapcsoljuk ki az occlusion cullt, mert többet vesztünk CPU oldalon, mint amit a GPU oldalon nyerünk.
  5. Zsúfolt jelenet esetében akkor 10x - 15x teljesítmény növekedést is el lehet érni!

Mint látható maga az algoritmus semmiféle térfelosztó tulajdonsággal nem bír, hanem csak "mindössze" egy láthatósági vizsgálat. Ahhoz, hogy igazán hatékony legyen az algoritmus egy olyan térfelosztott jelenettel együtt kell használni, ahol igaz a hierarchiára, hogy ha szülő nem látszik, akkor a gyerekei sem. Ilyenkor a sokat emlegetett elemek a térfelosztási hierarchia csomópontjai és levelei.

 

Szólj hozzá!

Címkék: occlusion cull hierarchical z buffer visibility

A bejegyzés trackback címe:

https://sakura7.blog.hu/api/trackback/id/tr842124973

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Nincsenek hozzászólások.
süti beállítások módosítása