- A Colorful "fagyosan kompakt" alkatrészekkel megy elébe a nyárnak
- A Keychron ismét egy űr betöltését vállalta magára az egerek szegmensében
- Az átlagnál vaskosabb ventilátorok kandikáltak ki a Corsair vitorlája mögül
- Csatába küldte Magyarországon idei csúcs hangprojektoros szettjét a Samsung
- Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Az átlagnál vaskosabb ventilátorok kandikáltak ki a Corsair vitorlája mögül
- Hobby elektronika
- Házimozi, és Hifi kábelezés!
- NVIDIA GeForce RTX 3080 / 3090 / Ti (GA102)
- Milyen billentyűzetet vegyek?
- ThinkPad (NEM IdeaPad)
- Melyik tápegységet vegyem?
- Milyen processzort vegyek?
- Raspberry Pi
Hirdetés
-
Kapnak egy rakás reklámot a Roblox játékosai
it Videohirdetésekre készülhetnek ezentúl a virtuális világokban a Roblox játékosai.
-
A Keychron ismét egy űr betöltését vállalta magára az egerek szegmensében
ph A cég újdonsága azokat célozza, akik egy nagyobb fajta, hüvelykujjtámasszal ellátott, ugyanakkor pehelysúlyú eszközt vásárolnának.
-
Spyra: akkus, nagynyomású, automata vízipuska
lo Type-C port, egy töltéssel 2200 lövés, több, mint 2 kg-os súly, automata víz felszívás... Start the epic! :)
Új hozzászólás Aktív témák
-
-
Ati_X_321
aktív tag
[OFF]egyetértek, de ki akar raszterizálni
, én arra várok, hogy full sugárkövetés alapúak legyenek a játékok
nem ismerem ezt a Larrabee-t, de remélem hamár sugárkövetésről van szó, akkor úgy csinálták meg, hogy vmi BSP engine-t hatékonyan futtat és akkor hamar gyorsulhat a raytrace-ingamúgy meg nem olyan nagyon bonyolult a raszterizáló hardver, hogy nvidia ne tudna felzárkózni (sztem)[/OFF]
[ Szerkesztve ]
-
Ati_X_321
aktív tag
szerintem egy raytracer időkomplexitása, rosszabb esetben, csak BSP fát alkalmazva (ami ugye elég alap már pár évtizede), is logaritmikusan nő az objektumok (vagy objektumokat alkotó háromszögek) számával
(a sugár által metszett test megtaláláshoz log2 n számú összehasonlítás kell), de a BSP fa csak statikus scene-re jó
mod: tehát nem lineárisan nő a számításigény
más: itt van GPU alapú global illumination shaderrel, sztem Szirmay Kalos László munkája
http://www.gametools.org/html/demos___videos.html[ Szerkesztve ]
-
Ati_X_321
aktív tag
se CPU, se Cell, se GPU nem raytracingre lett kitalálva, tehát az ilyen mondatok, hogy jelenleg 8 magnyi CPU-val 200k-s scene megy pl raytrace-szel, raszteres megoldással (egyelőre szebb végeredménnyel) meg 8M-s, és ezért a raytrace szar felesleges
akkor lenne egy fokkal jobb az összehasonlítási alap, ha a raytracinget és a software raszteres rendert hasonlítanák össze
az meg hogy melyik proci hány GFLOP teljesítménnyel rendelkezik, az még nem árul el semmit affelől hogy raytracingre mennyire alkalmas
korábban is írták, hogy a raytracing teljesen párhuzamosítható, konkrétan minden pixel kiszámítása futhatna párhuzamosan a többivel, tehát (egy naív raytracer esetében) 1280x720-as felbontás esetén 921600 szál nyugodtan számolhatna a másiktól függetlenül.
CPU-nál általában annyi szálat érdemes futtatni, ahány magos
GPU nagyon sok szálat tud párhuzamosan futtatni (és kell is), de a szálak nem függetlenek egymástól, ugyanazt csinálják (MAD), csak más adatokon (pehelysúlyú szálak, buták, ha vmi elágazás jönne az egyik szálban, akkor kb szétesik a pipeline, többi szálat is megfogja, stb..). Asszem egy G80-ban 14 körüli a multiprocesszorok száma, amik tudnak szálakat vezérelni (multiprocon belül a szálak ugyanazt csinálják).Raytracing esetében az egyes sugarak más fényutat járnak be, más tárgyakkal ütköznek, emiatt a szálak külön életet élnek, futásuk működés szempontjából is független egymástól, nem csak a feldolgozott adatok szintjén.
A logaritmikus skálázódást konkrétan a BSP-fa teszi lehetővé statikus esetben, de van megoldás dinamikus scene-re is.
nyílván intelék picit jobban értenek hozzá
), de sztem olyan proci kell, ami vhol a CPU és GPU között van, tehát lebegőpontos számításra kihegyezve mint a GPU, de nem pehelysúlyú szálakkal, és inkább több multiprocesszor legyen, kevesebb hozzátartozó szállal (a szomszédos pixelre jutó sugarak jó eséllyel ugyanazt a fényutat járják be, ugyanazokkal a tárgyakkal ütköznek) + vmi hardveres BSP cache[ Szerkesztve ]
-
Ati_X_321
aktív tag
Mert amint valtozik a scene ujra kell generalnod a KDtree-t es ez masodpercekig tart egy scenen.
ugyanez meg van raszteresnél is, mindkettő háromszögekkel dolgozik, szóval nem értem, hogy jön ez idea mostani játékok is kd fát használnak a pálya statikus részének leírásához (source engine, quake4), a dinamikushoz meg nem, ez eddig is így volt, továbbra is így lesz
raytracingnél is lehet ugyanez
mostani játékoknál kezd bejönni a full rombolható környezet, asszem láttam valami UE3-as videot ezzel kapcsolatban
BSP fát nem implementáltam még, kifejthetnéd, hogy miért kell újra felépíteni az egészet, ha módosítás történik, olyan megoldás nem jöhet szóba, hogy kiegyensúlyozatlan lesz a fa a módosítás után? erősen véges számú módosítás esetében talán nem olyan nagy probléma, mostani játékokba se rajzolhatod újra a pályát rakétavetővel.
vagy másik ötletem a módosuló partícióban lévő adatokat érvényteleníteni, és onnan egy pointerrel kimutatni egy dinamikusan jól karbantartható adatszerkezetre, persze ekkor is "kiegyensúlyozatlanná" válik
Most mar vili hogy miert nem mozog semmi azokon a CELL relatime RT demokon?
pedig simán mozoghatna, csak nem az objektumot kell eltranszformálni (nem háromszög esetén amúgy is bajos), hanem a sugarat kell inverz transzformálni[ Szerkesztve ]
-
Ati_X_321
aktív tag
-
Ati_X_321
aktív tag
ok, hogy nem holnap lesz, de én már nagyon várom
textúrázást, szűrést nem vágom, hogy kell raytracerben, csak raszteresnél
de tényleg összejön a sok sugár, én így számolom, hogy miből:
az első metszett objektumtól az összes fényforrás irányába + visszaverődés irányába + törésirányba = ez legalább 3 sugár, amiből az utsó kettő rekurzívan továbbhaladjátékban bőven elég lenne kezdetben 3-as mélységkorlát, ez esetben a sugarak száma
3+3*2+4*3 = 21 ha nem rontottam el -
Ati_X_321
aktív tag
válasz
#06658560
#172
üzenetére
RT tud kezelni hullámtermészetű jelenségeket? Rács és réseffektust?
nem mostanában fogsz látni diffrakciót, meg interferencia jelenségeket az tuti, de ha kisétálsz az utcára, ott sem olyan gyakori, hogy észrevenné az embernem a fény hullámtermészetével operál a sugárkövető
mivel minden átlátszó anyag minden hullámhosszon eltérően töri a fényt (prizma), ezért elvileg minden hullámhosszra külön kellene lekövetni a sugarakat (spektrális képszintézis), ehelyett 3 hullámhosszra (RGB) is épp elég hosszú ideig tart.
Konkretizálva. Egyetlen pixelhez 1, tíz, tizenöt, száz, ötszáz, ezer, vagy mennyi sugár információja fog tartozni?
fent leírtam, függ a rekurzió mélységétől, azt hogy hány visszaverődési, törési mélységet engedünk megMásrészről én inkább a hagyományosabb sugárvizasgálatot tartanám helyesnek, azaz a fényforrásból menni előre. igaz, hogy sokkal nagyobb a számítási kapacitás, de azért mégiscsak az lesz élethű, ha mindenáron azt akarjuk előhozni.
sugárkövetés a szemből kiinduló sugarak követésére szakosodott, a fényforrásból kiinduló sugarak csak elenyésző hányada éri el a szemet, ami nem, annak a számítása felesleges volt, és az pedig mindegy hogy a fényt milyen irányból követjük mindegy
más a helyzet Global Illumination esetén, ahol pont a fényforrások által kibocsátott fényutakból csinálnak fotontérképet/PRT-t, ezáltal "leleplezik" az indirekt fényforrásokat,
ez valóban jóval élethűbb és közelebb van a valósághoz, de ezt realtime esélytelen, nagyságrenddel nagyobb számításigénye van, mint a sugárkövetésnek, azonban statikus scenehez készül ilyen előre számított, globális illuminációs módszereket használó textúra, mai játékok is használják -
Ati_X_321
aktív tag
A szures azert kell mert ha csak egy sugar van keppontonkent akkor gyakrolatilag point sampling "minoseget" kapnal. Ami nem kivanatos. Legalabb egy bilinearnak megfelelo kene ha mar tenyleg igenytelenek vagyunk.
ezt vágom, csak én a korábbi hsz-edben úgy értettem, hogy emiatt akarsz még sugarakat lődözni, valószínű megoldható a bilineáris hatás elérése enélkül is -
Ati_X_321
aktív tag
válasz
#06658560
#181
üzenetére
Interferencia: annyira nem ritka jelenség
nyílván nem ritka jelenség, sőt mindenhol ott van, csak éppen nem veszed észre, mert nem monokromatikus fénnyel szoktál találkozni, hanem fehérrel, ami mindenféle frekvenciájú fény szuperpozíciója, és ebből egy hullámhosszra teljesül az interferencia feltételeA fény hullámtermészetével nem fognak játékok számolni, mert felesleges, ritka jelenség, hogy észrevehető.
ha valahol annak kell látszódnia (árnyék széle), majd valamilyen csalással ott leszhelyette van sok más dolog, ami tényleges képminőség javulást hozna, például anyag felületébe behatoló fény, ami ott ideoda verődik, egy része elnyelődik (BSSRDF), de szintén egy nagyságrendet dob a számításokon.
, én arra várok, hogy full sugárkövetés alapúak legyenek a játékok
), de sztem olyan proci kell, ami vhol a CPU és GPU között van, tehát lebegőpontos számításra kihegyezve mint a GPU, de nem pehelysúlyú szálakkal, és inkább több multiprocesszor legyen, kevesebb hozzátartozó szállal (a szomszédos pixelre jutó sugarak jó eséllyel ugyanazt a fényutat járják be, ugyanazokkal a tárgyakkal ütköznek) + vmi hardveres BSP cache
Új hozzászólás Aktív témák
ph A vállalat a sugárkövetés – ray tracing – mellett megtartaná a hagyományos raszterizálást is.
- Kerékpárosok, bringások ide!
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Az átlagnál vaskosabb ventilátorok kandikáltak ki a Corsair vitorlája mögül
- exHWSW - Értünk mindenhez IS
- gban: Ingyen kellene, de tegnapra
- PlayStation 5
- Nagyrobogósok baráti topikja
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Termékoldal buktatta le a Huawei Watch Fit 3-at
- Nemzetközi piacra érkezik az Amazfit Helio Ring
- További aktív témák...
