|
|
|
|
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!!!
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
|
|
|
|
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 
raytraceisten és übermedic
|
|
|
|
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...
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
|
|
|
|
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?
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
|
|
|
|
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.
Ezt a hozzászólást Joderida módosította (2012.01.02 18:46 GMT+1 óra, ---)
|
|
|
|
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)
Kód: float3 eyeToScreen = float3(Position.x * tanHalfFOV * aspect, Position.y * tanHalfFOV, 1);
float3 viewSpacePos = normalize(eyeToScreen) * farPlane;
ha pedig worldSpace kell, akkor
Kód: float3 eyeToScreen = float3(Position.x * tanHalfFOV * aspect, Position.y * tanHalfFOV, 1);
EyeRay = mul(eyeToScreen, invView);
Kód: float4 position;
position.xyz = eyePosition + normalize(EyeRay) * farPlane;
position.w = 1.0f;
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
|
|
|
|
-----------------------------------------
Dont Listen to the Naysayers
|
|
|
|
|
|
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..
-----------------------------------------
Dont Listen to the Naysayers
|
|
|
|
(
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
alias aalberik
|
|
|
|
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.
|
|
|
|
|
|
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.
-----------------------------------------
Dont Listen to the Naysayers
|
|
|
|
Nem lassú az, csak ésszel kell használni
|
|
|
|
-----------------------------------------
Dont Listen to the Naysayers
|
|
|
|
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.
[thinking]Nem tudsz elrontani egy játékot, ha nem is fejlesztesz.[/thinking]
4Bit Security Admirális-Generális
|
|
|
|
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?
-----------------------------------------
Dont Listen to the Naysayers
|
|
|
|
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á.
Kód: // i megy 0-tol Height-ig, j 0-tól Width-ig
// -> [-1, 1]x[1,-1] (dx)
tmp.y = (((float)i / (float)Height) - 0.5f) * -2.0f;
tmp.x = (((float)j / (float)Width) - 0.5f) * 2.0f;
tmp.z = 0;
tmp.w = 1;
D3DXVec4Transform(&pos, &tmp, &invvp);
pos /= pos.w;
r.Direction.x = pos.x - r.Origin.x;
r.Direction.y = pos.y - r.Origin.y;
r.Direction.z = pos.z - r.Origin.z;
NORMALIZE(r.Direction, r.Direction);
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 :]
alias aalberik
|
|
|
|
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? :]
alias aalberik
|
|
|
|
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
alias aalberik
|
|
|
|
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 )
Ezt a hozzászólást molgab87 módosította (2011.08.02 08:41 GMT+1 óra, ---)
|
|
|
|
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.
Ezt a hozzászólást Asylum módosította (2011.08.02 01:25 GMT+1 óra, ---)
|
|
|
|
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.
|
|
|
Legújabb project:
Ludo Bluetooth
Legutóbb frissített
project:
steampunk engineer
Friss kép a galériából:
|
Frissebbek 
