Van a ray tracingnek egy olyan oldala, amelyről jóval kevesebbet beszélünk, mint a tükröződésekről, az árnyékokról vagy arról, mennyit esik az FPS, ha mindent maximumra húzunk. Pedig a háttérben dolgozó geometriai rendszer legalább ennyire fontos, csak kevésbé látványos. A játékos abból annyit érzékel, hogy valami vagy fut rendesen, vagy nem.
Egy statikus fal egyszerű eset. Ott van, nem mozog, a GPU tudja, hol keresse. Egy erdőben viszont egyszerre több ezer fa, bokor, levél és fűcsomó mozoghat, ráadásul nem feltétlenül ugyanabba az irányba vagy ugyanazzal a ritmussal. Fúj a szél, hajlanak az ágak, változik az árnyék, közben a ray tracingnek minden képkockánál tudnia kell, merre haladhat tovább egy sugár, mibe ütközhet bele, mi takar ki mit. Papíron ez csak még egy renderelési feladat. A gyakorlatban viszont az a fajta részlet, ami nagyon gyorsan megeszi a tartalékot.
Az AMD egyik friss kutatása ezt a problémát próbálja olcsóbban kezelni, és az első mérési eredmények elég komolyak.
A bemutatott jelenet nagyjából 25 000 külön animált növényt tartalmaz. Maximális részletességen összesen körülbelül 2,8 milliárd háromszögről beszélünk. A LOD-rendszer ebből egy adott képkockában nagyjából 500 milliót hagy aktívan a ray tracing számára, ami még így is hatalmas mennyiség.
Az egészet egy Radeon RX 9070 XT futtatta 1080p-ben, elsődleges és árnyéksugarakkal, 60 FPS felett. A hagyományos megoldással az ilyen animált geometria gyorsítóstruktúrái az AMD számításai szerint akár 80 GB körüli memóriát is kérhettek volna. Az új tetrahedral cage módszerrel ez körülbelül 1,7 GB-ra esett.
A 80 GB itt a ray tracing gyorsítóstruktúráira vonatkozik, nem a teljes játék VRAM-fogyasztására. Ennyi pontosítás kell, különben félrecsúszik az egész szám.
A háttérben a BVH, vagyis a Bounding Volume Hierarchy dolgozik. Ez segít abban, hogy a GPU ne minden sugárnál kezdje végignézni a jelenet teljes geometriáját. Több százmillió háromszögnél ez eleve reménytelen lenne, ezért a BVH térbeli csoportokra bontja a jelenetet, majd fokozatosan szűkíti, hol lehet tényleges találat.
Statikus jelenetben ez kezelhetőbb, mert az objektumok helye nem változik minden képkockában. Egy mozgó fánál már több dolga van a rendszernek. Ha az ágak, levelek és kisebb részletek folyamatosan deformálódnak, a gyorsítóstruktúrának is követnie kell ezt.
Egyetlen fa még nem ügy. Huszonötezer viszont már az.
A tetrahedral cage módszer úgy kerüli meg a problémát, hogy a részletes modell köré egy jóval egyszerűbb, tetraéderekből felépített szerkezetet helyez. A mozgást főleg ez a ketrec követi, miközben a részletes geometria megmarad.
Amikor egy sugár elér egy deformált tetraédert, a rendszer átszámolja azt a modell eredeti, nyugalmi állapotának megfelelő térbe. A metszésvizsgálat ezután már a statikus geometriával történhet. Elsőre elég mérnökös megoldásnak hangzik, de a gondolat egyszerű: ne a legdrágább részt mozgassuk újra és újra, ha elég egy könnyebb közelítés.
Ez főleg ott működhet jól, ahol az objektum alapformája nem változik meg teljesen. Egy fa hajlik, a lomb mozog, az ágak csavarodnak, de nem alakul át valami teljesen mássá.
Aki játszott eleget a 2000-es években, biztosan találkozott azzal, hogyan próbáltak a régebbi motorok spórolni a növényzettel. A távoli fák néha lapos textúrává változtak, a fű pár tíz méter után eltűnt, egy teljes mező pedig ugyanazzal a néhány animációval mozgott. Nem feltétlenül volt szép, de működött. Akkor még sokszor annak is örültünk, ha a játék nem kezdett el köhögni egy sűrűbb erdőben.
Ma sokkal kifinomultabbak ezek a trükkök, a geometria mennyisége pedig közben megsokszorozódott. A ray tracing erre még rátesz egy lapáttal, hiszen a sugarak útját is követni kell a sok mozgó részlet között. Az AMD bemutatója ezért használ ennyi növényt: itt gyorsan kijön, hol kezd fájni a hagyományos megközelítés.
A számítási időnél is nagy az eltérés. Az AMD szerint a hagyományos, sűrű geometriát követő BLAS-frissítés több mint 300 milliszekundumot is elvihetett volna ennél a jelenetnél.
60 FPS-nél egy teljes képkockára körülbelül 16,7 milliszekundum jut. Ehhez képest a 300 milliszekundum már nem lassú, hanem egyszerűen használhatatlan. A tetraéderes megoldással ugyanez a munka nagyjából 3,3 milliszekundumra csökkent.
A memóriaoldali különbség hasonlóan nagy. Itt már nem néhány százalékos optimalizálásról beszélünk, hanem arról, hogy egy jelenet egyáltalán belefér-e a keretbe.
A VRAM miatt ez különösen érdekes. Az elmúlt években egyre több játéknál láttuk, milyen gyorsan elfogyhat a videokártyák memóriája magas textúraminőség, nagy felbontás és ray tracing mellett. Egy 12 GB-os kártya sok esetben még bőven elég, aztán jön egy rosszabbul sikerült port vagy egy agresszívebb beállítás, és hirtelen már minden tartalék számít.
Ha egyetlen részfeladatból több tíz gigabájtnyi memóriaigény vágható le, az fejlesztői oldalról nagyon komoly mozgásteret ad. Ettől persze nem lesz egyik napról a másikra minden VRAM-probléma megoldva, de itt nem is ez a lényeg. Az számít, hogy ugyanazt a jelenetet mennyivel kisebb költséggel lehet kezelni.
A PUBG DLSS 4.5 és FSR 4.1 teljesítményét vizsgáló tesztünkben is látszott, mennyit számít ma már az, hogyan használja fel egy grafikai rendszer a rendelkezésre álló erőforrásokat. A modernebb technikák egyre gyakrabban ugyanazt a problémát próbálják kisebb költséggel megoldani.
A tetrahedral cage hasonló gondolkodás, csak más ponton nyúl bele a folyamatba. Már a mozgó geometria kezelésénél próbálja visszafogni a terhelést, jóval azelőtt, hogy elkészülne a végső kép.
Játékosként ebből valószínűleg nem egy új menüpontot látunk majd. Inkább azt, hogy egy erdő sűrűbb, több objektum mozog, vagy kevésbé agresszíven kell lebutítani a távolabbi részleteket.
Ez egyébként pont az a fajta technika, amit jó esetben nem veszünk észre. Ha feltűnik, valószínűleg valamit rosszul csináltak.
Az egyszerűbb tetraéderes ketrecnek azért megvan az ára: kevésbé pontosan követi a részletes modell minden apró deformációját. Egy távoli bokornál ez valószínűleg fel sem tűnik. Egy közeli karakter arcán már igen.
Az AMD ezért főleg növényzetnél, tömegjeleneteknél és távolabbi karaktereknél lát benne lehetőséget. Ez teljesen logikus. A játékmotorok amúgy is folyamatosan csalnak a részletességgel, csak ma már jóval ügyesebben, mint húsz éve.
A bemutató RX 9070 XT-n futott, ami legalább azt megmutatja, hogy az alapötlet mai hardveren is működőképes lehet.
Innen már sokkal inkább az a kérdés, mennyire könnyű használni.
Az AMD DirectX Raytracing mintákon és egy C++ könyvtáron dolgozik, amely a tetraéderes ketrecek létrehozását segítené skinnelt, keyframe animált és statikus objektumokhoz. Ez a része jóval kevésbé látványos, mint maga a demó, de hosszú távon talán fontosabb is.
A fejlesztők ugyanis nem azért hagynak ki egy technikát, mert nem elég érdekes, hanem sokszor azért, mert túl drága beépíteni. Egy jól dokumentált könyvtár ezen rengeteget változtathat.
A HPG 2026-os előadás technikai anyag, de aki tényleg kíváncsi arra, hogyan épül fel a módszer és mit mértek pontosan, annak érdemes belenéznie.
A Frame Generation működéséről és FPS-re gyakorolt hatásáról szóló elemzésünkben olyan technológiával foglalkoztunk, amelynek hatása azonnal látszik az FPS-számlálón. Ennél valószínűleg más lesz a helyzet. A motor használja majd ott, ahol értelme van, a játékos pedig jó esetben csak a végeredményt látja.
A kutatás mögött Holger Gruen, Carsten Benthin, Michael Kern és David McAllister áll, a munkát pedig a HPG 2026 konferencián mutatták be. Innen még simán lehet hosszú út egy konkrét játékig, és az is benne van, hogy a végleges megoldás már nem pontosan ebben a formában jelenik meg.
Ettől függetlenül ez az egyik érdekesebb ray tracinges fejlesztés mostanában, főleg azért, mert nem még több nyers erőt kér ugyanarra a problémára.
Ha valamelyik nagy motor vagy stúdió felkapja, valószínűleg nem a „tetrahedral cage” név marad meg bennünk. Inkább az, hogy ugyanazon a videokártyán egyszer csak több minden mozog, és kevésbé fogy el alóla a levegő.
