A proxy mesh maga a probléma része. Ez egy kerülőút az UE5-ben, hogy működjön nekik a DXR a programozható bejárás nélkül, de annyira limitáltak alacsony részletességű proxy mesh mellett a képi lehetőségek, hogy a Microsoft meg se próbálkozott a használatával. Nem azért, mert nem volt beépítve, hanem azért, mert megfelelő minőségű hw RT alkalmazásához nem szabad nagyon visszavenni a részletességet a proxy mesh esetén, és akkor meg bő +10-15 GB a VRAM terhelése. Itt érdemes számításba venni, hogy a Hellblade 2-ben pár objektum részletessége akkora, mint máshol egy teljes pályáé. Egészen mások a lehetőségek.
Mellesleg attól, hogy proxy mesh-ed van, még ugyanúgy nem tudod kivágni a nem látható geometriát DXR-ben.
Ez a probléma egyébként létezik a DXR megjelenése óta, és nem megoldható programozható bejárás nélkül, mert azzal hozod be a LOD-ot. Iszonyat sok kritikát kapott anno a DXR 1.0 nagyon komoly fejlesztőktől, és hát ugye a DXR 1.1 is csak inline RT-t hozott, tehát megoldást nem. Mert azzal nem vagy kisegítve, hogy az RT csak pár virtuális méterig működik a kamerától, vagy annyira alacsony az RT-vel dolgozó proxy mesh részletessége, hogy szimplán jobb minőséget ad a Lumen, mert jobb részletességű adatokkal dolgozhat. Ez a melyik kezembe harapjak effektus, és látható, hogy még a DXR megalkotója sem akar egyikbe sem beleharapni, mert maga a szabvány a fos.
Igazából az egyetlen alternatív lehetőség az, ha írnak egy olyan RT rendszert, amivel az Ubisoft előállt a Snowdrop 2-ben, de a Microsoft valószínűleg már a resetet tartja szem előtt, így nem látták értelmét a mostani szabványokat pacskolgatni.
Mellesleg egyébként az UE5-be valószínűleg készül brixelizer plugin, tehát abban is alkalmazható lesz Snowdrop 2-höz hasonló rendszer, de ennek nem sok értelme, mert úgyis nyomnak egy resetet a következő DXR-nél, ás akkor a brixelizer is megy a kukába.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.