Raytrace vs. Poligon
2004-03-23T14:08:08+01:00
2004-04-16T11:37:52+02:00
2022-07-27T12:57:50+02:00
  • Valoban, ez mar szubjektiv, hogy milyen minosegromlast engedunk meg. Szerintem ha a szita eleg jo, az arnyekcsucsoknal sem jellemzoen jon elo a minosegromlas.
    Inkabb nagyon vekony egy pixel szeles belogo kis karok, vagy egy pixel meretu arnyekok 'bujnak el', amelyek nagyon ritkak, persze ketsegtelenul minosegromlas... Ha az embernek sok ideje van, erdemes opcionalisan belerakni ilyen trukkoket a ray tracerbe, amit ha nem valik be, ki lehet kapcsolni.

    Amugy meg a ray-tracing gyakorlati alkalmazhatosagarol: Szerintem meg a high-end rendszerekben lehetne nagy jelentosege a ray-tracingnek. Mondjuk olyan alkalmazasoknal, ahol egy kicsit tobb penz van egy rendszerre (katonai repuloszimulator?).
    Pl, ha csak egy olyan rendszert irnank, ami mondjuk 8 PC-t hasznal a szamolasra helyi halozaton keresztul, akkor mar lenyomhatnank a mostani grafikus kartyakat. Van valakinek tapasztalata arrol, hogy hasznalnak - e a gyakorlatban ilyesmiket valahol?
    Mutasd a teljes hozzászólást!
  • Erdemes ezzel kiserletezni, de azert vigyazni kell arra, hogy ha tul nagy a kezdeti 'racsod', akkor egyes arnyekokat 'nem vesz eszre'. Pl. vegyunk egy labdat, aminek az arnyeka latszik a focipalyan. Ha a labda nagyon magasra repul, es az arnyeka az 1 pixel nagysagrendbe esik, akkor elofordulhat, hogy elbujik elolunk meg a 2*2-es racsnal, is, bar ilyenkor ez nem erdekes: legfeljebb nem latjuk azt az 1 pixeles arnyekot. Azonban, ha a racsot tul nagyra veszed, mar nagyobb arnyekok is 'elbujhatnak'.
    Mutasd a teljes hozzászólást!
  • ez a modszer nem tökéletes mert rontja a képminöséget, a raytracingnél inkább tulmintavételezni kell
    pl egy rácsos kapu árnyéka el is veszhet ha ugy jön ki:)
    az árnyékcsucsok is torzulnak stb
    ilyen alapon jo lenne az is hogy minden második pixelt számolod ki a többit meg a szomszédokbol átlagolod
    a koherenciát fel lehet használni de lehetöleg a képminöség romlása nélkül , inkább a hierarchiában valo keresésben kéne kihasználni
    amugy ez a modszer csak akkor müködik jol ha ha olyan sugarakat inditasz amik 2x2 pixel vastagok és figyelsz arra hogy teljesen takart e az egész sugar , ha nem utána 1x1-es sugarral finomitod

    persze mindenkinek más a célja , ezért elöfordul hogy mig nekem 1-2 gyorsitási technika nem felel meg addig másoknak tökéletes
    Mutasd a teljes hozzászólást!
  • mi lenne, ha nagyon ritkan kovetned eloszor, es utana ott felezgeted, ahol valtozik?
    pl 32-esevel mesz, es ha kulonbozik a ket vegen, akkor addig felezgeted, amig jo nem lesz? az oversampling is benne van ebben..
    Mutasd a teljes hozzászólást!
  • az a baj hogy egyszerü scenékben gondolkodsz , ha 10 fényforrás van akkor a modszered semmit nem ér inkább lassit a sok feltétel vizsgálat

    Nem ertem, miert? Megegyszer:
    Minden negyedik pontot traceled rendesen, minden fenyforrasra beallitasz egy bitet, hogy eleri-e a pontot, vagy nem.
    A kozbulso pontokra meg lehet sporolni egy csomo fenyforras sugarkovetest a modszeremmel. Ezt fuggetlenul kell csinalni fenyforrasonkent. Minel tobb fenyforras van, annal nagyobb ennek a gyorsitasna ka jelentosege. Vegyuk eszre, hogy a modszer csak akkor nem efficiens (akkor zavarhat be a tul sok feltetelvizsgalat), ha a vetett arnyekok atlagosan csak 1-2 pixel nagysaguak. Ez nagyon ritka eset, meg bonyolult scene eseten is. Ez a gyorsitas tutira mukodik, mert leimplementaltam. Egyebkent raadasul aszittem' feltalatam valami ujat, de egy ray-tracing levlistan kiderult, hogy mas is gondolt ilyesmikre. Persze meg itt is van kutatnivalo: meg lehetne vizsgalni, hogy milyen pixelelrendezeseket erdemes rendesen szamolni, melyeket interpolalni, (mi legyen az arany es az elrendezes) es bejon az oversampling igenye is, ha igazi antialiasingot akarunk. Szoval itt is van meg min gondolkodni.
    Mutasd a teljes hozzászólást!
  • az a baj hogy egyszerü scenékben gondolkodsz , ha 10 fényforrás van akkor a modszered semmit nem ér inkább lassit a sok feltétel vizsgálat

    ugy rémlik te emlegetted a globális illumináciot , azt is meg lehet csinálni photon mappal, csak ott mégtöbb sugarat kell inditani , arrol nem is beszélve hogy statikus scenékre müködik csak gyorsan, viszont hardveresen gyorsithato lenne egy gyors paralell procival

    az elözö hozzászolásomhoz még annyit hogy a RT algoritmus hatékonysága növelhetö a mai technikával szemben a parameteres felületek használatával
    mert mig a mai technikával egy bezier , bspline felületet rengeteg kis felületre kell bontani addig a RT-nél egyböl meglehet kapni a metszéspontot
    természetesen a lassu rekurziv közelitést hanyagoljuk hanem inkább a felület egyenletével kell számolni csak a hiba az hogy általában ezek nem egyszerüek
    ha találnánk olyan felületipust aminek a metszéspontja könnyen számolhato, vagy egy jo algoritmust akkor nagyságrendekkel gyorsabbak tudnánk lenni
    én a bezierben gondolkodom mert a bezier felület támpontjai befoglalják felületet tehát használhato befoglalo dobozként amivel gyorsan ki lehet szürni ha nem metszi a sugar
    ha metszi a befoglalo akkor muszáj a felület egyenletével számolni de itt is be lehet vetni azt a trükköt hogy a sugarat ráforgatjuk a Z tengelyre igy az egyenletrtendszer egyszerüsithetö

    talán ezekkel a modszerekkel lehet a legjobb hatásfokot elérni de még sok problémát kell megoldani mig ebböl realtime játék lesz
    Mutasd a teljes hozzászólást!
  • nem hiszem hogy bármilyen trükk gyorsitana a RT-n ami a ray számát csökkenti, mivel nem az a sok hanem a visszavert meg a fényforráshoz huzott és ott a trükközésnek nincs helye sajna

    Teny, hogy a szembol inditott sugarakat a legkonnyebb szamolni.
    Azonban nem egeszen igaz amit irtal, az altalam emlitett 'interpolacios' trukk a fenyforrashoz huzott sugarak szamat is csokkenti!
    Minden 4.-ik pixel kovetek rendesen, ha egy pixel minden atlos szomszedja arnyekban van, akkor azt mondom o is arnyekban van, ha egyik atlos szomszedja sincs arnyekban, akkor o sincs arnyekban. Ez meglepoen keveset teved, es meg amit teved az is alig eszreveheto. Rengeteget gyorsit!!!

    Ennek a gyorsitasnak is jellemzoje, hogy extrem bonyolult scene eseten mar nem gyorsit
    Mutasd a teljes hozzászólást!
  • a pdf docsi az elég alap de remélem sokaknak segit,
    magyarul nem sok docsi van angolul viszont van vagy 500 pdf,ppt docsim

    nem hiszem hogy bármilyen trükk gyorsitana a RT-n ami a ray számát csökkenti, mivel nem az a sok hanem a visszavert meg a fényforráshoz huzott és ott a trükközésnek nincs helye sajna

    az elsö metszést lazán ki lehet számolni lineáris képt-al is tehát a mai technologiával lerendereljük a scenét és a kapott pixelek lesznek az elsö metszések eddig nincs is gond mert kihasználják a mai csucshardvereket de utána jön a feketeleves, a rengeteg visszavert sugár meg a mégtöbb fényforráshoz huzott

    de ez a gyorsitási modszer is csak 100 millio - 1 milliárd poly/framig müködik mert onnantol a valodi raytrace algoritmus gyorsabb mivel a logaritmikus - lineráris függvény valahol ott metszik egymást

    de mostanában ez a veszély nem fenyeget hogy ennyi polygont dolgozzunk fel realtime
    ugyhogy ez a gyorsitási modszer a legjobb , föleg hogy kihasználják a gpu-t is
    Mutasd a teljes hozzászólást!
  • Egyebkent gyanus nekem is, hogy altalaban az octree a legjobb megoldas, de 10-20%-nal tobbet nem hiszenm, hogy dobott volna a progim sebessegen. valszeg. ha legkozelebb ray-tracert irok en is abbol indulok ki. Mikor nekikezdtem a raytracelesnek, meg nem ismertem, aztan meg mar maradt a gombhierarchia. Amugy ettol fuggetlenul, az interpolacio, amirol irtam nagyon sokat gyorsitott szinte minosegromlas nelkul.
    Mutasd a teljes hozzászólást!
  • ezen az oldalon:
    http://www.fsz.bme.hu/~szirmay/szg.htm
    itt:
    http://www.fsz.bme.hu/~szirmay/grafika/bmeray.pdf
    talalhato egy, ami szukosen gazdalkodik a lebegopontos osztassal.. ez persze nem baj, mert az egy elegge idoigenyes muvelet :)

    mi legalabbis ezt a modszert tanultuk.. elegge egymasra epulnek, ezert irtam be az oldal linkjet.. ha felhsznal vmi ismeretlen fv-t, akkor erdemes visszalapozni..
    Mutasd a teljes hozzászólást!
  • sorry ha magadra vetted

    ha kis scenéröl van szo akkor a grid a legjobb megoldás könnyü rajta végigmenni egyenes interpolácioval

    ha nagy a scene akkor én az octree-t tartom ideális algoritmusnak,adaptiv octtree-val el lehet érni hogy 1 polygon legyen minden kis kockában igy értelme sincs a befoglalo gömbnek, vagy metszi a sugar a polyt vagy nem,
    a metszésre is van sok algoritmus, szerintem a leggyorsabb az amikor a polykat elforgatjuk ugy hogy a sugar a Z tengelyre kerüljön és 2D-ben megvizsgáljuk hogy az origo benne van e a háromszögben körüljárási irányt számitva

    ha valakinek van a tarsolyában jobb algoritmus ne kiméljen
    Mutasd a teljes hozzászólást!
  • Én úgy vettem észre, egy programban (a mi esetünkben egy raytracerben) az idő túlnyomó része nem a számítások elvégzésére megy el, hanem az adatok mozgatására, függvényhívásokra stb.

    Reszben igaz amit irtal.
    A 'fuggvenyhivasok' kitetel nem lehet akadaly. Ha az ember optimalizal, akkor a gyakran hasznalt fuggvenyeket inline-nak erdemes deklaralni, lehet makrozni, meg egyeb csunyasagokat elkovetni: az en kodomban a fuggvenyhivasok mar nem jelentettek jelentos koltseget.
    Masreszt viszont igazad van, a mai architekturakon, nem feltetlenul a proci a szuk keresztmetszet, hanem a memoria elerese. Ezert aztan fontos szempont, hogy ugy szervezd a kodot, hogy minel tobb adatleres a cache-bol jojjon.

    Az szerintem nagyobb scene-k eseten gaz lesz, hogy nincsenek hierarchiaba szervezve a befoglalo kereteid, mert igy a futasi ido linearisan fugg az objetumok szamatol, az meg eleg durva tud lenni.
    Mutasd a teljes hozzászólást!
  • nem tudom mit hogy csináltok , de ha gömb befoglalást figyeltek az már jo nem lehet

    Ez aztan a megalapozott allitas! Nem tudod mit csinalunk, de az jo nem lehet!
    Egyebkent az irasomban emlitettem, hogy a befoglalo gomb hierarchia nem feltetlenul optimalis, tehat akar lehet is jobb az octree, de nagyon jelentos kulonbsegek nincsenek, es erosen fugg a scene jellegetol is a dolog. Szoval, engem meg lehet gyozni sokmindenrol, de nem ebben a stilusban, ahogy tetted...

    befoglalo gomb hierarchia: Sikerult ezt ertelmezni? Hierarchia, tehat az eleresi ido az objektumok szamaval csak logaritmikusan no, raadasul a gomb metszes eldontese egy nagyon alacsony koltsegu szamitas tud lenni, ha jol optimalizalod)

    akkor meg minek akartok gyorsitani nemértem

    Azert, hogy real-time legyen, es nem 'akarok', hanem mar megtettem evekkel ezelott.
    Mutasd a teljes hozzászólást!
  • Én úgy vettem észre, egy programban (a mi esetünkben egy raytracerben) az idő túlnyomó része nem a számítások elvégzésére megy el, hanem az adatok mozgatására, függvényhívásokra stb.

    Tehát az első raytracerem:

    for (int i=0;i<480;i++)
    for (int j=0;j<640;j++) {

    PrimaryRay.MakePrimary(...);
    Trace(PrimaryRay);
    PutPixel(...);
    }

    class RAY {
    public:
    float OriginX,OriginY,OriginZ;
    float DirectionX,DirectionY,DirectionZ;
    float Min,Max;

    void MakePrimary(...);
    };

    A sugarakat egyenként követem, futásidő 650msec.

    Amikor az SSE változatnak nekiláttam, először C++ ben készítettem el a működő változatot - négy sugár (=sugárköteg)egyidejű követését valósítottam meg. Ebben az esetben a RAY osztály így festett:

    class RAY4 {
    public:
    float OriginX[4],OriginY[4],Origin[4];
    float DirectionX[4],...,...;
    float Min[4],Max[4];

    void MakePrimary4(...);
    };

    Most a sugárkövetés így néz ki:

    for (int i=0,i<480/2;i++)
    for (int j=0;j<640/2;j++) {

    PrimaryRay4.MakePrimary4(...);
    Trace4(PrimaryRay);
    PutPixel4(...);
    }

    Ebben az esetben a futásidő (SSE nélkül C++ implementáció esetén) 300 msec-re csökkent.

    Pedig ugyan annyi számítást végeztünk el! Azáltal hogy a ciklusok rövidebbek lettek, kevesebb függvényhívást hajtunk végre, kevesebb adatot mozgatunk, de ugyan annyi lebegőpontos műveletet hajtunk végre.

    Ha 16, 64,.., stb sugarat követnék, folytatódna ez a tendencia?

    A programomban semmiféle befoglalókeret hierarchiát nem használtam, egyszerűen minden objektumnak van egy koordinátatengelyekkel párhuzamos élű befoglalódoboza.
    Mutasd a teljes hozzászólást!
  • nem tudom mit hogy csináltok , de ha gömb befoglalást figyeltek az már jo nem lehet
    akkor meg minek akartok gyorsitani nemértem
    a kulcsszo az OCT-TREE, igy akár 1 millio object vagy polygon közül meg lehet találni a metszést 10-20 vizsgálat alatt
    Mutasd a teljes hozzászólást!
  • Hi!

    A "naiv" raytracer, ... és ha talált, megnézem a benne található geometriát.

    ...
    A sugarak gyakran alig térnek el egymástól ... szomszédos pixelekből indulnak ki.

    ...
    Osszuk fel a képernyőt 8x8 pixeles blokkokra ... Így a 64 tesztelés helyett mindössze egy tesztelés jut a 8x8-as blokkra.

    Ok, így már étrhető.

    Ebben az esetben (imho) előre kiválaszthatóak az objektum(ok) pontjainak a határai. Nem kellenek 2x2, 4x4, 8x8 blokkok.

    A nadamhu 5letét beépithetőnek tartom (imho), a táblázatok előre való legyártása komoly sebességnövekedést tesz/tehet lehetővé.

    Amúgy vektorprocesszorokon valós idejű RT lehetséges!!! Lásd pixelshader.

    Nem tudom melyik évben (199x), volt egy (tömörítve)4K demo (128MB RAM mellett futott védett módba!!!), pont ezt csinálta. Valós időben mászkált gombok, hengerek között, 3 fényforrással (533MHz celeronon futattam). Nagyon tetszet.
    Mutasd a teljes hozzászólást!
  • Hi!

    Normális Ray-Tracer? ... Bár egyszerűnek éppen nem nevezném...

    Igen, ezekkel mind 1et ertek.

    Normalison en az olyan icipici RT forraskodot ertem ami konnyen atlathato (es bovitheto). Pl. csak gombot es 3szoget tud (+CSG).

    Mar talaltam 1et, de ha atirom a define float-ot double-ra akkor nem latok semmit . A program forraskodja viszonylag egyszeru, de ezt a kis "hibat" nem tudom minek betudni.
    Mutasd a teljes hozzászólást!
  • Itt szó sincs subsampling-ról és interpolációról!

    Pedig erdemes lenne. Amit irtal, (SSE nelkul 650ms), az nagyon sok.
    Pontosan milyen befoglalo hierarchiat hasznalsz? En befoglalao gömb-hierarchiat hasznaltam.
    Ez (ahogy kesobb utanaolvastam) valoszinuleg nem a letezo legjobb befoglalo hierarchia, de azert eleg jonak bizonyult.

    Masreszt, nagy sebesseg eleresehez szerintem meg a mai procik eseten is elengedhetetlen az interpolacio.
    Evekkel ezelott irtam ilyet, ugyhogy lehet, hogy nem leszek eleg pontos:
    En annak idejen elso korben minden negyedik pontot kovettem le rendesen, es a kovetes soran keletkezett adatokat (objektum id, textura koordinata, normal vektor, fenysorrasokhoz tartozo boolean-tomb, tukrozott objektum id) cacheltem. Ha egy pontnak pl. mind a negy atlos szomszedjahoz ugyanazok az objektum-id-k es fenyforras eleresi booleanok tartoznak, ott nyugodtan lehet interpolalni egy csomo mindent, ahhoz a ponthoz alig kell szamolni.
    Ezt most ikabb illusztraciokent irtam le 2 ev tavlatabol, ezt erdemes reszletesen vegiggondolni.
    Tovabb bonyolitja a dolgot, hogyha igenyes vagy, es antialiasingot is akarsz, akkor amit nyertel idot, annak egy reszet be kell aldozni, es a diszkontinuitasoknal bizony pixelenkent tobb mintat kell venni. Az antialiasingos kiegeszitest en mar nem implementaltam, ahogyan en mar az SSE verziot sem fejeztem be.

    Egyebkent ti csak tisztan erdekessegkeppen nyomjatok ezt a temat, vagy szerintetek ez levalthatja a mai polygonos megoldasokat?

    Szerintem akkor valthana le, ha sikerulne becsempeszni vahogy a globalis illuminaciot, vagy legalabbis jobban kozeliteni.

    Az a minimum, hogy olyat kellene csinalni, hogy ha statikus fenyforrasokrol es objektumokrol (is) van szo, akkor texturaszeruen elore le kell szamolni minden pixel megvilagitottsagat. (radiosity-t figyelembe veve). Ez tokeletesen diffuz anyagokra mar tokeletes kepet szamolna!
    Ennel meg egy fokkal vadabb otletem, ami pixeleneknt egy olyan L fuggvenyt tarolna, ami a 'szemsugar beesesi szog'-enek megfelelo fenyesseget tarol le elore, ez meg a radiosity-nel is finomabb effeketeket hozna elo (ez masodlagos fenyforrasok figyelembevetele nem diffuz anyagokaon), itt azonban a koherenciakat ki kellene hasznalni, hogy ezt az informaciot egyaltalan kezelheto mereture tomoritsuk. Otleteim vannak, de a magvalosithatosaguk es az ertelmuk is erosen kerdeses.
    Mutasd a teljes hozzászólást!
  • A koherencia kihasználása

    A "naiv" raytracer, amit először írtam egyesével követi a sugarakat. Minden egyes sugarat tesztelek a befoglaló dobozokra, és ha talált, megnézem a benne található geometriát.

    A sugarak gyakran alig térnek el egymástól (koherencia). Ilyenek pl a szemsugarak, amelyek közös origóval rendelkeznek és szomszédos pixelekből indulnak ki.

    Osszuk fel a képernyőt 8x8 pixeles blokkokra. Igen gyakori eset, hogy mind a 64 sugár NEM talál el egy bizonyos objektumot. A "naiv" raytracer mind a 64 sugarat tesztelte ezen objektum befoglaló idomára. Határozzuk meg a 8x8-as sugárköteg befoglaló idomát (kúp), és ezt teszteljük az objektumokéval (gömb).
    Így a 64 tesztelés helyett mindössze egy tesztelés jut a 8x8-as blokkra.

    Ha a két test (a gömb és a kúp) metszi egymást, mind a 64 sugarat teszteljük az objektummal. Itt szó sincs subsampling-ról és interpolációról!

    Az SSE-s verzióm után ezt szeretném megvalósítani a raytraceremben...
    Mutasd a teljes hozzászólást!
  • Normális Ray-Tracer?
    A Pov-Ray normális?
    Szerintem igen.
    A kódja open, és c illetve c++.
    Semmi asm. Legalábbis iszonyúan kevés.
    Bár egyszerűnek éppen nem nevezném...
    Mutasd a teljes hozzászólást!
  • Hi!

    650 ms-ról 175 ms-ra csökkent
    Átlagosan is ennyivel nő?

    Mi lenne ha nem 2x2-es, hanem 4x4-es vagy 8x8-as kötegekben végezném a sugárkövetést?

    Csinálhatod, de akkor interpolálnod kell (sokkal gyorsabb lesz). Ergo: 640x480 helyett 320x240 a kép valós számolása, és a interpolálás határozza meg a mínőséget. Itt az interpolálás nem lineáris!

    Ráadásul bizonyos esetekben ... Ilyenkor a sugárköteg befoglaló idoma egy kúp.

    Ez nem rossz 5let, de nem speciális eset(tek)ről van szó?

    Hol lehet "normális" ray-tracert találni (ANSI-C), semmi "pure asm"? Ami 1szerű és bövíthető.

    XiX
    Mutasd a teljes hozzászólást!
  • A programomat SSE-re optimalizálva egy képkocka számítási ideje 650 ms-ról 175 ms-ra csökkent (egyszerű scene,640x480).

    Mi lenne ha nem 2x2-es, hanem 4x4-es vagy 8x8-as kötegekben végezném a sugárkövetést?

    Ilyenkor nem kellene már a sugárköteg minden egyes sugarát tesztelni egy befoglaló doboz "ellen", hanem a sugárkötegnek a befoglaló idomával operálnánk..

    Ráadásul bizonyos esetekben a sugárköteget alkotó sugarak origója egybeeshet (pl pontszerű fényforrásnál). Ilyenkor a sugárköteg befoglaló idoma egy kúp.
    Mutasd a teljes hozzászólást!
  • a pixelshaderek tökéletesen alkalmasak a sugarkövetés megvalositására, azt viszont még nem tudom hogy elég e egy mai hardver játékhoz valo RT engine futtatásához


    Elmeletileg nem is kell hagyomanyos sugarkovetes a megfelelo minoseg eleresehez. Eleg ha minden felulet dinamikus texturat kap, amely minden kepnel frissul. Ilyenkor annyi kepet kell megrajzolni minden egyes lathato kephez, ahanyszoros tukrozodest szeretnenk kovetni. Arnyekokhoz eleg egyszeres, amit mar az uj shadow extension-ok is tudnak. Finomabb arnyekokhoz (soft shadows) mar tobbszoros iteracio kell. Tukrozodeshez is eleg egyszeres, de tobb egymassal szemben allo tukorhoz mar ugyancsak tobbszoros kell.

    Ha valaki pixel shader-el akar trace-elni, akkor megteheti, bar ket korlatba fog utkozni:
    a) a pixel shader-ek programhossza limitalt
    b) a felhasznalhato konstansok szama is erosen limitalt (ide kerulne a geometria)

    Mindazonaltal, ha valamikor lesznek teljesen szabadon programozhato vector processzorok, akkor mindenki eldontheti, hogy mire hasznalja oket. (polygonos megjelenitesre vagy sugarkovetesre) Akkor persze nem lesz kulon vertex meg pixel shader, hanem csak egy altalanos vektor processzor tomb, lebegopontos es fix egysegekkel, regiszterekkel. (lasd: cray rendszerek)

    Viktor
    Mutasd a teljes hozzászólást!
  • Én is próbálkozom RTRT megvalósításán az SSE utasításkészletre alapozva, amely egyszerre négy lebegőpontos műveletet végez - így egyszerre négy sugarat követek.

    Amit még nem tudtam benne megoldani: a geometria (háromszöglista és befoglaló dobozok) a renderelés alatt végig a cache-ben van..

    Érdemes megnézni a REALSTORM nevű raytracert: www.realstorm.de
    <www.realstorm.de>
    Mutasd a teljes hozzászólást!
  • a raytracing elöbb utobb mindenképp alap lesz mert gyorsabb az algoritmus mint a mai technika ( egy bonyolultsági fok felett)

    a mai hardverek támogatják a raytracinget, éppen ezen ügyködöm egy realtime raytracing engine-t irok
    a pixelshaderek tökéletesen alkalmasak a sugarkövetés megvalositására, azt viszont még nem tudom hogy elég e egy mai hardver játékhoz valo RT engine futtatásához, de remélem hogy igen
    Mutasd a teljes hozzászólást!
  • Mar nem emlekeztem pontosan a linkre, de vegulis megtalaltam az emlitett jatekot:

    jatek

    Csak a screenshotokat neztem, mindenesetre erdekes kezdemenyezes.
    Mutasd a teljes hozzászólást!
  • Én a Raytracing esetén az előnyét ott láttam, hogy nagyon szépen lehetett matematikai egyenletekkel leírt térbeli görbéket készíteni. Olyan görbéket, amik tényleg görbék, és nem poligonokból állnak. Többezer poligont egy gömb egyenlete tudott helyettesíteni... :)

    Valo igaz. Ha nem poligonokrol van szo, akkor a ray-tracing sokkal optimalisabb tud lenni. Egy orosz srac csinalt egy real-time ray-tracen alapulo jatekot. Ha poligonos lett volna, nem lett volna tul latvanyos a mai gyorsitokartyak mellett, ezert a jatekban minden gombokbol allt ossze!

    másik előnye a fénytörés volt, amit a poligon alapokon nagyon-nagyon nehéz elkészíteni

    Valoban.
    Mutasd a teljes hozzászólást!
  • Én a Raytracing esetén az előnyét ott láttam, hogy nagyon szépen lehetett matematikai egyenletekkel leírt térbeli görbéket készíteni. Olyan görbéket, amik tényleg görbék, és nem poligonokból állnak. Többezer poligont egy gömb egyenlete tudott helyettesíteni... :)

    A másik előnye a fénytörés volt, amit a poligon alapokon nagyon-nagyon nehéz elkészíteni... vagyis raytrace esetén tudtam két gömb közös részéből egy lencsét készíteni, amely úgy törte a fényt, mint egy igazi lencse... ilyet mikor fog tudni a poligon alapú 3D? :)
    Mutasd a teljes hozzászólást!
  • En is foglalkoztam Raytracer irasaval, ezen belul is a sebessegre optimalizalassal nehany eve. (real time ray tracing).

    A tapasztalatom az, hogy a jol optimalizalt ray-tracinghez nem kell 'annyira' sok szamitasi teljesitmeny, egy mai proci mar ugy-ahogy meg is birkozik vele real-time-ban. (persze ez a scene bonyolultsagatol fugg.)
    Ha a hardverek ezt tamogatnak akkor akar a poligonfillezett technologiat le is valthatna.

    De: Nincs ertelme. Ugyanis a poligonos megoldasokkal ma mar odaig jutottak, hogy ugyanazt a minoseget el lehet erni, mint a ray tracinggel. A raytracing 'vivmanya' az arnyekvetes es a tukrozodes trukkozheto environment mappinggel.

    Tehat latvanyos javulas csak akkor kovetkezne be, ha meg a ray-tracingen is tovabb lepnenk, es valamilyen globalis illuminacios algoritmusokat hasznalnanak real-time-ban, mint pl. photon mapping. Ha ez elkovetkezik - amihez oriasi szamitasi kapacitas kell -, akkor valszeg. vege lesz a polygonfillezes korszakanak. Hogy ez mikor kovetkezhet be? Nos ez izgalmas kerdes, valaszolni nem tudok ra.
    Mutasd a teljes hozzászólást!
  • Foglalkoztam sokat régen Raytrace programokkal (írással és használattal is), és az a kérdés ötlött fel bennem, hogy vajon hol tartana ma a játékfejlesztés, ha a 3D kártyát nem a poligon alapú 3D-t támogatnák, hanem a Raytrace alá tennének bővebb támogatást? Tehát olyan 3D processzorok lennének, amelyek a sugár követéséhez tartalmaznának hardveresen gyorsított speciális utasításokat?
    Mutasd a teljes hozzászólást!
abcd