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

augusztus 2019
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

Tile-based deferred rendering - r1938

2014.05.02. 00:06 :: syam

A napokban ástam bele magam a címben említett témába. Sajnos ennek a neve megegyezik egy GPU architektúra nevével. Ebben a posztban a compute shaderrel megvalósított tile-based deferred rendering / shadingről lesz szó, amit mellesleg a Battlefield 3 (Frostbite 2 engine) is használ.

Ez a technika a deferred renderelés lighting szakaszát hivatott lecserélni. Ez a szakasz legtöbb esetben a következően szokott felépülni:

  1. fények frustum (és occlusion) cullja
  2. renderelés beállítása a lighting szakaszhoz
  3. fények renderelése egyesével / batchelve / instance-olva
  4. additív blendelés (adott esetben floating point rendertargettel)

Az első rész leginkább CPU-n végzendő műveleteket jelent (occlusion cull használata azonban igen költséges lehet).
Második részben a grafikus pipeline beállítása (blendelés, shaderek, shader változók stb.)
Harmadik részben sok-sok drawcall, shader váltások és beállítások, aminek a végeredménye blendelődik a  rendertargettel.
Mint látható az egész procedúra sok GPU és driver műveletbe kerül, mint drawcallok, floating point blendelés / ROP, fill rate stb. 

Ezeket azonban egy lépésbe össze lehet fogni compute shader segítségével - ezzel szinte ingyen kaphatunk occlusion cullt is (furcsa helyzet, hogy eddig CPU-n használt algoritmust írunk úgy, hogy hozzáférünk GPU erőforrásokhoz, mint pl. depth buffer)!
Az alapötlet az alábbi: a képernyőt felosztjuk N x M darab tile-ra, amikkel a compute shader fog dolgozni. Ez a shader fogja elvégezni a fenti 4 lépést egy lépésben:

  • minden egyes tile-ra kiszámol egy-egy frustumot (4 vagy 6 sík)
  • ezzel megvizsgálja az összes átadott fényt - ami akár több ezer is lehet - és kigyűjti azokat egy listába, amelyek potenciális hathatnak az adott tile-ba tartozó pixelekre
  • majd ezen lista és a g-buffer felhasználásával elvégzi az árnyalást
  • a végeredmény pedig legtöbbször egy textúrába kerül, amit már csak meg kell jeleníteni.

Azonban nincs végtelen kapacitásunk a compute shader használatakor sem. Az árnyaláson kívül a fény - frustum vágás algoritmusán lehet spórolni ( és persze a fények számán).
Ha az árnyalást már a nekünk tetsző formára alakítottuk ki és optimalizáltuk akkor megnézhetjük a fény - frustum vágást. Ebből nézzük a két leggyakoribb esetet a pontfényt és szpotfényt.
A pontfény esetén nincs túl sok választási lehetőségünk, de szerencsére ez az algoritmus nagyon egyszerű.
Bonyolultabb eset azonban a szpotfény. Ehhez négyféle algoritmussal próbálkoztam:

  1. gömb - frustum vágás hasonlóan a pontfényhez
  2. félgömb - frustum vágás
  3. szpotfény köré vont gömb - frustum vágás
  4. szpotfényt befoglaló négyzetalapú piramis - frustum vágás

És hogy miért is volt érdemes a 2 - 3- 4 esetekkel foglalkozni. A szpotfényt, mint egy gömbcikket közelíthetjük ugyan a teljes gömbbel, de a jóval nagyobb térfogat miatt nagyobb felületen fog lefutni az árnyalás. Emiatt tehát megpróbáljuk pontosabban közelíteni a szpotfény térfogatát. 

Végeredmény pedig következik az alábbiakból.
Minél pontosabban illeszkedik a gömbcikk térfogatához az algoritmus annál több / bonyolultabb számolást igényel. Tapasztalatom szerint a 2. változat a befutó. A 3. és 4. esetében a szpotfény - frustum vágás már annyival "bonyolultabb", hogy olyan helyzetben éri csak meg a bonyolultabb algoritmus ha azzal sok árnyalandó felületet spórolunk meg. Mivel ez igen jelenet- ill. bevilágításfüggő végül a szpotfényeket vágásához a 2. változatot használom.

Megjegyzés:
A 2. változat megoldásához először először csak a frustum síkjait valamint a félgömb sugarát, középpontját és félbevágó síkot használtam fel emiatt nem igazán tudtam megoldást találni.
Jóval később esett csak le, hogy a frustum síkjait a frustum pontjaiból számolom ki vagyis a frustum pontjaira is tudok építeni.
Innentől viszont egyszerű az algoritmus: a gömb - frustum vágás után - amennyiben szükséges - már csak a sík - ponthalmaz vágás eredménye kell.

Szólj hozzá!

Címkék: deferred shading occlusion cull tile based deferred rendering compute shader

A bejegyzés trackback címe:

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

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.