Keresés

Hirdetés

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

  • Abu85

    HÁZIGAZDA

    válasz b. #37 üzenetére

    Ez ugyanolyan szintű RT, ami van a DXR-es játékokban. A különbség az, hogy voxelizál, vagyis gyakorlatilag ugyanazt a számítást, nagyságrendekkel nagyobb hatékonysággal végzi, mint a DXR, ami sajnos rendkívül rossz hatékonyságú háromszögekre van kényszerülve. Ha mondjuk lenne a DXR-nek is voxelizációra megoldása, akkor az is ugyanilyen gyors lenne.

    Effektet ugyanúgy rakhatsz ebbe is, mint a többi DXR-es programba. A kulcstényező a bejárás, amit már megcsinál a motor. Hogy annak eredményére építve milyen effekteket raksz még, gyakorlatilag mindegy. Abban igaza van a Cryteknek, hogy maga a visszaverődés az a problémakor, ahol az RT előnyösebb tud lenni a raszterizációnál, míg más területen a különbség szinte észrevehetetlen mondjuk egy voxel cone tracinges AO-hoz és GI-hoz képest (amit a CryEngine tud: SVOTI), miközben az erőforrásigénye az RT-nek sokkal nagyobb.

    A CryEngine annyiban előnyben van, hogy sokan próbálkoztak az SVO-val. Epic, DICE, stb. Az NVIDIA-nak is volt ilyenje VXGI néven, csak nem mozoghatott semmi a jelenetben, mert megpusztult tőle. A Crytek az egyetlen cég, amely ezt a koncepciót úgy megoldotta, hogy működik is, nem csak tervezgették. Emiatt sokszor hasznosabb nekik erre építeni, míg mások ezt nem igazán tehetik meg, mert lyukra futott a kutatás.

    [ Szerkesztve ]

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

  • LionW

    tag

    válasz b. #39 üzenetére

    Ennek egy része azért lehet mert alacsonyabb LoD-on + alacsonyabb felbontáson csinálja a voxel gi-t. Tényleg észrevehetően rosszabb a minőség a valódi raytracinges játékokhoz hasonlítva.
    Amúgy akit érdekel, van egy open source játékmotor amiben elég komoly fejlesztéseket csináltak voxelizált gi-vel kapcsolatban, és elvileg középkategóriás gépeken is fut Vulkan api-n. Jövőre adják ki(bétában már tesztelhető githubról), a fejlesztő közölt egy pár képet + videót a twitterén, elég érdekes szerintem, én nagyon várom.
    https://twitter.com/reduzio

  • dabadab

    titán

    válasz b. #39 üzenetére

    Mit akar jelenteni az "aham"?

    A cikk is pont ugyanazt írja, amit a Crytek is mondott, hogy voxel alapú cuccról van szó, annak minden előnyével meg hátrányával együtt.

    DRM is theft

  • Abu85

    HÁZIGAZDA

    válasz b. #39 üzenetére

    A cikket eleve update-elték, hogy túlpörgették a témát.

    Az meg a másik, hogy ma real time szinten egyedül a Dreams, ami RT. Semmi más. Minden további játék raszterizációt használ és RT-vel csak effekteket számol. Ugyanez a CryEngine megoldása is, csak ők nem a nagyon lassú DXR bejárást használják, hanem csináltak egy sajátot, ami gyorsabb.

    (#40) LionW: A Voxel GI eleve nem ray tracing ebben a programban, hanem raszterizáció. RT-t egyelőre csak a visszatükröződés kapott. Persze lehet rá írni RT GI-t is, csak sokkal lassabb lesz, és nem hoz annyi minőséget.

    [ Szerkesztve ]

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

  • 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.

  • arn

    félisten

    válasz b. #44 üzenetére

    [ Szerkesztve ]

    facebook.com/mylittleretrocomputerworld | youtube.com/mylittleretrocomputerworld | instagram.com/mylittleretrocomputerworld

  • Abu85

    HÁZIGAZDA

    válasz b. #48 üzenetére

    Mi beszélünk róla. Csak nem érted, hogy mi az. Az SVOTI RT az nem SVOTI RT. Az SVOTI a Cryten voxel cone tracing global illumination eljárásának a neve. Ők total illuminationnek hívják, igazából édesmindegy a neve. Az SVOTI-nak ebben nincs igazán szerepe. Ebből csak az SVO az érdekes, mert ez az alap arra, hogy voxelizáld a jelenetet. Aztán ha már ez kész van, akkor ezt felhasználhatod például a global vagy total illuminationre, a név itt mindegy, az effekt ugyanaz. Viszont az SVO felhasználható arra is, hogy erre építsd fel az miss, closest hit és any hit shaderekre épülő sugárkövetést. Ahhoz, hogy ideig elérj, szükséged van egy traversal lépcsőre, ez sok fázisból áll, de a lényege nagyon leegyszerűsítve az, hogy amikor kilövöd a sugarakat, akkor azokat ne kelljen csekkolni az összes háromszögre vagy az összes voxelre, mert az kicsit kurvára időigényes. Emiatt felépítesz egy gyorsítóstruktúrát, amiben a modellek egyes elemeit egy tömbbe rendezed. Ekkor kapsz egy rakás háromdimenziós dobozt, kvázi téglalapot, és a BVH mélységétől függően, szépen le tudod tesztelgetni, hogy melyik dobozt metszi a sugár. Amelyiket nem, ott már a háromszögek vagy voxelek sem lényegesek, mert a dobozon nem megy át, így tuti, hogy azon belül nem talál el semmit. Na ez az a pont, ahol a DXR és a CryEngine másképp dolgozik. A DXR-nél ez a dobozolás a háromszögekre vonatkozik, míg a CryEngine esetében a voxelekre. A DXR ezt nem tudja támogatni, mert maga a grafikai futószalag, amit a DirectX 12 specifikál nem értelmezi azt, hogy mi az a voxel. Tehát bármennyire is sokszorosan hatékonyabb ez a traversal lépcső voxelekkel, DXR alatt nem alkalmazható, az aktuális specifikációkkal, ezért a DXR a nagyon rossz hatékonyságú háromszögekre van kényszerítve. Ezzel azt akarom megértetni veled, hogy bármi, minden, akármi ami megcsinálható DXR-ben, megcsinálható itt is, mert a sugárkövetés effektekre lebontott része a dolgoknak ugyanaz, amint megvan a sugárra vonatkozó intersection eredménye futhat rajta a miss, closest hit vagy any hit shader. Az egytelen különbség, hogy a CryEngine a traversal esetében egy voxeles megoldást használ, mert ez sokkal gyorsabb, bármelyik háromszöges megoldásnál, még a fixfunkciós hardvereknél is. Igen sajnos, ennyire rossz hatékonyságú a háromszöggel a sugárkövetés, de ugye a háromszögek eleve a raszteriáció miatt kellenek, a sugárkövetés támogat más felületeket is. Ezek azok a trükkök, amik miatt előfordulhat, hogy egy-egy offline render engine bár lényegében ugyanazt csinálja, a sebesség tekintetében nagyon-nagyon-nagy lehet a különbség.

    Amiért mérvadó, amit itt bemutattak az az, hogy maga az alap már ki van számolva a traversal során. Az, hogy innen a miss, closest hit és any hit shaderek tekintetében hány effektet írsz, gyakorlatilag mindegy. Működésben tehát különbözik a CryEngine a DXR-es megoldástól, de ha azt nézed, hogy végeredményben az a lényeg, hogy melyik háromszöget lövi át a sugár, akkor pontosan ugyanúgy megmondja a Crytek megoldása, ahogy a DXR is. Csak a Crytek rendszere gyorsabban és hatékonyabban megmondja ezt. És innentől már az egész csak effekt, felhasználód ezt az információt, hogy csinálj visszaverődést, árnyékokat, GI-t, AO-t, akármit. Ez innentől kezdve már az lebegőpontos ALU-kon fut. Amiért a Crytek csak visszaverődést csinált, annak az az oka, hogy ez az az effekt, ahol a sugárkövetésnek valós előnye van. Tehát nem csak abban látod a bekapcsolását, hogy egy számjeggyel kevesebb az fps, hanem a képen is meglátszik, hogy számol valamit a gép. Más effekt esetében nem feltétlenül van előnye a sugárkövetésnek, mert AO-ból alig van különbség egy jelenetszintű, vagy egy olyan multi-view megoldás között, amit a Crytek használ, GI dettó, ott eleve voxel cone tracinggel dolgozik a CryEngine. Tehát lehet, hogy ezeket meg lehetne írni RT-vel is, csak nem látnád az előnyét neki a képen, viszont sebességben kevesebb lenne, amit éreznél. Az árnyékok kérdése necces, mert ott azért lehet előnye az RT-nek, de a CryEngine pont az a motor, amely hihetetlenül jó ebből a szempontból, tehát bőven van esélye, hogy ott se látnál mást, csak az fps csökkenését. A visszaverődés viszont egy olyan dolog, ami nagyon nehezen oldható meg raszterizációval. A rough felületre talán lehetne valami trükk az SVO miatt, de specular szinten látszana, hogy nem az igazi. Az SSR-nek pedig megvannak a korlátjai, míg a reflection probe zabagép. Tehát specular visszaverődésre nem nagyon van más értelmes megoldás, mint az RT. Főleg azzal a sebességgel, ahogy a CryEngine csinálja.

    [ Szerkesztve ]

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

  • dabadab

    titán

    válasz b. #50 üzenetére

    "milyen következtetést tudsz ebből levonni, hogy összevetsz két olyan RT eljárás amiben az egyik 1 féle gyenge minőségű reflections-t használ a másik meg 6 félét amik egymással is kölcsönhatásban vannak és számoltatnak rá ütközést ?"

    Azt, hogy az egyik működik a jelenlegi gépeken is, a másik meg nem (a nagy részükön egyáltalán nem, a maradék kevésen meg túl lassú)?...

    Szerintem mindenki érti, hogy a Crytek-féle voxeles megoldás sok dolgot elcsal, viszont nagyjából működik és ezt elég gyorsan teszi.

    [ Szerkesztve ]

    DRM is theft

  • dabadab

    titán

    válasz b. #52 üzenetére

    "ez így nem Raytracin demo, hanem egy hagyományos Crytek engine demo ami egyetlen RT reflection effektet old meg RT eljárással azt is lebutítva"

    Az RTX is arról szól, hogy a szokásos módszerek mellett egy-két effektet valami korlátozott RT-vel ad hozzá, szó sincs arról, hogy ténylegesen RT-vel generálná a képet.
    A számítógépes 3D grafika mindig is a csalásról meg a trükközésről szólt, ezt nem most találta ki a Crytek.

    Amúgy meg tényleg nem értelek: van egy eljárás, ami csak egyetlen gyártó új, drága hardvereivel működik és ott is elég problémás a teljesítménye, meg van egy másik, ami mindene, lényegesen gyorsabban, de némileg gyengébb minőségben.

    Hol itt a gond?

    DRM is theft

  • egyedülülő

    őstag

    válasz b. #52 üzenetére

    "Soha nem lesz elég erős hardver ahhoz hogy ne lehessen kivégezni, akár végtelen számú sugárral dolgozni." Szuper akkor ez lesz az új mantra amiért a fizika és az a.i nem fog semmit fejlődni. Nagyon örülök.

    "Ha lenéznénk az űrből a földre, nem látnánk az országhatárokat. Csak egyetlen kis bolygót látnánk."

  • Abu85

    HÁZIGAZDA

    válasz b. #50 üzenetére

    Nem az SVOTI a lényeg, az egy GI effekt. Ami itt a lényeg az az SVO, amiből ez az egész működik.

    De ez ugyanolyan szintű RT, mint ami van a DXR-es játékokba. Maga a traversal nem is oldható meg máshogy. Ott arra keresed a választ, hogy a kilőtt sugár, a meghatározott hosszig eltalál-e valamit, mit talál el leghamarabb, és még miket talál el. Erre a három kérdésre ad választ a traversal. Az, hogy ezt DXR-rel csinálod, vagy egy sokkal hatékonyabb implementációval, ahogy a Crytek csinálja, a végeredmény szempontjából mindegy, mert amint megvan a válasz a kérdéseidre, amik mindegyik megoldásnál ugyanazok, máris futtathatod a miss, closest hit és any hit shadereket. Ilyen szempontból tehát nem lehet más működésű sugárkövetést alkalmazni, mert a kérdés mindig ugyanaz, és ugyanolyan válasz kell. Az viszont már meg lehet határozni, hogy a válaszhoz mennyire gyorsan jutsz el. A Crytek nem volt elégedett a DXR sebességével, így írtak maguknak egy olyan megoldást, ami gyorsabban ad választ a fenti kérdésekre. Mindössze ennyi a különbség.

    Teljesen mindegy, hogy hány effektet raksz bele. Mindegyik arra a kérdésre épül, hogy a sugarak hosszig eltalálnak-e valamit, mit találnak el leghamarabb, és még miket találnak el. Ha ezt meg tudja oldani a beépített traversal, akkor ezer RT effektet is be lehet rakni. A kérdés itt már az, hogy megéri-e. Mert sokszor a raszterizáció nem ad rosszabb eredményt, viszont nem felezi a sebességet, utóbbi kulcstényező. Most a Cryteknek nem sok értelme lenne RT GI-t számolni, amikor az SVOTI-jukkal nagyjából megegyező minőséget kínálna. Az egyetlen különbség, amit látnál, hogy RT-vel nem 10, hanem 60%-ot esik a sebességed. Bizonyos fejlesztő számára ennek van értelme, mert nem tudták megoldani, hogy legyen a motorban egy normális voxelizáció, ezt lentebb részletezem, hogy miért.

    Írtam is a fenti hsz-ben, hogy többen probálkoztak voxel cone tracinggel, csak egyedül a Crytek jutott el addig, hogy működjön is. A VXGI addig jutott el, hogy full statikus jeleneten működött, de amint megmozdult valami, összefosta magát. Gondolom láttad az NV-nek a Maxwellhez kiadott holdas demóját. Meg se mozdult benne semmi. Jó okkal, nem működött a technológiájuk, ha az objektumok animálva voltak. A Crytek SVOTI megoldásának az az előnye, hogy működik akárhogy, nem számít, hogy van-e animáció. A többiek is itt buktak amúgy bele, ahol az NV. Ezen csak a Sony tudott felülkerekedni, de csak úgy, hogy egy fix hardverre írták meg, amúgy PC-re nem tudták volna portolni. A problémának köze lehet ahhoz, hogy a voxelizációt mindenki a GPU-n csinálta, és úgy adta vissza munkára a CPU-nak, majd ment vissza az eredmény a GPU-nak. Ez túl nagy round trip volt. A Crytek a voxelizációt magán a CPU-n csinálja, és csak CPU->GPU irányú feldolgozás van, nem pedig GPU->CPU-GPU. A Sony ezen a megosztott memóriával kerekedett felül, így round trip ugyan volt, de adatmásolás nem.

    (#51) dabadab: Nem, a Crytek megoldása nem csalás. Egyszerűen csak nem háromszögeken dolgozik, de ennek jó oka van, a háromszögek eléggé rossz megoldásnak számítanak RT-re. Viszont a Microsoft ezt nem tudja megcsinálni, mert a DirectX futószalag a raszterizáció miatt csak háromszöget kezel. Viszont maga az eredmény szempontjából a Crytek megoldása ugyanúgy megmondja egy sugárról, hogy eltalál-e valamit, mit talál el leghamarabb, és mit talál még el. Ugyanezt csinálja a DXR is, és alapvetően csak erre keresed a választ, hogy utána futtatni tud a shadereket.

    [ 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