Még a hónap elején merült fel, hogy érkezik az Ubisoft új Snowdrop 2.0-s videojáték-motorja, amelyről máig csak annyit tudni, hogy nagymértékben épít majd a sugárkövetésre, de nem úgy, ahogy az eddigi játékok, sokkal inkább ésszel próbál közelíteni a problémakör felé. Az viszont máig nem tiszta a felhasználók számára, hogy pontosan miképpen lesz nagy teljesítményű a sugárkövetés, hiszen a hardverek elvileg adottak, és ezek elérhetők két szabványos API-n keresztül is. Innen adódik a kérdés, hogy min tud egyáltalán változtatni egy alternatív megközelítés, már ha lehet egyáltalán javítani a mostani helyzeten?
Az új Snowdrop képességeinek utánakérdeztünk az elmúlt időszakban, és megtudtuk, hogy az Ubisoft alapvető problémája a két szabványos API-val az volt, hogy az egész sugárkövetés egy nagy feketedobozként valósul meg bennük. Vannak bizonyos funkciók, amelyeket a shaderekben meg lehet hívni, de ezek nagy része limitált lehetőségeket ad, és maguk az API specifikációk is rendkívül titkolózók az alkalmazott BVH adatstruktúra-formátumával kapcsolatban. Utóbbit persze a fejlesztőnek nem is kell ismerni, mert a jelenlegi modell a Vulkan és a DirectX Raytracing esetében is annyiból áll, hogy a limitált lehetőségek szerint megírt kód alapján a driver majd csinál valami, fejlesztői oldalról láthatatlan "fekete mágiát", és ha jó az eredmény, akkor örülni kell. Itt felmerülhet a kérdés, hogy mi van akkor, ha nem túl jól muzsikál a megírt kód? Ez a bonyolultabb eset, ugyanis ilyenkor a végére kell járni annak, hogy hol a gond. Netán az alkalmazott gyorsítóstruktúra egyes limitációi erősödtek fel? Lehet, de mivel ez nem ellenőrizhető, így biztosra nem jelenthető ki. Elképzelhető, hogy a munka ütemezése kapcsán került homokszem a gépezetbe? Nem kizárható, de nem tudni, hogy mi az optimális egyensúly az erőforrás-kihasználásban, amire törekedni kellene a sugárkövetés használatakor. És ezeket a kérdéseket lehetne még folytatni, ugyanakkor egyértelmű válasz egyikre sincs, mert minden teljesítményt meghatározó döntés a futtatási környezeten vagy a meghajtón belül történik, gondosan elrejtve a fejlesztői szemek előle. És nem azért, mert ez így jó, hanem azért, mert ezt az implementációt követeli meg a Vulkan és a DirectX Raytracing API.
Szóval a szabványos sugárkövetéssel kihozható valamilyen módon egy adott sebesség, akár úgy is, hogy a sugarakkal való kalkuláció virtuális távolságát korlátozzák, de érdemi előrelépést biztosító optimalizálásokra nincs lehetőség, mert a szabványos implementációk ezeket egyszerűen nem teszik lehetővé.
Úgy tudjuk, hogy a fenti problémák zömét az adja, hogy az elérhető API-k által használt egyedi BVH adatstruktúra-formátum zárt. Ezt a fejlesztőknek elvileg el kell fogadniuk, hogy így működik, és érdemi befolyásuk nincs rá. Az Ubisoft viszont pont ezen a ponton nyúl bele a rendszerbe, jobban mondva ezen a ponton kerüli meg azt. Mivel a szabvány nem ad nyílt egyedi BVH adatstruktúra-formátumot, ezért szereztek egyet szabványon kívülről, amivel lehetőség nyílik az egyedi BVH bejárási logika kidolgozására. Ennek két előnye van. Egyrészt minden döntés programozott, tehát nem egy kapott, nagyrészt ismeretlen képességű rendszerrel dolgoznak, hanem egy saját maguk által írttal, és ennek pontosan tudják az előnyeit, illetve hátrányait. Másrészt eltűnik a rendszer feketedoboz jellege is, tehát innentől kezdve ellenőrizhető, hogy a programkód mely része okozza lassulást, és ezáltal könnyen javítható egy esetleges hiba.
Az Ubisoft nagy teljesítményű sugárkövetését ugyanakkor a gyártóknak direkten támogatniuk kell, hiszen több ponton is megkerüli a rendszer a szabványokat. A jó hír, hogy ezt az alkalmazott konstrukció nyíltsága miatt meg lehet tenni gyakorlatilag akármelyik Vulkan vagy DirectX Raytracinget ma is támogató hardveren, de a megfelelő implementáció kidolgozása teljesen a gyártókon múlik. Sajnos egyelőre csak az AMD csatlakozott, viszont a labda ott pattog az Intel és az NVIDIA oldalán is, és van még idejük dönteni arról, hogy mit szeretnének.
