Keresés

Hirdetés

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

  • Raymond

    félisten

    válasz ddekany #22 üzenetére

    Nem, az egesz ceget megvette mindenestol.

    Privat velemeny - keretik nem megkovezni...

  • GeoPhoto

    tag

    válasz ddekany #26 üzenetére

    A RT jó, meg minden, de mint olyan aki konyít (picit :) a matek részéhez is, meg csinált POV-Ray-hez anno még script alapú képeket sajnálattal kell közölnöm, hogy a consumer kategóriában biztos nem lesz 2010-ben, Crysis szintű! RT valós időben.

    Sokat lehet spórolni az RT-nél a befoglaló dobozok használatával, de amikor a képen lévő elemszám többszázezres nagyságrendű ott már szívás van...

    Vannak RT szerű megoldások, Radiosity meg társai, amik sokszor csak a tükröződésben vannak lemaradva a látványban, de valószínűleg csak a raster/RT combináció az ami realitás rövid távon az otthoni kategóriában.

  • Dzs3ko

    tag

    válasz ddekany #26 üzenetére

    Lehetőség van akár a mai gépek mellett is ray-tracere csak a sebesség a kérdés.
    Ha elindítod a maxot és lefuttatsz egy teáskannát :) Jeleneleg ez szerintem 10 - 30 sec (beállítástól függően). Majd ha ez már 100 fps lesz akkor menni fog :)) Persze nincs értelme egyből áttérni, csak szépen lassan. És lehet hogy a ray-trace nem is vált le minden eljárást.

  • Raymond

    félisten

    válasz ddekany #56 üzenetére

    "Egyszerűen egy komoly (lassú!!!) raytracing végeredménye valósághűbb mint egy raszterizálásé, és épp azért mert -- leegyszerűsítve -- nincs benne külön csel árnyékra, tükröződésre, szórtfény térbeli változására, stb-re, hanem sokkal inkább csak adódnak ezek a dolgok."

    Na es pontosan ez nem lesz realtime meg nagyon-nagyon sokaig. Az osszes alresz meg van oldva ugy hogy "good enough". Sot az elsodleges sugarak szamolasa meg OK, de mit csinalsz a masodlagos es tobbivel? Mert abban a Larrabee sem fog jeleskedni.

    "Viszont, a raytracing elég tág fogalom, és pl. lehet valami úgy is raytracing, hogy teljesen "művi" marad a kép, mert hisz gyorsan akartunk végezni."

    Ezert hasznal az osszes komolyabb offline renderer valami mast mint raytracinget a vegso cel eleresere. A legnagyobb fejlodes par eve az GI es az IBL volt. Pont azert mert ezektol lesznek az igazan elethu kepek amik ma lathatoak. A klasszikus raytracing mas trukkok nelkul adja azt a mu format ami a par evel ezelotti offline kepekre is olyan tipikus.

    Privat velemeny - keretik nem megkovezni...

  • Ati_X_321

    aktív tag

    válasz ddekany #56 üzenetére

    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 ]

  • dezz

    nagyúr

    válasz ddekany #56 üzenetére

    "Továbbra is kérdezem, hátha vki tudja, hogy a scene komplexitásának növekedésére és az effektek egyre inkább elszabaduló halmozódása esetén nem lehet-e, hogy a raytrace elvű megjelenítés lassabban lassul be mint a raszteres. Mert akkor nagyon hosszú távon lehet itt még váltás.
    Volt valahol egy grafikon erről, de most nem találom. Egy bizonyos komplexitás fölött a ray-tracing jött ki jobban.

    Azt persze nem akarom elhinni (ezt Dezz mondta), hogy az Intel elsősorban raytrace alapon akarja működtetni a következő grafikuskártyáját. (Már feltéve hogy az nem 10 év mulva jön ki...)
    Pedig állítólag ez az Inteltől származó információ. Ott versenyeznek, ahol tudnak. GPU-t nem igazán tudnak csinálni, de sok egyszerű x86 magos cuccot igen. Aztán azt arra használják, amire lehet. :DDD

    (#57) Raymond: "Ez az elso es leglatvanyosabb ezert van tele Pohl demoja is ezzel. A kerdes viszont az hogy egy interaktiv applikacioban (ertsd jatek) mennyi ertelme van es mennyire gyakori a felbukkanasa. Peldaul hol van olyan eset ahol egyszeruen ez kell mert a mostani megvalositasok nem adjak meg a kello realitas latszatat."
    Az ilyesmi szitukat manapság természetesen erősen kerülik a mai játékokban. És persze nem csak króm golyók tükrözhetnek, hanem bármilyen simább felület. Pl. autók karosszériája, amikor egymás mellett elmennek, és nem csak a statikus környezet tökröződik... Vagy képzelj el egy üvegfalakkal telerakott irodaépületet.

    "Ralisztikus es valos arnyekokhoz nem kell raytracing."
    Hát... A mai játékokban nem éppen realisztikusak, nem minden tárgy vet árnyékot mindenre, stb.

    "Soft shadows meg peldaul vegekpp nem lesz a klasszikus ray-tracing algoritmusal ugy elerve hogy az valaha is interaktiv legyen (tudom, soha nem mond hogy soha, de itt evtizedekrol beszelunk)."
    Azért ilyen esetben lehet egy kicsit trükközni, ettől nem feltétlenül lesz számottevően kevésbé élethű.

    "Masik dolog hogy semmi ertelme nem lenne ezt nyomatni amikor van kismillio masik megoldas gyorsabb es szebb vegeredmeny eleresere."
    Csak épp minden csak félig élethű (real-time-nál).

    ("Az említett élethű füst-effekt.")
    "Ennek mi koze a raytracinghez?"
    Az, hogy raszteres alapon is nagyon lassú. Sőt asszem tulajdonképpen ray-tracing-szerű algoritmussal csinálják, a neve most nem jut az eszembe. UPD: közben eszembe jutott: voxel space.

    "Ezt sem tegnap elott oldottak meg raytracing nelkul de legyen. Mondjuk hogy kell."
    Csak szintén lassú.

    ("Változó függvény alapú felületek és terek.")
    "?"
    X. order surfaces. Eleve nagyon sok háromszög lehet, és ha még frémenként újra is kell generálni...
    A 2. egyik esete végülis a füst, de lehet az más is.

    "Metaballs - na ehez vegkepp nem kell semmilyen raytracing."
    Jó, de ez is sok háromszög, és állandóan újra kell generálni.

    (#59): iRT video - nézd végig, ahogy kapcsolják rá egymás után az effekteket... És ez 14 Cellen 20+ fps HD-ban.

    Itt 3 PS3 számolja csak az autót+talapzat, így már jópár fps-sel megy - ez az autó 75x több poligonból áll, mint a játékokban szokás.

    [ Szerkesztve ]

  • Raymond

    félisten

    válasz ddekany #70 üzenetére

    Rengetek nagyagyut (ismert figurakat, regi gfx motorosok hardver es szoftver egyarant) es technologiat (cegestul vagy anelkul) vettek meg az utobbi 2 evben. Ugy nez ki amit terveznek komolyan gondoljak :)

    Privat velemeny - keretik nem megkovezni...

  • Dare2Live

    nagyúr

    válasz ddekany #86 üzenetére

    ezek realtime demok akármilyen hihetetlen is. gyak egy cpu magon.

    de nem ez larabee nélkól megvalosithatatlan.

    don't look up, don't look up, don't look up, don't look up, don't look up, don't look up, don't look up...

  • #06658560

    törölt tag

    válasz ddekany #114 üzenetére

    Azért a modell marha messze van a teljeshez, ha megnézed. Egy komplett repülőgépmodell kicsit több alkatrészt tartalmaz, mint amit ott látsz. És spec ilyen termékeknél az igazi parasztvakítás a midnenféle fotorealisztikus és egyéb megjelenítés ér rendering. Egy mérnök nagy ívben xarik rá hogy néz ki, hogy jelenítik meg, milyen élethű a színe, a funkciót, formát minél pontosabban jelenítse meg a rendszer, más nem fontos.

  • #06658560

    törölt tag

    válasz ddekany #116 üzenetére

    ott egy példám: nyeregfelület, felületi mikro és makroérdeséggel. Folytonos legyen. Erre minden pontban számolsz? Mert ha végiggondolod végtelen sok pontban fogja eltalálni egy fényforrásból érkező sugár. Vagy ha a szem megfelelő területét nézzük akkor végtelen sok olyan sugár van, ami az adott teljes felüeltről visszaverődve eljut a szemig, azaz kénytelen lennél végtelen sok pontban kiszámolni...

  • #06658560

    törölt tag

    válasz ddekany #118 üzenetére

    Ez szép és jó, de egy pixelbe mennyi irányból eshet be a fény? Innentől akkor hol lesz valósághű? Köszönöm, ez nem lesz az.

  • dezz

    nagyúr

    válasz ddekany #123 üzenetére

    A linken ezt írják:
    "Ambient occlusion is most often calculated by casting rays in every direction from the surface. Rays which reach the background or “sky” increase the brightness of the surface, whereas a ray which hits any other object contributes no illumination."

    Nos, ha ezt kicsit továbbvisszük, és megnézzük a elért objekt színét és távolságát is, és az elsőt a második mértékében hozzáátlagoljuk az adott pont színéhez, máris jobb a helyzet...

  • #06658560

    törölt tag

    válasz ddekany #122 üzenetére

    Epp ezt akarnank megmagyarazni Dezznek, hogy emiatt nem szabad meg otthoni felhasznalasra erotletni a RT-t.

    A RT-t sehol nem szoltam le, csak amikor jonnek itt a milyen lethu videok, akkor modnom, hogy koze nincs a valosaghoz, aki latott mar jarmuvet az tudja.

    Az altalam emlitett nyeregnel a problemat a korrekt fuggvenymeghatarozas jelenti, mert egy min ketvaltozos fv-re raultetnek masik kettot, vagy esetleg valami komplett fuggvenysot. Eleggel belehalhat egy szamolo, mire kiszamolja hol van, mikozben a fuggvenysorbol adodoan periodikus lesz, azaz siman lehet ugy felpiteni, hogy egy kis rweszletet ismetelgetem, ami kisse gyorsabbra veszi a format. Es nem roszabbra... A tulzott fuggvenyben gondolkodas eroltetese sok esetben visszaut.

  • #06658560

    törölt tag

    válasz ddekany #146 üzenetére

    Az rendben is van, de mekkora teruletet akarunk bemodellezni? Legyen csak egy szoba, aminek alljunk egyik csuicsa fele kb harmadolotavon, a ter minden iranyaban. nezzunk kisse ferden a velunk atellenes el melle valamennyire. Vegyuk fel az emberi latomezot. Az elethu kephez amig ezt a latomezot nem kepesek a kiinditott sugarakkal lemodellezni, addig nem szabad itt meg a nagy dezznek sem elethusegrol beszelnie.Mert barmily meglepo te az adott pozicioban meg azon fenysugarakbol is fogsz informaciot szerezni, amik tortenetesen a mogotted levo falon tornek meg, es melloled indultak. Csak mire eljutnak a szemedig addig rengetegmas elemen is torni fognak, szorodni, es csokkenni intenzitasban. De megis lesz komoly hatasuk. mivel a szem kettos integralast vegez a kep kialakitasakot-ill lehet az agy- ezert valahogy ezt kell osszehozni.
    Perspektivahoz: merre kell donteni a sugarat? Szelre, kozepre? Rengeteg esemeny van, ami fenyt=informaciot kepes juttatni ugyanabba az erzekelobe( szembeli receptor, CCd egy erzekeloje, monitor egy keppontja ha RT) Es ha valosaghu kepet akarunk, akkor ezt midnet meg kell hatarozni. Ahogy fogalamztad, ebben leolvadna minden gep, mire megcsinalna egy sima szobaban is akar.

  • dezz

    nagyúr

    válasz ddekany #146 üzenetére

    Azért hozzátenném, hogy a valóságban a fény nem részecske alakban terjed, hanem kvantummechanikai hullámok formájában, szóval a tökéletes lemodellezés szinte lehetetlen dolog.

    (#149): Ez rendben is van, én sem mondtam, hogy minden szempontból élethűbb. Viszont:
    - A gagyi environment mapping helyett jó lenne már valami életszerűbb tükrőződéseket látni.
    (Nézd meg pl. ezt a videót! És az az "approximate ray-tracing" még mindig csak egy fake megoldás. Szal ha más is mozogna ott, rögtön nem lenne ilyen jó. És már ettől is a felére esik az fps, pedig a golyó a képernyő kis részét teszi ki.)
    - Az sem baj, ha a fénytörések sem olyan rosszak.
    - Meg ha az árnyékokkal sem spórolnak.

    Ezen kívül, ha eleve így kezdjük leképezni a dolgokat, egy sor egyéb effektust is élethűbben oldhatunk meg.

    (#150) Kopi31415: "Pontosan mennyi lesz az a sok?"
    Asszem többtíz.

    "Plusz a mostanaban mutogatott szamitasokhoz mekkora szamitasi kapacitast fogtak be? Pl Lambo a 3 PS3-mal. 24 mag, a ha jol tudom jelenleg letezo egyik legjobb processzorban."

    3 Cell = ~600 GFLOPS. (De ezek nem egy-az-egyben összevethető adatok, mert pl. a G92 egymagában is 500 körül van, sokmindenben mégis sokkal lassabb, mint akár 1db Cell.)

    "Osszesen mennyi az ara mondjuk ennek?"

    3 PS3 = 1200 dollár.

    "Es mekkora tempot volt kepes elerni?"

    Az autós demókban 5-10 fps-t.

    "Mennyivel lesz ehhez kepest gyorsabb a Larrabee, amikor megjelenik, figyelembe veve, hogy meg nem lesz optimalizalva hozza semmi?"

    Azt nem tudom, de az IBM ray-tracere nem éppen game-orientált, miközben az Intelé igen, és állítólag 10x gyorsabb a szokásosnál.

    "Mennyi fog belole kelleni egy elvezhetoen futtathato jatekhoz?"

    A 90fps-es ray-tracelt Quake4-hez 8 mag kellett. 32 maggal már egy jóval komplexebb scene is elmegy...

    (#151): Így van, de sem mondtam, hogy az alap ray-tracing máris 100%-osan reális képet ad.

    Viszont:
    "Perspektivahoz: merre kell donteni a sugarat? Szelre, kozepre? Rengeteg esemeny van, ami fenyt=informaciot kepes juttatni ugyanabba az erzekelobe( szembeli receptor, CCd egy erzekeloje, monitor egy keppontja ha RT) Es ha valosaghu kepet akarunk, akkor ezt midnet meg kell hatarozni. Ahogy fogalamztad, ebben leolvadna minden gep, mire megcsinalna egy sima szobaban is akar."

    Talán nézd meg ray-tracing alapjait. ;)

    (#153): "Ehhez ket kerdes: te beleszerelmesedtel a fenytoresbe? Minden RT demo eddig azt feszegette, holott nagyreszuknek ezzel semmi koze nem lett a valosaghoz. Es folyamatosan a fenytorest, mitn szamolast hozod elo.Neked csak a fenytores jelenti az eletszeruseget? Csak kromkalitkak es falak kozott tudod elkepzelni a vilagot?"

    Ezt miből vontad le? Mert ezek sokkal jobbak a ray-tracingben? Attól még van ott más is.

    "masik: hova konvergal a RT szamolas? Csak nem ugyanoda, mind a masik variacio? Mert ha igen, akkor miert is tepjuk a szankat? Meg ha lenyegesen bonyolultabb modelleknel is fog ez bekovetkezni."

    Azért nem egészen mindegy...

    "Azert a RT-s fps-ek sem valami hudefenyes teljesitmenyrol arulkodnak. Es azokat nem C2D-n futtatjak. Te emlegeted folyamatosan, hogy hozzadobunk meg egy adag Cellt. Akkor miert lesz ebbol barmi othhon elvezheto? Magyarazd mar meg, ha jelenleg tizensok Cell kell valami kiszamolasahoz, max 20 fps-herz, es azt hozod elo, ha bonyolodik, akkor meg egy adag Cell, mikor fogja ezt egyetlen Larrabee kiszamolni?"

    Lásd kicsit feljebb.

    [ Szerkesztve ]

  • Ati_X_321

    aktív tag

    válasz ddekany #166 üzenetére

    pontosan, ez nekem is eszembe jutott, csak a szemléltetés kedvéért írtam, hogy mennyire jól párhuzamosítható :)

    jó lenne vmi NURBS felület alapú megoldás, akkor elférne a memóriában, de azzal is csak a gond van (metszéspontszámítás problémás)

    [ Szerkesztve ]

  • #06658560

    törölt tag

    válasz ddekany #163 üzenetére

    olvasd el mire írtam, és miért. dezz jött azzal, hogy a raszteres megjelenítés a nullához tart. A kétszeres sebesség is. Ezért kérdeztem, hogy a RT akkor vajh hova?
    Egyébként amit ezzel kapcsolatosan pont emlegetett, hogy a kétszer lyan erős proci sem számít semmit... Hát, csak éppen minden poligonszámnál kb kétszeresére nő a teljesítmény, ha rendesen sikerül megduplázni a számításokat végző egység erejét. És mivel azon csodadiagramm függőleges tengelyelineáris volt, így a mentén a változások azért nem voltak oylan kicsik egy duplázásnál...

    Egyébként pont műszaki ember vagyok, különösen megspékelve matematikai érdeklődésel.
    A problémám a megközelítéssel volt, hogy azért, mert midnen egyfele konvergál, ha az egyiknél közben fejlődött a technika, akkor annyival elintézzük, hogy a duplája nem a nullához tart szintén?

    // Lehet ha azt is megnézed mire válaszolok az könnyíti megérteni azt, amit írok miért írom.//

    jelen esetben kérdéses az i, hogy egy raszteres megjelenítést, vagy egy RT megjelenítéest számoló hardvernél a számoló egységek milyen tempóban tudnak gyorsulni. Mert Ha valamelyik gyorsabban tud a technológiai lépések során, akkor nicns értelme a skálázódáson vitázni, amelyik ebben jobb, az le fogja hagyni a másikat mindenféle elemszámnál, még ha netalántán meredekebb is a görbéje. Jó dolog egy logaritmikus görbe, ahogy egy exponenciális is. :)

    Az utolsó mondatoddal teljes mértékben egyetértek a kételyben. :)

  • #06658560

    törölt tag

    válasz ddekany #162 üzenetére

    "szélére kell dönteni. Olyanok a sugarak, mint egy összegömbölyödött sündisznó tüskéi, ahol a sündisznó a képernyő közepén fekszik. És mivel a sugarak iránya adja ki a perspektívát, azok iránya fix, teljesen mindegy, hogy mi van a 3D-s modellen."

    Ez szép és jó, perspektíva létrehozásához. DE. A teljesen máhonnan betükröző napfénnyel mi van? AMi esetleg bevakít?
    RT tud kezelni hullámtermészetű jelenségeket? Rács és réseffektust?

    Konkretizálva. Egyetlen pixelhez 1, tíz, tizenöt, száz, ötszáz, ezer, vagy mennyi sugár információja fog tartozni?

    Szerintem a nézőpontunk nem áll messze egymástól, csak másfele nézünk. Te próbálsz meggyőzni a RT nagyszerűségéről, amit nem vitatok, sőt, közben a hátrányait, kételyeit is szépen sorbaveszed, azonban amiért én beleszóltam itt eme komoly vitába az az volt, mert dezz nagyon egysíkúan csak a RT-t tarotta valósághűnek, miközben az általa linkelt dolgok, amiket meg tudtam eddig nézni nem igazán voltak azok.
    Má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.

  • #06658560

    törölt tag

    válasz ddekany #186 üzenetére

    Ahogy korabban is irtam, kicsit masfele nezve beszelgetunk, de nem allunk egymastol tavol. :)

    A bevakitasos dolog meg, attol lesz eletszeru valami, ha ezeket is tudja. Melysegelesseg,bevakitas mindketto kell a tenyleges elethuseghez, hiaba hibaja ez az emberi szemnek. Illetve nem is annyira hibaja, mint inkabb a felepitasabol kovetkezo egyszeru fizikai torvenyek miatti teny.

    Egyebkent pont arrol beszelek en is, hogy a RT-hoz igen sok fenysugarat kell szamolni minden ponthoz, hogy az elethuve valjon. Addig felesleges itt hozni ezeket a remek "elethu" demokat.

  • Raymond

    félisten

    válasz ddekany #190 üzenetére

    Ettol fugg milyen megoldast hasznal a scene strukturara elmeleitel a statikus reszeknel nem lett volna gond a tobb poligon de valami nymomos oka lehet hogy sem bump sem normal mapping nincs legalabb azokon. Mivel igy az eredeti valtozat minseget sem eri el a demo. A problemaja szerintem az lehetett hogy egyszeruen nincs eleg rendelekezre allo ido a shading-re mert a raytracing annyit lefoglal. Az engine reszleteinek ismerete nelkul max talalgatni lehet.

    Privat velemeny - keretik nem megkovezni...

  • #06658560

    törölt tag

    válasz ddekany #191 üzenetére

    Hat, az optika teruleten eleg reg melyedtem el, de szerintem a melysegelesseg letrejotte egyszeru fizikai kovetkezmeny. Van egy lencsed, van egy vasznad, amire a ke3pet vetited:(sargafolt) A ketto egymastol mert tavolsagat is ismered. A kostellaciobol ket dolgot tudsz valtoztani: a lencse formajat, es tavolsagat. Ezen felallasban egy adott lencsetavolsaghoz es lencseformahoz csak egy tartomany tartozik, amibol a kep eles lehet sajna. A tobbibol mar annyira meredek szogekben erkezik a feny, hogy ott torzul a toreskor az irany az elmelethez, vagyis nem eleg nagy a lencse. Vegtelen kiterjedesu lencsevel vegtelen messzesegig lehetne rendesen fokuszalni a kepet. De azzal meg kozelre nem lehetne semmit elerni. A melysegelesseg egyebkent szerintem kifejezetten hasznos a tavolsag felmeresehez pl.,valamint rengeteg folosleges- adott tevekenyseghez nem szukseges informacio kiszuresehez.

    Azaz egy autoszimulatornal szerintem meg lehetne csinalni, hogy bevisznek melysegelesseget a kepbe: alapesetben a palya egy adott szakaszara fokuszal az ember, pl kanyar. Na nanak a tavolsagat kell beloni elesre, a tobbit el lehet mosni, mondjuk egy-ket pixelnyit. meg is lenne a hatas.

  • fLeSs

    nagyúr

    válasz ddekany #202 üzenetére

    Egy részét kicsit rosszul látod.

    "Amíg az egyszálas teljesítmény a döntő, mert alapvetően egyszálasak (vagy néhány szálasak) a programok, addig nincs más lehetőség, mint OoO-val gyorsítani."

    Ha OoO helyett in-order chipet tervezel annak megvan az az előnye, hogy az egyszerűbb felépítés miatt sokkal magasabb órajelet érhetsz el. A Power6 in order, asszem 5 GHz-es, és a világ leggyorsabb (GP) processzora jelenleg.

    Szóval összességében az in order felépítés kedvez a chip egyszerűbb felépítésének, ebből következően több magot köthetsz össze, tehát a TLP-nek is, amiről te beszélsz.

    [ Szerkesztve ]

    "I press keys on a keyboard all day and click a mouse in front of a glowing rectangle. Somehow that turns into food and shelter."

  • fLeSs

    nagyúr

    válasz ddekany #205 üzenetére

    Asszem 4,7 GHz-es a legalacsonyabb órajelű változat.
    És a leggyorsabbat a különböző ipari szabvány tesztekre értem, speccpu, specjbb, tpc-c, oracle, sap meg mittomén mik vannak még. :) De elsősorban a spec a lényeg.

    Egy x86-os procival is meg lehetne ezt játszani, csak ahhoz kompletten át kéne tervezni, bármelyikről is legyen szó. A mondandóm lényege annyi lett volna, hogy az in order nem feltétlenül jelenti azt, hogy lassú/gagyi. :D Pár év múlva lehet, hogy az Itaniumot hoznám fel példának, mert az is in order.

    "I press keys on a keyboard all day and click a mouse in front of a glowing rectangle. Somehow that turns into food and shelter."

  • vati

    senior tag

    válasz ddekany #237 üzenetére

    A fényforrások véges (>0) méretének és az indirekt megvilágításnak a problémáját a gyakorlati raytracing implementációk esetében le lehetne kezelni, nem túl rossz közelítésekkel. Persze nem olcsón... egy fényforrás helyett lesz pl. 100.
    A véges méretre pl.azt, hogy vegyük a fényforrás kerületének N(~8-16) pontját, és nézzük meg, ebből hány van takarásban, ebből elég jó függvény jöhet ki a részleges árnyék mélységére. A szórt megvilágításra pl. lehet diszkretizálni térszögekre a környezetet, és ezeket egyenként kiterjedt fényforrásként kezelni, miután ismert az átlagos színük és fényességük. Plusz ereje lehet a módszernek, hogy lehet iterálni: első lépésben nem vesszük figyelembe a szórt megvilágítást (másodlagos fényforrások) a második, többedik iterációban már az előzőben megkapott környezet megvilágítottság is belejátszik mint plusz fényforrás. (persze a légköri szóródást direkben bele kell kódolni) Másik iterációs lehetőség, finomítani a környezet mint fényforrás felbontását.
    A vége maga a teljes valóságleképzés, illetve amennyire akarjuk ezt közelíteni. De legalább lehetséges, az alapelv elég általános, elég fizikaközeli annyira, hogy megengedje a skálázást.
    Végső soron különbséget sem kell tenni a fényforrás és a fényvisszaverő testek között. közö

    Ezeket raszternál nem tudom, hogy lehetne kezelni. A raszternél tudomásom szerint minden ilyen finomság csak spéci effektezéssel megy, (ha megy) változó és limitált eredményességgel.

    Asus TUF Gaming A17 / Ryzen7 6800H / 16GB / 512+1024 GB SSD / GeForce RTX 3050Ti "Vízen járni is könnyű, ha az ember tudja, hol vannak a cölöpök..."

  • d3tto

    csendes tag

    válasz ddekany #237 üzenetére

    Több milliós scenekre működik, igaz még mindig nem elég sebesen.

    De meglepetés mindig lesz.

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