Új hozzászólás Aktív témák

• #46 Abu85 HÁZIGAZDA b. #44

  Új Válasz 2019-11-17 14:19:21 #46

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Abu85

  HÁZIGAZDA

  válasz b. #44 üzenetére

  De ez pontosan ugyanaz.

  A DXR és a Crytek-féle RT csak abban különbözik, hogy bejárás hogyan van megoldva. A DXR-nél háromszögek vannak BVH gyorsítóstruktúrába szervezve, de ennek van egy olyan hátránya, hogy a háromszög egy rendkívül rossz hatásfokú reprezentáció a BVH-hoz. A Cryteknek annyi a trükkje, hogy nem háromszögekkel dolgozik, hanem régebben csináltak még a voxel cone tracinghez egy voxelizációs eljárást. Ez az SVOTI-jük, és erre csinálnak pár effektet, például a GI-t. Ezt egyedül ők csinálták meg az iparágon belül, ugyanezzel a megoldással mindenki elhasalt, kivéve a Sony, de ők célhardverre (PS4) írták, ott azért egy probléma megoldása nagyságrendekkel egyszerűbb, mint egy rakás, eltérő felépítésű PC-s hardvernél. Na most mivel már volt egy ilyen technológiájuk, PC-s szinten gyakorlatilag egyedüliként, úgy döntöttek, hogy nem foglalkoznak a DXR-es BVH-val, hanem csinálnak maguknak egy olyan gyorsítóstruktúrát, amely már eleve a voxelizált jelenetet dolgozza fel. Ez nekik rém egyszerű volt, ott a voxelizációjuk a motorban, elég csak beolvasni. Ahhoz, hogy ez másnak is működjön, előbb meg kell oldani a voxelizációt, de ahogy írtam, ebbe minden PC-s fejlesztés bicskája beletört.
  Azzal, hogy maga a bejárás nem háromszögekre van alkalmazva, azt a hatalmas sebességhátrányt nem nyelik be, amit maga a háromszög, mint problémaforrás adna. Ezt a Microsoft a DXR-nél nem tudja megtenni, mert maga az API futószalagja követeli a háromszöget, mint reprezentációs elemet. Tehát effektíve, ha a jelenet objektumait egy bizonyos mélységű BVH-re fel is bontod, az utolsó szinten is lesz legalább egy olyan háromdimenziós tömb, amibe teszem azt kerül legalább 50-100 háromszög. Azokra mind le kell futtatni az intersectiont, még akkor is, ha a sugár ezekből csak egyet talál el. Ez a feldolgozás problémás és egyben lassú része, nem véletlen, hogy próbálnak a DXR-es játékok erősen spórolni a geometriai részlegességgel, mert van egy mélységlimit a BVH szempontjából, amibe bele kell férni, és ott sem árt, ha egy tömbben nem 100 háromszögre megy az intersection. A Crytek megoldása itt annyiban más, hogy ők már magát a intersectiont voxelekre végzik, és ez nagy előny, mert a voxel nagyon jól paraméterezhető reprezentációs elem, amivel el tudják például érni azt, hogy kis mélységgel is, csupán relatíve kevés vizsgálatra legyen szükség, bizonyos mértékig a geometriai részletességtől is függetlenül. Nekik ez valószínűleg azért fontos, mert a CryEngine egyik nagy fegyvere a geometria hatékony kezelése, de ha a DXR miatt ezt vissza kellene fogniuk mesterségesen, akkor a motor elvesztené azt a képességeit, ami miatt esetlegesen páran licencelnék. Emiatt kidolgoztak egy olyan eljárást, amivel ezt a képességet nem vesztik el, de közben meg is tudják oldani pont ugyanazt, amit DXR-rel csinálnak mások. Mert onnantól kezdve, hogy megvan valamilyen módon a traversal lépcső, az RT többi része már csak shading, és ebben a Crytek megoldása sem különbözik a DXR-től, van miss, closest hit és any hit compute shader, amelyek szépen futnak a multiprocesszorokon, pont ugyanúgy, ahogy az a DXR-en történik. Ezek adják ugye magát az effektet, visszaverődés, árnyék, GI, AO, akármi, ahogy megvan a traversal, onnantól kezdve minden megoldás ugyanaz.

  A fentiek miatt a Crytek megoldása is képes pontosan ugyanarra, amire a DXR, hiszen csak shadereket kell ehhez írni. Ha széttörik valami, az se gond, ugyanúgy látszani fog a visszaverődésnél, egymásra is tudnak hatni. Egyszerűen csak a compute shadert kell rá megírni, de mivel maga a működés ugyanúgy a miss, closest hit és any hit opciókra épít, így bármelyik DXR-re írt compute shader felhasználható a Cryteknek is. Persze annyi különbség van, hogy a DXR megköveteli a DXIL-t, míg a Crytek megoldása a D3BC kóddal is elvan, de ez igazából csak egy újrafordítás, valós jelentősége nincs. Az egyetlen dolog, ami miatt a Crytek ezt választotta, az a nagyobb sebesség, illetve kevesebb limit. A többiek pedig azért nem választják ezt, mert a CryEngine-ben benne van a működés alapjául szolgáló SVO, ami szinten mindenki másnak hiányzik.

  Egyébként a Crytek is tud majd hardveres gyorsítást használni ezzel, most még nem hasznos, mert a saját megoldásuk gyorsabb a DXR aktuális hardveresen gyorsított megoldásánál. Viszont a DXR 1.1 már elmozdul a programozhatóság irányába, ami például a Cryteknek pont jó, mert bizonyos problémákat rá tudnak ereszteni a fixfunkciós hardverre, anélkül, hogy a technológiájuk hatalmas sebességelőnyéről le kellene mondaniuk.

  [ Szerkesztve ]

  Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Új hozzászólás Aktív témák