A CONTROL Resonant első látványosabb jeleneteinél könnyű reflexből elővenni az FPS-számlálót. Path tracing bekapcsol, grafika feljebb, aztán nézzük, mit bír a videokártya. Régebben ez egész jól működött összehasonlításnak. Ha ugyanazon a pályán az egyik kártya 55, a másik 80 FPS-t hozott, nagyjából tudtuk, melyik mit tud. A Resonantnál viszont már érdemes egy kicsit tovább nézni annál a számnál, ami a képernyő sarkában ugrál, mert mögötte jóval több történik annál, mint hogy a GPU egyszerűen elkészít egymás után egy rakás teljes képkockát.
A Remedy új játékában a teljes path tracing mellé DLSS 4.5 Ray Reconstruction, felskálázás, RTX Mega Geometry és Dynamic Multi Frame Generation is társulhat. Mire a kép eljut a monitorig, nem egyszerűen az történik, hogy a GPU kiszámolt egy 4K-s frame-et, majd nekiállt a következőnek. A renderelés több lépcsőből áll, ezek közül pedig néhány éppen azért létezik, mert azt a látványt, amit Manhattanben látunk, hagyományos úton elképesztően drága lenne valós időben előállítani.
A Resonant Manhattanje amúgy sem egy steril városi díszlet. Az épületek és az utcák több helyen természetellenesen torzulnak, a gravitáció sem mindig abba az irányba működik, amerre elsőre várnánk, egy hétköznapi utcarészletből pedig pillanatok alatt olyan jelenet lehet, ahol egyszerre dolgozik rengeteg fényforrás, árnyék, törmelék, tükröződő vagy nedves felület és nagy mennyiségű geometria. Ilyen környezetben a path tracing már nem csak egy plusz tükröződés a grafikai menü alján, hanem jóval mélyebben belenyúl abba, hogyan áll össze a kép.
Mitől ilyen drága egy fény?
A hagyományos játékok világítása tele van ügyes csalásokkal. Ezt nem negatív értelemben mondom, ez a valós idejű grafika egyik alapja. A fejlesztők hosszú évek alatt megtanulták, hogyan lehet árnyéktérképekkel, előre számolt fényekkel, screen-space effektekkel és különféle közelítésekkel olyan képet készíteni, amely játék közben hihetőnek látszik, miközben a GPU-nak nem kell ténylegesen végigszámolnia minden fénysugár útját.
Ha például egy fényes padlón látunk egy tükröződést, attól még nem biztos, hogy a játék valóban tudja, mi történik a kamera mögött. Egy screen-space reflection csak abból az információból dolgozik, ami már ott van a képernyőn. Fordítsunk egy kicsit a kamerán, és bizonyos tárgyak egyszer csak eltűnhetnek a tükröződésből. Sokáig teljesen együtt éltünk ezzel, mert mozgás közben az ember általában nem áll meg azon gondolkodni, miért fogyott el fél autó az üvegben.
A ray tracing ezen próbált javítani azzal, hogy sugarakat követ a jelenetben. A path tracing még tovább megy, mert nem néhány külön kiválasztott effektet akar lecserélni, hanem a világítás jóval nagyobb részét ugyanabból az alapelvből próbálja felépíteni. Ez addig hangzik egyszerűnek, amíg nem kell mindezt valós időben kiszámolni.
Egy valós fényforrásból felfoghatatlan mennyiségű sugár indul minden irányba. Ezek a sugarak felületekről verődnek vissza, újabb felületekre jutnak, közben színt vagy intenzitást változtatnak. Egy játékban nyilván nem lehet minden pixelhez végtelen mennyiségű mintát használni, különben egyetlen kép kiszámítása tovább tartana, mint ameddig bárki hajlandó lenne várni rá. A valós idejű path tracing ezért eleve kompromisszumból indul: kevés mintából kell olyan eredményt előállítani, ami már elég tiszta ahhoz, hogy játék közben ne a zajt nézzük.
A nyers sugárkövetésből származó kép kevés mintánál zajos. Ha egyszerűen kiraknánk a monitorra azt, amit a GPU elsőre kiszámolt, a látvány szemcsés, instabil és több jelenetben kifejezetten ronda lenne. Korábban több külön zajszűrő dolgozott az árnyékokon, tükröződéseken és más ray traced elemeken. A Ray Reconstruction ennél több információból próbál stabilabb végső képet előállítani, ezért nem igazán érdemes úgy nézni rá, mint egy külön grafikai extrára. Path tracing mellett maga is része lett annak, hogyan készül el a használható kép.
Ezen a ponton már furcsább a helyzet, mint amit néhány éve egy hagyományos grafikai beállításnál megszoktunk. A GPU kiszámolja a jelenet geometriáját, anyagait és a fényterjedéshez szükséges adatokat, de a végleges pixel egy része rekonstrukció eredménye. Ettől még nem arról van szó, hogy a játék egyszerűen kitalálja a képet. Dylan ugyanott áll, az ellenfél ugyanott van, a fal geometriája sem egy mesterséges intelligencia fantáziájából születik. A különbség inkább az, hogy a végleges képhez már nem minden információt számolunk végig nyers erőből, pixelről pixelre.
Az ilyen rekonstrukciós megoldások nélkül a mai path tracinget jóval nehezebb lenne használható teljesítménnyel valós időben futtatni.
A geometria sem lett egyszerűbb
A fény önmagában még csak a probléma egyik része. A sugaraknak azt is tudniuk kell, mi van körülöttük.
Egy egyszerű, mozdulatlan szobában ezt könnyű elképzelni. Ott van négy fal, néhány bútor, pár tárgy. A mai játékok viszont rég nem ezen a szinten mozognak. A Resonant Manhattanje nagy, részletes zónákból áll, az építészet torzulhat, harc közben pedig egyszerre rengeteg objektummal, effektussal és apró geometriai részlettel találkozhatunk. A ray tracingnek ilyenkor nem elég annyit tudnia, hogy van előttünk egy épület. Meg kell találnia, melyik sugár pontosan mibe ütközik.
Az RTX Mega Geometry erre a növekvő geometriai bonyolultságra próbál választ adni. Ez kevésbé hálás marketingtéma, mint amikor egy grafikonon az FPS hirtelen kétszeresére ugrik, pedig hosszabb távon legalább ilyen fontos lehet. Nem sokat ér a kifinomult sugárkövetés, ha a jelenethez szükséges gyorsítóstruktúrák kezelése közben maga a háttérmunka emészti fel a hardver erőforrásait.
Nemrég hasonló problémával foglalkoztunk az AMD 80 GB-ról 1,7 GB-ra csökkentett ray tracing BVH-memóriaigényéről szóló cikkünkben. Ott egy szélsőségesen összetett, animált növényzetes jelenet mutatta meg, hogy a ray tracingnél nem csak a sugarak száma okozhat gondot. A háttérben azt is nyilván kell tartani, hol található az a rengeteg geometria, amivel ezek a sugarak találkozhatnak.
Nem ugyanaz a technológia dolgozik a két esetben, de a probléma gyökere hasonló. Ahogy részletesebbek lesznek a játékvilágok, úgy válik egyre nehezebbé maga a ray tracing köré épített háttérmunka is.
4K, de nem feltétlenül úgy, ahogy régen gondoltuk
A Super Resolution miatt a CONTROL Resonantnál sem szükséges minden esetben a kijelző natív felbontásán elkészíteni az alapképet. Ha 4K-s monitoron játszunk, attól még a motor renderelhet alacsonyabb belső felbontással, a DLSS pedig ebből állítja elő a 3840×2160-as kimenetet.
A régi gondolkodással ez egyszerű képminőség-veszteségnek hangzik. Kevesebb pixel készül, tehát a kép rosszabb. Csakhogy a temporális felskálázók már nem egyszerűen széthúzzák az alacsonyabb felbontású képet. Korábbi frame-ekből, mozgásvektorokból és más motoradatokból is dolgoznak, ezért olyan részletet is képesek stabilan megjeleníteni, amit egy hagyományos skálázásnál soha nem kapnánk vissza.
Nem minden jelenetben sikerül tökéletesen. Vékony tárgyaknál, gyors mozgásnál, részecskéknél vagy haj körül még mindig előjöhetnek hibák. Ezért sincs sok értelme két szóval lezárni az egészet úgy, hogy natív vagy mesterséges. Inkább azt érdemes nézni, játék közben melyik ad jobb képet elfogadható teljesítménnyel.
Ha egy magas minőségű DLSS-beállítás mozgásban stabilabb élsimítást ad, miközben olyan teljesítményt szabadít fel, amiből bekapcsolhatjuk a path tracinget, akkor már nehéz azt mondani, hogy a natív felbontás automatikusan jobb választás. Más jelenetben előfordulhat az ellenkezője is. Nem kell egyik technológiának sem drukkolni, meg lehet nézni, melyik néz ki jobban.
A Resonantnál ráadásul a felskálázás nem feltétlenül egy utolsó mentőöv gyengébb videokártyákhoz. Inkább része annak a renderelési költségvetésnek, amelyből a fejlesztők a jóval drágább világítást finanszírozzák. A belső felbontás csökkentésével felszabaduló teljesítmény egy része mehet olyan effektekre, amelyek natív 4K mellett már túl soknak bizonyulnának.
És akkor ott a Frame Generation
A hagyományos renderelésnél viszonylag egyszerű a helyzet. Ha a játék 60 FPS-sel fut, a motor másodpercenként nagyjából hatvan új renderelt képet készít. 120 FPS-nél sűrűbben érkezik az új állapot, ezért nemcsak a mozgás lesz simább, az irányítás visszajelzése is gyorsabb lehet.
Frame Generationnél a kijelzett FPS és az alapul szolgáló renderelési sebesség különválik.
Vegyünk egy teljesen szemléltető példát. Ha a Resonant egy adott gépen Frame Generation nélkül mondjuk 55 FPS körül futna, majd köztes képkockákat készítünk a valódi frame-ek közé, a monitoron ennek többszörösét is láthatnánk. A kamera mozgása tényleg folyamatosabb lenne, egy 144 vagy 240 Hz-es kijelzőt sokkal jobban ki lehetne használni, és egy ilyen látványorientált játékban ez nem valami értelmetlen trükk.
Az irányítás ettől még nem válik natív 150 FPS-es irányítássá. A generált frame egy köztes vizuális állapot. Attól, hogy bekerül két valóban renderelt kép közé, a processzor nem kezdi gyakrabban számolni a játék teljes szimulációját, és az új input sem ugyanúgy jelenik meg rajta, mintha a motor ténylegesen háromszor annyi friss állapotot készítene.
Erről részletesebben írtunk a Frame Generation 2026-ban: tényleg több FPS-t kapsz, vagy csak a számláló lesz nagyobb? című cikkben is. A Resonant pedig jó példa arra, miért érdemes külön kezelni a kijelzett képkockaszámot és azt, ami alatta történik.
Egy ilyen játék beállításánál nálam nem a Multi Frame Generation lenne az első kapcsoló. Először megnézném nélküle, milyen az alap. Ha mondjuk stabilan 55–70 FPS körül mozog a játék, rendben van a frametime és jó az irányítás, onnantól a képkockagenerálás kellemes plusz lehet. Ha viszont egy adott konfiguráción path tracing mellett 25 FPS környékére esik vissza az alap, abból hiába készül papíron 80 vagy 100 FPS a kijelzőn. A kameramozgás szebbnek tűnhet, az alacsony alap-framerate érzése viszont ott marad az irányításban.
Ezt egy egyszerű benchmark könnyen elfedi. Látunk két oszlopot, az egyiken például 43, a másikon 126 FPS, és elsőre természetesen a második tűnik sokkal jobbnak. Sokszor már kevésbé hangsúlyos, hogy a 126-ból mennyi volt ténylegesen renderelt képkocka, milyen volt a késleltetés, melyik DLSS-mód futott, és mekkora belső felbontásból készült a kép.
A CONTROL Resonant azért is jó példa, mert nem kompetitív lövölde. Egy történetközpontú akciójátékban sok játékos simán elfogad egy kis késleltetési kompromisszumot azért, hogy a path tracing megmaradjon és a kameramozgás közben simább képet lásson. Egy CS2-meccsnél valószínűleg teljesen más sorrendben lennének fontosak ezek a dolgok.
Az FPS mellé már kell a magyarázat is
Régebben egy mérésnél sokszor elég volt odaírni, hogy 2560×1440, Ultra, 78 FPS. Ma egy hasonló eredménynél szeretném tudni azt is, milyen felskálázást használtak, melyik minőségi módban, ment-e Frame Generation, aktív volt-e a Ray Reconstruction, milyen ray tracing beállítás futott, és mi volt az FPS képkockagenerálás nélkül.
Ugyanaz a 120 FPS ugyanis többféleképpen is megszülethet.
Az egyik gép valóban 120 új képet renderel másodpercenként. A másik mondjuk 60 környékéről jut el 120 megjelenített frame-ig. Egy harmadik ennél is alacsonyabb alap-framerate-ről használ több generált képkockát. Ránézésre a számláló ugyanazt írhatja, az egérrel vagy kontrollerrel viszont nem biztos, hogy ugyanazt érezzük.
Ebből persze nem következik, hogy csak a natív, hagyományosan renderelt FPS ér valamit. Ha kizárólag ezt tekintenénk elfogadhatónak, a modern path tracing nagy részét valószínűleg egyszerűen kikapcsolnánk. Könnyebb lenne a dolgunk, csak éppen nem azt a grafikát néznénk, amit ezekkel a módszerekkel el lehet érni.
Végső soron ugyanazt csináljuk, amit PC-n mindig is. Régen levettük az árnyékokat High-ra Ultráról, mert játék közben alig láttuk a különbséget, cserébe kaptunk tíz FPS-t. Később állítgattuk a volumetrikus ködöt, a tükröződést vagy a látótávolságot. Most azt döntjük el, hogy DLSS Quality vagy Balanced legyen, kell-e teljes path tracing, és mennyi generált képkocka fér bele úgy, hogy az irányítás még jó maradjon.
Más eszközök, ugyanaz a PC-s matatás.
Az ajánlott gépigénnyel is óvatosan
A CONTROL Resonant PC-s gépigénye első ránézésre még csak nem is tűnik őrültnek. Az ajánlott oldalon RTX 3060 Ti, Radeon RX 6700 XT vagy Intel Arc B580 szerepel, 16 GB rendszermemóriával és SSD-vel.
Ebből azonban nem következik, hogy egy RTX 3060 Ti-n fel lehet húzni mindent 4K Ultra path tracingre.
Régebben sem volt tökéletes az „ajánlott gépigény” kifejezés, ma pedig különösen kevés információt ad önmagában. Ajánlott milyen felbontáshoz? Milyen grafikai profilhoz? Natív képhez vagy felskálázással? Ray tracinggel? Mennyi FPS a cél?
Egy modern játék ugyanazon a videokártyán nagyon eltérően viselkedhet attól függően, mit engedünk rá. Ezért egy Resonant-tesztnél sem sokat mondana nekem annyi, hogy „RTX 4070: 115 FPS”, majd kész. Sokkal többet érne, ha mellette ott lenne a Frame Generation nélküli eredmény, a használt DLSS-mód és néhány szó a frametime-ról. Abból már el lehet dönteni, milyen élmény van a szám mögött.
Megéri-e a path tracing?
Erre nincs olyan válasz, amit minden gépre és minden játékosra rá lehet húzni.
Van olyan jelenet, ahol visszakapcsolva a hagyományos világítást rögtön feltűnik, mennyivel természetesebben ülnek a tárgyak a környezetben path tracing mellett. Máskor inkább csak akkor vesszük észre a különbséget, ha egymás mellé tesszük a két képet. Ha közben jelentős teljesítményt veszítünk, nem biztos, hogy mindenkinek ugyanaz lesz a jó választás.
A Resonant torz Manhattanje legalább hálás terep ehhez. Sok a változó világítás, rengeteg a kemény és fényes felület, az építészet sem marad mindig szabályos, a Control látványvilága pedig eleve szereti azokat a helyzeteket, ahol a fénynek komoly szerepe van a hangulatban. Egy világos, egyszerű belső térben valószínűleg kevésbé látványos a különbség, mint amikor egy sötétebb utcában neonfények, nedves aszfalt, üvegfelületek és különböző irányból érkező fények dolgoznak egyszerre.
Én ezért nem úgy állnék neki, hogy Ultra vagy semmi. Először úgy állítanám be a játékot, hogy Frame Generation nélkül is legyen használható alap-FPS, utána megnézném, melyik path tracing beállítás hozza azt a látványt, amit játék közben tényleg észreveszek. Ezután jöhetne a felskálázás finomhangolása, végül pedig a Frame Generation.
Fordított sorrendben nagyon könnyű szép számot gyártani egy rosszul beállított játékból.
Az FPS-számláló ettől még nem lett értelmetlen. Ha a monitor másodpercenként 160 különböző képet kap, akkor tényleg ennyit jelenít meg, és a generált képkocka is ott van a kijelzőn. A szám csak már nem árulja el önmagában, milyen gyakran készített új állapotot maga a játék, milyen belső felbontásból indultunk, vagy mennyi munkát végzett közben a rekonstrukció.
A CONTROL Resonant technikai oldala ezért érdekesebb annál, hogy egy adott RTX vagy Radeon hány FPS-t ír ki benne. Jól megmutatja azt a pontot, ahol a régi „hány FPS-sel fut?” kérdéshez már kell még néhány adat.
Milyen FPS-ről beszélünk, és hogyan készült el az a kép, amit végül látunk?
