minden pixelre ki kell lőnöd egy sugarat, te tóni

Egyetlen ray-sphere teszt lefut 0.00 másodperc alatt.
Okos matek: x*0.00 = 0 ---> Végtelen teszt azonnal.


---

A messzi tárgyakról ugrott be hirtelen. Ahogy elképzelem a kamera lencsét, a sugarak vektora szétfelé áll, mint egy sörét. De mi történik, ha valami pont olyan helyen van, ami két ray közé esik?

Gyors fejszimuláció alapján: Nem lesz a képen, sem sehol a jelenetben nem lesz hatása!!!

ddbwo: ha kicsi és részletes dolgokat akarsz - jellemzően akkor, ha 0 és 1 helyek közé töltöd be az összes geometriát, a float percizitása kevés lehet. floattal szmötyizhet minden. ha cpus realtime ray tracert akarsz, akkor viszont felejtsd el a doublet, és oldd meg a problémát trükkökkel.

Nagyon ritkán van rá csak szükség, főleg akkor, ha a kamera és az objektumok messze vannak az origótól (ez kombinálva a nagy objektumokkal). Akkor pl a sugár egyszerűen átmehet az objektumokon stb. Nekünk volt hasonló problémánk pár rendernél, és ott azzal megoldódott, hogy az intersection teszteket double-ben végeztük. Persze nem mindenhol, csak ahol kellett

Hát ja. Végűlis logikus. Elvégre double.
Mikor és hol van szükség dupla pontosságra? Eddig még nem használtam double-t sehol...

float elég.

double: ha az FPU a szűk keresztmetszet, akár több mint 2x-es sebességkiesést is jelenthet.

Mekkora pontosságot érdemes tartani a számokkal? Szükséges lehet a double vagy elég a float is? Mekkora sebesség kiesést jelenthet a double?

Asylum vagy Pretender:
Olyan kérdésem lenne, több dokumentációban olvastam, hogy a függvényt 2x hívják meg, az egyiket a nearplane-re, a másikt a farplane-re, a kérdésem az, hogy miért teszik ezt, ha egyszer az eyepos-ből ki lehet következtetni a sugár egyik pontját a másikat meg mondjuk a nearplane-ből.
Még egy kérdésem lenne, lookat-el csinálom a kamerámat, kell-e valamire figyelnem a sugárkövetéssel, collusion detection-el kapcsolatban. Köszönöm előre is a válaszokat.
gluUnproject-ről van szó(nekem saját függvény):
http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=279647

ui.: Elviekben sikerült megírnom a sugérkövetéses függvényem, de később tudom csak tesztelni, s BUÉK mindenkinek.

lehet, hogy így nem jó, de:
vagy ha a kamerát a {0,0,0}-nak tekinted (azaz viewSpace), akkor a következőképpen is megkaphatod a far plane-beli viewSpace pozíciót (részlet a shaderemből)

ha pedig worldSpace kell, akkor


De lehet hogy nem.. Deferred shadingnél működik, azzal a különbséggel, hogy nekem nem a farPlane kell, hanem egy adott Depth

De persze az is teljesen jó, amit Asylum írt

Feltételezve, hogy a user az (x, y) eleme [0, w] x [0, h] pontra kattintott ezt elöször át kell raknod a [-1, 1] x [-1, 1] tartományba, majd beszorzod a viewproj mátrix inverzével (ezután is kell perspective division!). Így kapsz egy world space beli pontot, ez lesz az egyenesed egyik pontja, a másik meg az eyepos nyilván.

Sziasztok, lehet nem jó helyre írok. Mindössze csak egy kérdésem lenne. Opengl ES 1.0-ban fejlesztek egy játékot és a kérdésem az lenne, hogy sugárkövetéssel szeretném megoldani az egyes objektumok kiválasztását. A matematikai "alapokat" innen megnéztem http://dea.unideb.hu/dea/bitstream/2437/2376/1/Diplomamunka_Berkes_Balazs.pdf .

A kérdésem csupán annyi, hogy egy egyenest meghatározhat 2 pont. Ezt a két pontot úgy kapom, hogy egyik a kamerám(xyz), a másik, ha jól értelmezem az a pont amit a felhasználó ad meg(xyz), amelyet a vetítési síkon "kattint be".
Kell még-e valamit csinálnom ezzel a megadott ponttal, vagy ez a bevitt pont megegyezik a "vetítési síkon való pixellel"(lehet nem érthető, a fentebb linkelt pdf-ben a 4. ábrán a vetési síkon beszínezett pixelre értem).

Azt tudom, hogy az android a bal felső sarokból számolja az xy értékeket, és az opengl a bal alsóból, tehát ezt majd meg kell cserélnem, esetleg kell még valamire figyelnem, illetve helyes a feltételezésem fentebb?
Köszönöm előre is a segítséget, Kellemes ünnepeket, Boldog Karácsonyt mindenkinek.

Valaki le tudná írni hogy mi a különbség az Torrance-Sparrow és a Cook-Torrance árnyalások között? Én azt vettem ki hogy a C-T a Beckmann eloszlást használja míg a T-S a Gauss féle normál eloszlást. Valamint a G, D és F azaz Fresnel kifejezésekre is szeretnék kérni egy pici leírást ha kérhetném. A G-nél azaz a "Geometrical Attenuation Factor"-nál olyat tudtam kihámozni, hogy azért kell a 3 kifejezés közül a minimumot venni mert az jár a legkevesebb energiaveszteséggel. Ezt jól értelmeztem? Illetve a D a mikrofelületeknek a milyét határozza meg? Ja és a C-T paper-ben olvastam hogy a színkomponenset egy egészen egyedi módon határozza meg. Ezt valaki el tudná magyarázni?

Köszönöm

Hogyan írj raytracert? - Realtime tutoriál

Hogy választod ki a következō sample irányt?

Sztem valami mas lesz a problema, mert nem kene ilyen sotet legyen a gomb.

Furák picit a szinek, gamma korrigálsz rendesen? Persze lehet a legfelülre rakott nagy paca éget ki mindent...

Amúgy nem kimondottan arra a csalásra gondoltam, rakjuk egy baromi erõs fény felülre, amit veszett egyszerū samplezni

Második nekifutás.
Elöl nincs fal, valszeg azért fekete a gömb innensö oldala (mondjuk a többi is fekete, no mindegy). 120 sample, 4 szálon (néhány perc).

Mi is saját szerver parkkal dolgozunk nem is kicsivel, de a mi esetünkben életképtelen(nek látjuk) mert több rendszer több terület, mindenki mindent azonnal akar, és minden létező erőforrást, meg úgy egyébként is a működésük jellege miatt szerencsésebb ha nem egy nagy erőforrásból táplálkoznak, hanem rendesen szétszeparált rendszereken dolgoznak, de persze látjuk azért értelmét, teszem azt fejlesztői oldalon nálunk azért lenne értelme, de ott meg megvannak az erőforrások, új beruházás ki van zárva. Na de hosszú lenne ezt ecsetelnem, lényeg, hogy mi arra amire ránk akarják sózni (csak mert ez a divat) nem látjuk életképesnek, persze nem feltétlen a technológia, hanem sokkal inkább az egyes osztályok üzletágak mentalitása miatt..

(

Idézet

---

DMG :
de szerintem maga a cloud az, ami életképtelen a játékiparban, de még a többi IT szektorban sem látjuk értelmét a kollégákkal.

---

coderun

Jelentem felhőt használjuk már élesben, szóval van értelme, csak saját szerverparkkal nem a nagy tesónál.
)

Ha megnézitek az SSAO eléggé pontatlan -.-

A közeljövő szerintem a hibrid renderelőké: az "elsődleges sugarakat" lehet helyettesíteni inkrementális rendereléssel az átlátszóság, tükröződés és árnyék pedig raycast / raytrace.
A GI pedig fake :3

Idézet

---

Asylum :
De ez nagyrészt SSAO ha jól látom.

---

Meg normális türköződés, stb...

Majd ha lesz animált mesh stb... Ez így eddig statikus geometria

De ez nagyrészt SSAO ha jól látom.

Ez tán realtime:
se

Majd , egyelöre elvan a feladvánnyal

Idézet

---

molgab87 :
Nem lassú az, csak ésszel kell használni

---

Hát ez relatív, de kifejtheted ha már ez egy ilyen topic.

Nem lassú az, csak ésszel kell használni

real time amúgy Cloudban már megy, de szerintem maga a cloud az, ami életképtelen a játékiparban, de még a többi IT szektorban sem látjuk értelmét a kollégákkal.

http://www.youtube.com/watch?v=UGwk28tYJbA

http://www.youtube.com/watch?v=XVZDH15TRro&feature=related

Idézet

---

Pretender :
miért, mi az a sötét paca ott?

---

A padló szeme

@4Bit:

A szabály nagyon egyszerü: minél lassabban kirajzolni a képet
Ha a path tracingre gondolsz, akkor gyakorlatilag egy monte carlo módszer (integrál közelitése kvadratúrával); egy iterációs lépés egy kép (sample), de minden sample-ben random irányba pattognak a fotonok.

Baromi lassan konvergál.

Nem hiszem, hogy ezt a közeljövőben használnád
nálam 1-2 fps-el futott eddig amit próbáltam (bár tény, hogy nincs erős cpum, és cpun ment). Ez még egyelőre nem egy realtime dolog... (de az lesz valószínűleg)

Valósághű fénykezelést lehet vele szimulálni, akárcsak a valóságban, itt is "fénysugarak" pattognak ide-oda, változik a tulajdonságuk, stb.

Mivel közeljövőbeli fejlesztéseim során (lehet) hogy én is használni fogom, meg szeretném kérdezni, hogy ennek mi lenne a szabálya, min alapszik?

Azt látom már hogy mi lenne a lényege, valamilyen fénykezelés áll a dologban, (tükröződés, visszaverődés, stb.) csak azt nem tudom még, hogy ennek hol lehet hasznát venni.
Köszönöm.

Idézet

---

DMG :
Viszont vagy az ablak kicsi, vagy a parapet magasság nagy.

Az a paca engem is érdekelne, mi vet árnyékot ott és hogyan?

---

Jézusom, azthittem egyértelmü... Gyorsan mozgó gömb...

Najó nem szemetelem tovább a topicot , legközelebb akkor ha valami real time cuccom lesz

Viszont vagy az ablak kicsi, vagy a parapet magasság nagy.

Az a paca engem is érdekelne, mi vet árnyékot ott és hogyan?

OBJECTI0N!!

Nem tudom, de feltünöen egyszinüek a képeid, csak nem ez a "csalás"?

miért, mi az a sötét paca ott?

Egy baromi egyszerü dologgal minden máris sokkalta látványosabb lesz

Én a viewproj mátrix inverzével beszorzom, majd perspective division és voilá.



Clippinget viszont kézzel kell elvégezni (near/far plane között van-e stb.)

Idézet

---

Wolfee :
nem, hanem hogy ha a kamerát nem egy fix ponttal adom meg, hanem egy ponttal, egy lookattel, egy up és right iránnyal, akkor hogyan lehet kiszámolni a sugár irányát

---

Ezt írtam le 5 hsz-szel lejjebb :]

nem, hanem hogy ha a kamerát nem egy fix ponttal adom meg, hanem egy ponttal, egy lookattel, egy up és right iránnyal, akkor hogyan lehet kiszámolni a sugár irányát

Úgy néz ki

Idézet

---

Wolfee :
www.fsz.bme.hu/~szirmay/grafika/bmeray.ppt

ebből a 17es diára voltam kíváncsi. mostmár mindenki fogalmazza meg magának a kérdést

---

A kérdés akkor hogyan működik a FirstIntersect függvény? :]

www.fsz.bme.hu/~szirmay/grafika/bmeray.ppt

ebből a 17es diára voltam kíváncsi. mostmár mindenki fogalmazza meg magának a kérdést

Idézet

---

Wolfee :
Akkor én kérdezek:
Eddig egy fix pontban volt a kamerám, viszont ha jól tudom, három vektorral szokás megadni a kamerát, és az alapján számolni. szóval a kérdésem, hogy ha van egy XYZ vertexem, egy CxCyCz kamera pozícióm, egy LxLyLz lookat vektorom és egy UxUyUz "felfele", akkor hogyan tudom eldönteni, hogy az SxSy koordinátában látszik-e az adott vertex?

---

Mi úgy csináljuk, hogy - mivel OGL kompatibilitást is akarunk - hogy az OGL 2 mátrixából kiszámoljuk a látótér / frustum közeli oldalát azaz egy téglalapot és ezt pásztázzuk végig sugarakkal.
Ez a téglalap jelenti ugye a képernyőt vagyis ha 0..1, 0..1 tartományban meg tudod adni a képernyőkoordinátád (ha szükséges egy inverz viewport transzformációt berakhatsz ide) egy bilineáris interpolálással lazán meg tudod adni a világban a kívánt sugarat.
Ha pedig a sugarat ismered akkor a láthatóság már csak a szokásos vizsgálat :3

Nem tudom pontosan mit szeretnél, de ilyen generálnak az adott samplehez egy sugarat és egyszerűen elindítják a jelenetben

Amire te talán gondolsz, nos annak hirtelen nem tudom a hivatalos nevét, de kb annyiról szól, hogy egy gridet építesz a screenre, és megnézed melyik triangle melyik részben van, és építesz ennek megfelelően egy listát, és ezt használod nagyon alap szintű gyorsítóstruktúrának. Ez elég lassú, kényelmetlen és kamerától függően folyton újra kell építeni (egy normális acc struct ezekkel a tulajdonságokkal nem rendelkezik). Ez kombinálhatod half space function-okkal, de az már inkább rasterizáció

(half space meg pl ilyen http://www.devmaster.net/codespotlight/show.php?id=17 )

ui : a screenX és screenY jobb elnevezés, csak én gyakran elkövetem azt a hibát, hogy csak samplekban gondolkozom. (méghozzá 5 dimenziósban )

igen, Sx és Sy mint ScreenX és ScreenY.
Azt hiszem, nem egészen tudom még megfogalmazni a problémámat

sx és sy raytraceben a sample x és sample y koordináták... természetesen 0 és 1 között.

vfc felesleges mivel úgyis csak a frustumon belül tracelgetsz

Sx és Sy mi? Pixel koordináták? Perspektiv vetités (és persp. division) után a [-1, 1] x [1, -1] intervallumban kell lennie.

Ha meg arra gondolsz amikor a vertex a kamera "mögött" van, akkor ugyanezen térben a z koordinátát kell megnézni, hogy a [0, 1] intervallumban van-e (avagy view spaceben a near/far plane között).

Ha az egészet world spaceben akarod akkor pedig view frustum culling.
Ezek jutottak elsöre eszembe.

Akkor én kérdezek:
Eddig egy fix pontban volt a kamerám, viszont ha jól tudom, három vektorral szokás megadni a kamerát, és az alapján számolni. szóval a kérdésem, hogy ha van egy XYZ vertexem, egy CxCyCz kamera pozícióm, egy LxLyLz lookat vektorom és egy UxUyUz "felfele", akkor hogyan tudom eldönteni, hogy az SxSy koordinátában látszik-e az adott vertex?

Raytrace, raycast, minden ami a témához kapcsolódik.