A grafikus vezérlők erejének növelésével a részecskeszimulációs rendszerek egyre több figyelmet kapnak a kutatások szempontjából. Az erre épülő effektek sokszor igen látványosak tudnak lenni, és a szimuláció rendkívül jól párhuzamosítható, ami a mai hardvereknek nagyon is fekszik.
A részecskeszimulációs rendszereknek jellemzően két problémája van. Az egyik a CPU és a grafikus vezérlő közötti adatkapcsolat sebessége. A szimulációt ugyanis a CPU megoldja, majd azt a grafikus vezérlőnek át kell másolni, hogy képi eredménye is legyen. Szerencsére, manapság ez a gond nem igazán hátráltatja a modern videojáték-motorokat, mivel a fejlesztők már GPGPU-s algoritmusokban gondolkodnak, tehát maga a szimuláció is a grafikus vezérlőn történik, vagyis az adatmásolással nem kell törődni. Erre a PC esetében a DirectCompute felület jól használható, tehát ez a gond úgymond megoldotta magát.
A szimuláció azonban csak egy tényezője a problémának, mivel a részecskéket még ki is kell rajzolni. Utóbbi a rajzolási parancsok tekintetében nem jelent gondot, mivel egy jól felépített rendszer erre nem igazán érzékeny, viszont a raszterizálás már komoly probléma. A legtöbb jelenleg alkalmazott valós idejű részecskeeffektet az úgynevezett többletrajzolásból eredő limitációk korlátoznak. Egy jó minőségű szimulációban ezrével kell leképezni a részecskéket, ami ezért gond, mert egy részecske nem feltétlenül csak egy pixelnyi méretű, illetve nagyon jellemző, hogy a részecskék még átfedésben is vannak, tehát igen negatívan befolyásolják a hardverek pixel kitöltési rátáját (fill rate). Pláne úgy, hogy az összes mai hardver négyes pixelblokkokon dolgozik. Erre az elmúlt években számos megoldási javaslat született, így például értékelhető koncepcióvá vált a felezett méretű pufferbe való leképzés, ami ugyan gyorsított, de a nyilván a programon belüli mesterséges korlát csökkentette az effekt minőségét.
Emil Persson ötletes koncepciója a többletrajzolás problémájára [+]
Kedveltebb opció lett Emil Persson ötlete, miszerint vágjuk le az adott részecskeeffekt textúrájának azt a részét, ami úgy sem hordoz lényeges információt. Ezzel ugyan az a felület, amire végül a részecskeeffekt textúrája felfeszül több poligonból áll majd, de a négyes pixelblokkokon való raszterizálás mellett sokkal jobban kíméli majd a pixel kitöltési rátát, ami végső soron gyorsabb feldolgozáshoz vezet.
A fentiek azonban nem igazi megoldásai a valódi problémának, mivel olyan dolgokat is leképez a hardver, amelyek igazából nem is látszanak, tehát az erőforrás így is lényegtelen számításokra megy el. Ezzel a fejlesztők nem igazán tudtak mit kezdeni, így a részecskeeffekteket eleve úgy tervezték, hogy vagy ne álljanak túl sok részecskéből, vagy a játék dizájnjának kialakításánál gondosan ügyeltek rá, hogy a kamera sose mehessen túl közel az effekthez. Utóbbi ugyanis felerősíti a többletrajzolás problémáját, mivel egy részecske relatíve sok pixelt is elfoglalhat, vagyis akármilyen hardver van az adott számítógépben, a teljesítmény szimplán összeomlik. Az AMD erre a problémára most megoldást talált, mivel bevetették a jellemzően leképzésnél használt forward+ algoritmust, azzal a különbséggel, hogy ez az eljárás most nem a nem szükséges fényeket, hanem a nem szükséges részecskéket vágja ki még raszterizálás előtt. Ez tulajdonképpen azt jelenti, hogy az adott jelenet leképzésénél sosem számol a szükségesnél több részecskével a hardver, ergo a teljesítmény az eddig tapasztaltnál jóval konzisztensebb lesz függetlenül a részecskék számától és a kamera pozíciójától.
Az AMD részecskeszimulációs rendszerének sebessége Radeon R9 290X VGA-val [+]
Természetesen a mozaikokra osztott feldolgozás során az adott mozaikokban található részecskéket a kamerához viszonyított pozíció szerint rendezni kell, de az a mai hardvereknek már nem túl megterhelő, bitonic algoritmussal teljesen jól használható eljárásról van szó. Ezután a nem szükséges részecskéket ki is lehet vágni, és a megmaradt részecskékkel megkezdődhet a raszterizálás. A gyorsulás effektre levetített mértéke változó. Amennyiben a részecskék kevés pixelt foglalnak el, illetve az átfedés is csekély, akkor nagyjából 30%-os tempóelőnnyel lehet számolni a forward+ algoritmus bevetésével. Ám ha a kamera közel van a szimulációhoz, és a részecskék sok pixelt foglalnak el sok átfedés mellett, akkor a forward+ algoritmus ötször gyorsabb leképzést tesz lehetővé. Ez a két eredmény lényegében le is fedi a legjobb és a legrosszabb eshetőséget, így az általános gyorsulás mértéke mindig a két érték között lesz valahol.
Az AMD megoldása a problémára a DirectX 11 API alá készült DirectCompute 5.0-ban írva. A teljesen szabványos forráskód természetesen nyílt lesz, így a fejlesztők szabadon felhasználhatják, illetve igény esetén módosíthatják, vagy akár portolhatják az új generációs konzolokra is.
