Keresés

Hirdetés

!!! SZERVERLEÁLLÁS, ADATVESZTÉS INFORMÁCIÓK !!!
Talpon vagyunk, köszönjük a sok biztatást! Ha segíteni szeretnél, boldogan ajánljuk Előfizetéseinket!

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

  • Carlos Padre

    veterán

    válasz b. #10 üzenetére

    Elterjedt tévhit (vagy szándékos fanboy dezinformáció) ez a "kamu rt". Valami vagy számolja a sugarakat vagy nem, ha számolja akkor az rt, ha nem akkor meg raszteres trükk. Ahogy az is bullshit, hogy az Nvidia megoldása az "igazi", mert az hardver rt. Fixfunkciós egységekkel gyorsított szoftveres rt az is, mint a többi. Olyan van, hogy buta, brute force rt, meg van okos rt, többféle megoldás is, aki foglalkozott már legalább hobbiból rendereléssel tisztában van ezekkel.

  • Abu85

    HÁZIGAZDA

    válasz b. #44 üzenetére

    Nincs olyan, hogy hardveres RT. Minden szoftveres. A DXR alatt is shadereket írsz, ahogy a Metal-féle megoldás, illetve a RadeonRays alatt is. Csak más nyelveken. De ettől az még szoftver, programkód, ami lefut a hardvereken bizonyos API-kon keresztül.

    ---

    Szerkesztetted.

    Milyen játék kiadása? Az Ogre3D egy motor. Alapvetően az RT megoldások előnye, hogy nagyon gyorsan implementálhatók. A sebesség a hátrányuk, így az optimalizálás, már nagyságrendekkel tovább tarthat, mint a régi technikáknál. Különösen akkor, ha nem tudható, hogy konkrétan mit csinál az gyorsítóstruktúra. Nem megoldhatatlan ez a probléma sem, de nem könnyű.

    Most PR-ra csapatjuk, vagy valódi programozói véleményre? A PR nyilván benyal tövig. A te pénzedből élnek, azt akarják, hogy elhidd, hogy minden kíííbaszott fasza. Ha kételyed támad, akkor nem adod nekik a pénzed, és nem tudnak majd új kocsit venni naponta. :))

  • Abu85

    HÁZIGAZDA

    válasz b. #42 üzenetére

    Mármint az, hogy feketedoboz a hardver? Azért feketedoboz, mert nincs dokumentáció arról, hogy mit csinál, így nem tudod, hogy hol a határa. Ilyenkor két dolgot választhatsz. Ráhagyod, mert így túlzott erőforrásba kerül megcsinálni, vagyis nem foglalkozol az elmélettel, és elkezded bőszen tesztelni a gyakorlatot. Ha sok jelenetet átnézel, és kielemzel, amely alapján mondjuk nincs probléma, akkor nagy valószínűséggel nem lesz gond. De ez több hónapos munka.

    Ez nem igazán más út, csak nem hülyék, hogy valós előnyt nem biztosító esetekhez is sugárkövetést használjanak. Minek?

    Az, hogy mivel csinálod a sugárkövetést, majdnem mindegy. A RadeonRays elsődleges előnye az, hogy API-tól független, míg a Metal Raytracing azért fontos, mert az Apple piaca fontos az Ogre számára. A DXR-hez viszont DirectX 12-kel, vagy gyártóspecifikus szinten Vulkan, tehát a fő leképezőt, vagyis a DX11-et előbb normálisan le kell cserélni.

    Egy olyan hardvernek eleve nem tudsz megfelelni, aminél nem tudod, hogy miképp működik. Egyedül hónapokig tartó tesztelésre építhetsz.

  • Abu85

    HÁZIGAZDA

    válasz b. #39 üzenetére

    Az, hogy a Microsoft és a Sony dokumentációt fog adni, a fejlesztőktől van, hiszen erről kérdeztem őket.

    Az, hogy az NV nem ad dokumentációt Matías N. Goldbergtől, az Ogre motorprogramozójától. De le is írta a röviden a helyzetet az egyik blogbejegyzésében:
    "You probably have heard RTX (aka NVIDIA’s raytracing, ‘DXR’ in D3D12 lingo) to have been doing a lot of fuzz lately.

    It’s not exactly clear whether the current generation of HW accelerated raytracing is the way to go (due to the the acceleration tree structures used by vendors is currently a black box, which could result in wild performance variations in the future depending on the scenes), but it is undeniable the industry will be moving towards raytracing hybrids in the future." - [link]

    Természetesen nem véletlenül, fizetnek érte. De még így is lemondják néhányan, mert aránytalanul nagy munka kitesztelni, majd megfelelően optimalizálni. Lásd Assetto Corsa Competizione.

    (#41) Ragnar_: ;]

  • Abu85

    HÁZIGAZDA

    válasz b. #37 üzenetére

    Attól, hogy az API ad egy specifikációt, hogy megírd a shadereket, még nem tudod a hardver dokumentációjának a hiányában ellenőrizni, hogy a program amit írtál nem ütközhet-e olyan helyzetbe, ami drasztikusan csökkentené a sebességet. Emiatt mást nem tudnak csinálni a fejlesztők most, mint hónapokig tesztelni az ilyen helyzetek után.

    Ezért van az, hogy JHH-t baszogatják a userek a "just works" szöveggel, mert abban igaza van, hogy just works maga a dolog, csak nagyon hosszú tesztelés kell, hogy erről meg lehessen bizonyosodni. De ez nem kellene, ha elárulnák, hogy miképp működik a hardver.

  • sb

    veterán

    válasz b. #7 üzenetére

    Sok helyen elfogultan szokott fogalmazni Abu, de ez hülyeség amit írsz.
    Az API ismeretével nyilván tudsz programot írni de az extra - és ez adhatja a plusz sebességet - ha látod mögötte mit tud a hw pontosan és azt hogyan valósítja meg.

    Ahogy egy x86 prociról is ismerjük az utasításkészletét, de az optimalizációt az adja, hogy tudod mit hány órajel alatt futtat, hány regisztere van, milyen utasítások hatnak egymásra, mekkora a cache, miylen szervezésű, stb...

    És ha több hw architektúra van akkor is lehet többre optimalizálni. Vagy épp olyan megoldás választani ami mindkettőnek viszonylag jó ha eltér a hw-s implementáció.

  • Carlos Padre

    veterán

    válasz b. #7 üzenetére

    Ebben csak az a gáz, hogy a szabványos DX 12 RT-t csak úgy összedobták, hogy legyen valami ami támogatja az Nvidia megoldását addig is amíg kijön a végleges RT megoldás és az nvidia ne tudjon kialakítani egy saját zárt ökoszisztémát, a'la Glide.

  • Abu85

    HÁZIGAZDA

    válasz b. #21 üzenetére

    A VXGI nem gyors, de csak akkor nem, ha valami megmozdul a jelenetben. Viszont nem a voxelizálás a probléma vele, hanem maga a VXGI implementáció van elbaszarintva. A Cryteknek láthatóan semmi gondja nincs a VXGI-hoz hasonló SVOTI-jal. Ha van egy ötlet, és azt két érintett eltérő módon ugyan, de megoldja, viszont az egyiknek nem működik, míg a másiknak igen, akkor nem az ötlet a gond, hanem a nem működő implementáció el lett cseszve. A Cryteknél ügyesebbek voltak.
    De nem csak a Cryteknek sikerült. Ott a SEGI a Unity-hez például. Az is ugyanarra az ötletre épült, mint a VXGI, és működik. Itt nem az ötlet a rossz, hanem valami nagyon félrement a VXGI implementációjánál, és az NV nem nagyon foglakozott vele, hogy ezt kijavítsa. Egyszerűen úgy döntöttek, hogy nyomnak egy shift+del-t és kész.

    Nem nagyon különbözik a Crytek-féle sugárkövetés a Frostbite-féle megoldástól, ha a tükröződés effektet nézzük. Az elv hasonló, csak az információ van máshogyan tárolva. Ezért érdekes ez a voxeles megoldás, ami PC-n eléggé kényes, mert a visszafelé kompatibilitás fontos, de konzolon ezzel nem kell foglalkozni.

  • Abu85

    HÁZIGAZDA

    válasz b. #19 üzenetére

    Ezt légyszi fejtsd ki bővebben, mert nem igazán jön át, hogy mire gondolsz pontosan.

    Szerk.:
    A részletesség konfigurálható.
    Az tök mindegy, hogy a kamera fixen mozog, vagy szabadon. A számítás nem változik. Lásd 3DMarkok.

    Ilyenre nem emlékszem, de a voxelek esetében nem igazán a csoportosítás a lényeg. Inkább a geometriai információk tárolása így olcsóbb a sugárkövetés tekintetében. Sokkal olcsóbb a hardver szemszögéből. Nyilván ennek is megvannak a maga nyűgjei, például ma az, hogy a grafikai futószalag ezt nem támogatja, tehát kell egy rakás compute shader, hogy működjön. De egy konzolnál ez egészen más kategória. Ott tényleg nem egy nagy probléma rátenyerelni a reset gombra, és megcsinálni olyanra, hogy jó legyen. A kompatibilitással nem kell törődni, mint a PC-n. A sugárkövetéses effekteket úgy se portolja majd vissza senki PS4-re vagy XO-ra. A PC-re meg valahogy ráheggesztik őket compute shaderrel.

  • Abu85

    HÁZIGAZDA

    válasz b. #15 üzenetére

    Mert még nincs kész. De teljesen reális így megcsinálni. Csak abba gondolj bele, hogy a PlayStation 4-en ez a játék [link] nem használ raszterizálást. Tehát már az aktuális konzolokon is működik a sugárkövetés. A titka lényegében az, hogy ne dolgozzál háromszögekkel, mert azokon nagyon-nagyon-nagyon drága sugárkövetés, mivel agyonterheli a memóriabuszt.

    Akit pedig linkeltél update-elt is, hogy túltolta. Egyébként semmi sem full ray-tracing még. Hibrid sugárkövetés van. Ez mindenhol részleges, de a CryEngine megoldása pont annyit tud minőségben, mint mondjuk a Frostbite megoldása. Mint írtam az elsődleges előnye sebességben az, hogy a CryEngine voxelekben tárolja a geometriát, míg a Frostbite nem, tehát a memóriabusz terhelésében sokszoros különbség van előbbi javára. Ez mindig a brute-force és az okos megoldás közötti küzdelem. Természetes, hogy a burte force egyszerűbben implementálható, nem kell hozzá voxelizálás a motorba, egy rakás olyan dolog, amelyet nehéz működtetni, de a sebesség mindig az okos megoldással jön. Eleinte minden brute force-on kezd, aztán lassan alakul úgy a rendszer, hogy optimálisabb legyen. Jelenleg itt tartunk. Jött egy nulladik generációs próba, és abból tanulva meg lehet csinálni a konzolokat. Ez tök jó volt az iparág számára.

    Mi az a subgroup? Mi köze van a sugárkövetéshez?

  • GodGamer5

    addikt

    válasz b. #10 üzenetére

    Mert a régi nem lesz kompatibilis az újjal és ezért új hardverekre lesz szükség. Ezért sem szeretnék rtx-es kártyát venni jelenleg.
    De ha nem is váltanák le akkor is rettentő mód korlátozva lesz.

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