játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5440
FZoli:    4892
Kuz:    4455
gaborlabor:    4449
kicsy:    4304
TPG:    3402
monostoria:    3284
DMG:    3172
HomeGnome:    2919
Matzi:    2519

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2185
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1625
syam:    1491
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] [35] [40] > 45 < [50] [55] [60] [65] [70] [75] [80] [82]
Thrall - Törzstag | 609 hsz       Online status #106687   2009.03.15 11:41 GMT+1 óra  
JA!
Na ez logikusan hangzik..
megpróbálom!
Jatekfejlesztes.hu közös projekt: próbálunk összerakni egy olyan csapatot, akik együtt el tudnak készíteni egy komolyabb játékot megfelelő minőségben. Érdekel?
Link:
JF.hu közös projekt
http://frogbonegame.uw.hu/
   
syam - Törzstag | 1491 hsz       Online status #106685   2009.03.15 11:36 GMT+1 óra  
1- amikor a fileból betöltötted a 2 képet, azok két tömbben lesznek
2- kell csinálnod még egy tömböt, amiben az összefésült képed lesz, ennek a mérete a kép pixeleinek száma*4, mivel ez már rgba lesz
3- egy for ciklussal szépen egybepakolod a 2 tömb értékeit ebbe az uj tömbbe
4- átadod openglnek
alias aalberik
   
Thrall - Törzstag | 609 hsz       Online status #106680   2009.03.15 11:30 GMT+1 óra  
Köszi, mindjárt próbát teszek...
De most az "összefésülésre" van valami parancs, vagy hooogy?
Jatekfejlesztes.hu közös projekt: próbálunk összerakni egy olyan csapatot, akik együtt el tudnak készíteni egy komolyabb játékot megfelelő minőségben. Érdekel?
Link:
JF.hu közös projekt
http://frogbonegame.uw.hu/
   
gaborlabor - Moderátor | 4449 hsz       Online status #106678   2009.03.15 11:25 GMT+1 óra  
a data-ban már rgba értékek legyenek, tehát ezt neked kell lekódolni... beolvasod mindkét fájlt, és az értékeket így tárolod el a data-ban. sztem syam ezt értette "összefésülsz" alatt.
és persze a textúra létrehozásánál a megfelelő formátumot add meg (a fenti esetben GL_RGBA)

szerk: elkéstem. de legalább jól gondoltam akkor

   
syam - Törzstag | 1491 hsz       Online status #106677   2009.03.15 11:23 GMT+1 óra  
ugy értem, h amikor a fileból betöltöd a képeket akkor fésülöd őket össze és az openglnek már ugy adod át szóval az opengl nem fog neked semmit összefésülni:]
alias aalberik
   
Thrall - Törzstag | 609 hsz       Online status #106674   2009.03.15 11:01 GMT+1 óra  
tehátakkor:
glBindTexture( GL_TEXTURE_2D,texturak[0]);
glBindTexture( GL_TEXTURE_2D,texturak[3]);
glEnable (GL_BLEND);

és a texturak[0]-betöltésnél
gluBuild2DMipmaps( GL_TEXTURE_2D, 4, width,
height,GL_BGR_EXT, GL_UNSIGNED_BYTE, data );

így???


és a texturak[3]-betöltésnél
gluBuild2DMipmaps( GL_TEXTURE_2D, 4, width,
height,GL_ALPHA, GL_UNSIGNED_BYTE, data );

így???

így nem műx, szóval valamit biztos nem értek...
Jatekfejlesztes.hu közös projekt: próbálunk összerakni egy olyan csapatot, akik együtt el tudnak készíteni egy komolyabb játékot megfelelő minőségben. Érdekel?
Link:
JF.hu közös projekt
http://frogbonegame.uw.hu/
   
syam - Törzstag | 1491 hsz       Online status #106636   2009.03.15 07:03 GMT+1 óra  
a 2 kép betöltésekor az egyik képet rgb csatornában tárolod a másikat az alfában
alias aalberik
   
Thrall - Törzstag | 609 hsz       Online status #106631   2009.03.15 05:31 GMT+1 óra  
Összefésülök???
HOgyan?
Van rá valami parancs, vagy hogy?
Jatekfejlesztes.hu közös projekt: próbálunk összerakni egy olyan csapatot, akik együtt el tudnak készíteni egy komolyabb játékot megfelelő minőségben. Érdekel?
Link:
JF.hu közös projekt
http://frogbonegame.uw.hu/
   
syam - Törzstag | 1491 hsz       Online status #106497   2009.03.13 13:55 GMT+1 óra  
2 texturát egybefésülsz és bekapcsolod a blendezést + beállítod alfa blendre
alias aalberik
   
Thrall - Törzstag | 609 hsz       Online status #106493   2009.03.13 13:43 GMT+1 óra  
Heló, lenne egy kérdésem, tud-e valaki egy egyszerű módszert alpha maphoz.
ehát hogy van egy modell, és szeretnék egy fekete-fehér képet betenni, hogy hol lászódik,hol nem.
A választ előre is köszi!
Jatekfejlesztes.hu közös projekt: próbálunk összerakni egy olyan csapatot, akik együtt el tudnak készíteni egy komolyabb játékot megfelelő minőségben. Érdekel?
Link:
JF.hu közös projekt
http://frogbonegame.uw.hu/
   
gaborlabor - Moderátor | 4449 hsz       Online status #106053   2009.03.08 15:39 GMT+1 óra  
Bukta - Tag | 308 hsz       Online status #106050   2009.03.08 15:22 GMT+1 óra  
Hy
Nem tudja valaki hogy a C#-hoz lehet-e OpenGL-t telepíteni-?-, hogy C#-ban tudjak OpenGL programokat írni. Úgy gondolom mint a .NET | XNA .... komonens | plugin vagy minek mondják
ArgumenException: A megadott DependencyObject nem ehhez a Freezable elemhez tartozó környezet. Paraméter neve: context
:oO Mi a???
   
Eldor - Tag | 162 hsz       Online status #105967   2009.03.07 02:38 GMT+1 óra  
Köszönöm, belenéztem a linkekbe. Első látásra nem könnyű olvasmány, de majd csak megbírkózom vele.

   
dothumour - Tag | 75 hsz       Online status #105964   2009.03.07 02:09 GMT+1 óra  
Eldor - Tag | 162 hsz       Online status #105963   2009.03.07 01:54 GMT+1 óra  
Hello!

Írok egy saját játék enginet C-ben SDL-el és OpenGL-el. Szeretnék belerakni valósághű árnyékolást is, de sajnos lövésem sincs, hogy kell. Tudtok valami használható tutorialt hozzá? A legjobb, ha magyar lenne, de az angollal is elboldogulok.

Tudom, hogy nem ide tartozik, de a hangokkal is bajban vagyok. Ha tudtok valamilyen APIt, amivel Linuxon és Windowson is ki tudok csikarni a hangkártyámból 3Ds hangokat, azt is leírhatnátok ide.

Válaszaitokat előre is köszönöm.

   
Thrall - Törzstag | 609 hsz       Online status #105814   2009.03.04 12:29 GMT+1 óra  
Idézet
Joga :
mi volt a gondja?


Programozási hiba végül is. ma volt délután először hogy elvileg jó lett, csak én meg valamit bennehagytam, ami nem kellett volna, de végül sikerült...
Jatekfejlesztes.hu közös projekt: próbálunk összerakni egy olyan csapatot, akik együtt el tudnak készíteni egy komolyabb játékot megfelelő minőségben. Érdekel?
Link:
JF.hu közös projekt
http://frogbonegame.uw.hu/
   
Asylum - Törzstag | 5440 hsz       Online status #105811   2009.03.04 11:55 GMT+1 óra  
a tutorial még várhat. Én is elkezdtem anno tutorialokat irni aztán annyiminden ujat tanultam meg annyira nem volt idöm foglalkozni vele hogy ugy is maradt.
Mondjuk néhány nemrégiben irt kodomat talán felrakom tutorként.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Joga - Törzstag | 1791 hsz       Online status #105809   2009.03.04 11:47 GMT+1 óra  
mi volt a gondja?
(ಠ ›ಠ) Stewie!

   
Thrall - Törzstag | 609 hsz       Online status #105803   2009.03.04 11:44 GMT+1 óra  
SIKERÜÜÜÜÜÜÜÜÜLLLLLLTTTTTTT!!!!!!!!!!

Jójó, tom, hogy még az eleje, de fasza lett!!!
Joga meg syam , köszi, összehoztam a kettőtök hozzászólásaiból,
9999999999 THX meg köszi!!!!
Fantasztikus, huh, mire ez meglett...
Lehet írunk haverral egy tutoriakt, mert szenvedtünk vele egy kicsit..
Jatekfejlesztes.hu közös projekt: próbálunk összerakni egy olyan csapatot, akik együtt el tudnak készíteni egy komolyabb játékot megfelelő minőségben. Érdekel?
Link:
JF.hu közös projekt
http://frogbonegame.uw.hu/
   
Joga - Törzstag | 1791 hsz       Online status #105800   2009.03.04 11:35 GMT+1 óra  
Hibaüzenet?
Ha csúnyán néz ki, akkor körül tudnád írni?
Kód esetleg?
(ಠ ›ಠ) Stewie!

   
Thrall - Törzstag | 609 hsz       Online status #105799   2009.03.04 11:26 GMT+1 óra  
Idézet
Joga :
3szögekben van megadva a model, szóval, nincs valami gáz?

Szerk.: Ja most nézem, hogy igen, 4szögekben

v : vertexkoordináták lista
vt : textúrakoordináták listája

A face-megadás:
f 1/15 5/206 8/18 4/10

Itt a négy csúcsnál pl az 1/15 azt jelenti, hogy a csúcshoz az első vertex és a 15. textúra-koordináta tartozik


Ez logikusan hangzik. Tehát a második koordináta a textúráé.
Bár még mindig ne műkszik.
Jatekfejlesztes.hu közös projekt: próbálunk összerakni egy olyan csapatot, akik együtt el tudnak készíteni egy komolyabb játékot megfelelő minőségben. Érdekel?
Link:
JF.hu közös projekt
http://frogbonegame.uw.hu/
   
syam - Törzstag | 1491 hsz       Online status #105791   2009.03.04 08:10 GMT+1 óra  
ismét csak azt mondom, h kód nélkül nem lehet mit mondani
alias aalberik
   
Thrall - Törzstag | 609 hsz       Online status #105790   2009.03.04 08:02 GMT+1 óra  
nekünk száz, hogy quad. de ez sem megy így...
Na mind1, mindenkinek köszönöm, remélem majdcsak sikerül.
Háthahátha a google ad végre valamit...
Jatekfejlesztes.hu közös projekt: próbálunk összerakni egy olyan csapatot, akik együtt el tudnak készíteni egy komolyabb játékot megfelelő minőségben. Érdekel?
Link:
JF.hu közös projekt
http://frogbonegame.uw.hu/
   
syam - Törzstag | 1491 hsz       Online status #105789   2009.03.04 07:52 GMT+1 óra  
az a baj, h az .obj polygonokban adja meg a face-ket,
ha a "f" után 3 csoport van akkor 3szög az eredmény, ha 4 akkor quad, ha több akkor tetszőleges konvex poligon
alias aalberik
   
syam - Törzstag | 1491 hsz       Online status #105788   2009.03.04 07:50 GMT+1 óra  
glTexCoord2f (t[t.t1-1].x * sz , t[t.t1-1].y * sz);
glVertex3f (v[t.v1-1].x * sz , v[t.v1-1].y * sz, v[t.v1-1].z * sz);

vhogy igy kellene kinézni, de kód nélkül nehéz megmondani
alias aalberik
   
Thrall - Törzstag | 609 hsz       Online status #105787   2009.03.04 07:49 GMT+1 óra  
Háromszögekkel az a probléma, hogy úgy nem rajzolja ki rendesen, a modell 4szögekkel van megadva, nemtom mi a baj...
Jatekfejlesztes.hu közös projekt: próbálunk összerakni egy olyan csapatot, akik együtt el tudnak készíteni egy komolyabb játékot megfelelő minőségben. Érdekel?
Link:
JF.hu közös projekt
http://frogbonegame.uw.hu/
   
Joga - Törzstag | 1791 hsz       Online status #105786   2009.03.04 07:46 GMT+1 óra  
3szögekben van megadva a model, szóval, nincs valami gáz?

Szerk.: Ja most nézem, hogy igen, 4szögekben

v : vertexkoordináták lista
vt : textúrakoordináták listája

A face-megadás:
f 1/15 5/206 8/18 4/10

Itt a négy csúcsnál pl az 1/15 azt jelenti, hogy a csúcshoz az első vertex és a 15. textúra-koordináta tartozik
(ಠ ›ಠ) Stewie!

   
Thrall - Törzstag | 609 hsz       Online status #105785   2009.03.04 07:45 GMT+1 óra  
Nem, GL_QUADS...
Jatekfejlesztes.hu közös projekt: próbálunk összerakni egy olyan csapatot, akik együtt el tudnak készíteni egy komolyabb játékot megfelelő minőségben. Érdekel?
Link:
JF.hu közös projekt
http://frogbonegame.uw.hu/
   
syam - Törzstag | 1491 hsz       Online status #105784   2009.03.04 07:40 GMT+1 óra  
másold be az egész rajzolásért felelős kódot, mert innen ugy tünik, mintha kevés vertexet renderelnél (t.v1 - a háromszögből mintha csak az első vertexet használnád)
mi a renderelési mód, gl_triangles?
alias aalberik
   
Thrall - Törzstag | 609 hsz       Online status #105783   2009.03.04 07:20 GMT+1 óra  
Huh! Degyorsak a válaszok, tényleg köszi.
Konkretizálnám a problémát.

Van egy uvw-zett modellem, ami a köv. felépítésű

# file generated by UVMapper
# NumVerts/NumTVerts/NumVNormals/NumFacets 246/304/0/244
# NumGroups/NumMaterials/NumRegions 0/1/0
# x/y/color/ppu 512/512/0/50.00000000

v -0.10000000 -0.13891201 0.10000000
v -0.10000000 0.10000000 0.10000000
v 0.10000000 0.10000000 0.10000000...
....
vt 0.72053963 0.36310607
vt 0.72053963 0.47483560
vt 0.34433210 0.83853751
vt 0.26466054 0.83853751
....
g Figure 1
usemtl default
s off
f 1/15 5/206 8/18 4/10
f 1/15 13/1 16/14 5/206
f 1/4 18/3 17/28 2/8
f 1/15 27/9 26/2 13/1
f 2/8 17/28 161/203 159/202
.....


és így rajzolom ki:
for (int i=0; i<triangleCount; i+= 1)
{

glTexCoord2f(!!!!!!!!!!!! NA EZT NEM TUDOM!!!!!!!!!!!!!); glVertex3f(v[t.v1-1].x * sz , v[t.v1-1].y * sz, v[t.v1-1].z * sz);
..........

}

Az objectet ki tudom rajzolni. Azonban a textúra nem megy rá jól.
Amúgy a v vertexek f facek u uv-k
Jatekfejlesztes.hu közös projekt: próbálunk összerakni egy olyan csapatot, akik együtt el tudnak készíteni egy komolyabb játékot megfelelő minőségben. Érdekel?
Link:
JF.hu közös projekt
http://frogbonegame.uw.hu/
   
syam - Törzstag | 1491 hsz       Online status #105779   2009.03.04 06:20 GMT+1 óra  
az .obj-ben semmi összefüggés nincs a vt-k és v-k között
a face-k alapján kell összerendelni a vertexekkel a texcoordokat:

f v/vt/vn v/vt/vn v/vt/vn v/vt/vn

adott esetben a vt el is maradhat
alias aalberik
   
dothumour - Tag | 75 hsz       Online status #105778   2009.03.04 06:19 GMT+1 óra  
Az "f 0/0/0 1/1/1 2/2/2"-szerű sorok adják az összefüggést.
@Asylum: (1-t) előfordulhat. OpenGL-ben az uv az st.
٩(͡๏̯͡๏)۶

   
Asylum - Törzstag | 5440 hsz       Online status #105777   2009.03.04 06:11 GMT+1 óra  
a vertex és a texcoord között nincs tul sok összefüggés, a texcoord és a textura között van, ahol (0, 0) a texture bal felsö sarka, (1, 1) pedig a jobb also. E kettö között pedig lineárisan pakolja.
OBJ-ban viszont talán a v textura koorinátát ki kell vonni 1-böl (legalábbis nálam ugy ment). Ha nem azt akkor az u-t. Probáld ki.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Thrall - Törzstag | 609 hsz       Online status #105776   2009.03.04 06:04 GMT+1 óra  
Heló, újabb kérdésem lenne: .obj formátumban a vertexek és a textúrakoordináták között mi az összefüggés?
Jó ideje szívok azzal, hogy textúrakoordinátákat be akarom tenni, sikerült a fájlból betölteni tömbbe, aztán glTexCoord2f(x,y)-al sikerül minden vertexhez hozzárendelni (i. vertexhez i. textúrakoordinátapárt), de nem akar jól kinézni. Tud esetleg valaki összefüggést a vertex koordináták és a textúrakoordinátákkal.

Amúgy a textúrával/modellel minden rendben, tehát uvmapperrel megcsináltam mind a modellt, mind a textúrát.
Választ előre is köszi!
Jatekfejlesztes.hu közös projekt: próbálunk összerakni egy olyan csapatot, akik együtt el tudnak készíteni egy komolyabb játékot megfelelő minőségben. Érdekel?
Link:
JF.hu közös projekt
http://frogbonegame.uw.hu/
   
syam - Törzstag | 1491 hsz       Online status #105702   2009.03.02 07:09 GMT+1 óra  
szerintem leginkább a "screen space" megoldásokra érdemes koncentrálni, mint pl ssao, deferred shading, de pl. a shadow volume is hasonló témakör
alias aalberik
   
szombatha - Tag | 97 hsz       Online status #105700   2009.03.02 06:59 GMT+1 óra  
nadam: a proféta szóljon belőled!!!!

de, tisztán egy átlagos objektumszámú scene rendereléséhez (árnyékokkal, fényekkel) mindenféle járulékos dolog nélkül (AI, hang, bill figyelés, játék logika, logolás, stb, stb) 300-400 fps-t kell tudni, ahhoz, hogy végül a kész játék során aztán lehessen tartani a 30 fps-t és még tartalék is legyen. 300-400 fps-t raytrace-szel? háááááát!

   
sirpalee - Tag | 1282 hsz       Online status #105699   2009.03.02 06:53 GMT+1 óra  
nadam a profi raytracerek sem raytracer only módban a leggyorsabbak, hanem félig rasterben félig raytraceben. Ez munkatapasztalat. Nagyon sok dolog gyorsabb a rasterral, viszont pár dolog lassabb. Ezért kell a kettőt összevegyíteni.

Szerk : Én is elkezdek kacsingatni a raytracer megoldások felé, főleg a compute shader elég gyorsan le tud tolni ilyeneket . Sajnos néhány effekthez muszáj ilyen technikákat használni, mert rasterral szinte megvalósíthatatlan.

Ezt a hozzászólást sirpalee módosította (2009.03.02 07:00 GMT+1 óra, ---)
raytraceisten és übermedic
   
nadam - Törzstag | 364 hsz       Online status #105697   2009.03.02 06:39 GMT+1 óra  
sipalee:
Szerintem az idő a ray-tracingnek dolgozik.
Úgy sejtem, hogy lesz egy pont, (amit nehéz megmondani mikor jön el,) amikortól kezdve nem lesz értelme nem ray-tracinggel dolgozni.
Mivelhogy a jól optimalizált raytracing futásideje nagyjából pixelszám * log(objektumszám), ezért egy bizonyos idő után már szinte akármilyen komplex scene-t el lehet vele vinni, csak a memória lesz korlátos. (Gondolom a sok cache miss lesz a legnagyobb fejfájás) Ugyanis a log(objektumszám) az nagyon lassan nő. Ez a pont amúgy nincs annyira messze, szerintem. 2000-2001 környékén foglalkoztam real-time ray tracinggel, már akkoriban 320*200-ban (sőt, lehet, hogy 640*400-ban, már nem emlékszem) egyszerű scenek (főleg gömbökből összerakott scenek ) mentek 10-20 frame per sec körül az akkori lassú egymagos procikon. A demo scene is ezzel volt tele akkoriban.

Szerk.:
Az is lehet, hogy a high-end teljesítményű 3D engine-k hibridek lesznek, de mivel a ray-tracing egyszerű, elterjed majd egy csomó nem annyira high-end, de elfogadható teljesítményű tisztán ray tracingen alauló ingyenes 3D engine is.

Ezt a hozzászólást nadam módosította (2009.03.02 06:52 GMT+1 óra, ---)
   
sirpalee - Tag | 1282 hsz       Online status #105696   2009.03.02 06:32 GMT+1 óra  
Idézet
nadam :

Nem idén, de lehet, hogy jövőre. Komoly research kellene ahhoz, hogy ezt megjósoljuk, de én 'hasból' úgy érzem, hogy nagyon közel az idő, amikor ez már megfontolandó alternatíva lesz..


Még nagyon messze van a real time raytracerek ideje. Sőt az övéké sosem fog eljönni, max hibrid rendszereké. Bármilyen szép is a raytracing elve, és egyszerű, nem eléggé hatékony, hogy csak azzal legyen számolva. Viszont egy hibrid raster / raytracer már reálisabb.
raytraceisten és übermedic
   
szombatha - Tag | 97 hsz       Online status #105695   2009.03.02 06:20 GMT+1 óra  
alapból 2048-as sm-mel dolgoztam, de a fényforrás "ügyes" elhelyezésével hamar használhatatlan lesz a lispsm. (pl. alkonyat) Tehát még közelitőleg sem lesz olyan éles árnyék mint a shadow volume-nál, hanem olyan lesz mint a rubik kocka.

Egy olyan sm árnyékkal renderelt képet szeretnék látni, amin van egy magas tárgy a lenyugvó nap fényében , ami hosszú-hosszú, szép árnyékot vet. Na ilyet még nem láttam sm-mel, stencil shadow-val viszont csináltam is

   
syam - Törzstag | 1491 hsz       Online status #105694   2009.03.02 06:02 GMT+1 óra  
a lispsm akkor esik teljesen szét,
-ha a nézeti vektor minél kisebb szöget zár be a fény vektorával, de ezt könnyen lehet kezelni
-ha a fény vektora közel merőleges az árnyékvető felületre - erre a mélységértékek interpolását javasolják, de akkor sajnos elveszik a hardveres shadowmap mintavételezés

én máshol nem láttam hibát benne (bár ezek is bőven elegendők) és 2048 méretű shadowmappel már olyan éles az eredmény, mint shadow volume esetében

a PCF pedig kb. azt jelenti, hogy minél távolabb van az árnyék az árnyékvetőtől annál elmosottabb; nvidia hardverek alapból és ingyen tudnak 2x2 pcf-t (ami önmagában szinte semmit nem ér; kb 9x9 a látványos már)
alias aalberik
   
nadam - Törzstag | 364 hsz       Online status #105693   2009.03.02 06:00 GMT+1 óra  
Idézet
szombatha :


nadam: nem tudom mikor lesznek ott a GPU-k, CPU-k, hogy realtime ray-trace-szel számoljam az árnyékokat, de az a gyanúm, hogy nem idén, nem is jövőre A PCF mit is takar?



Nem idén, de lehet, hogy jövőre. Komoly research kellene ahhoz, hogy ezt megjósoljuk, de én 'hasból' úgy érzem, hogy nagyon közel az idő, amikor ez már megfontolandó alternatíva lesz..

PCF: Percentage Closer Filtering (erre keress rá)
   
szombatha - Tag | 97 hsz       Online status #105692   2009.03.02 05:50 GMT+1 óra  
kösz a gyors válaszokat:

nadam: nem tudom mikor lesznek ott a GPU-k, CPU-k, hogy realtime ray-trace-szel számoljam az árnyékokat, de az a gyanúm, hogy nem idén, nem is jövőre A PCF mit is takar?

syam: lispsm-et megvalósító implementációt teszteltem, de elég durva problémákat láttam én ott. lásd az előző hozzászólásomat

most megpróbálom ötvözni az stencil shadow-t a shadow map-pel. A GPU-val megtámogatott stencil shadow elég gyors tud lenni és egészen nagy területekre vetett nagy árnyékoknál is. pl. magas épület által vetett árnyék is szépen működik, nem kockásodik. Mozgó objektumoknál meg mehet az SM. Az a lényeg, hogy objektumonként meg lehet adni, hogy milyen módon vessen árnyékot. Nagy, nem mozgó objektumnál stencil shadow, kisebb dinamikus objektumnál pedig shadow map.

Remélem még földi életemben bele tudok illeszteni egy elfogadható shadowrenderinget az engine-embe.

   
syam - Törzstag | 1491 hsz       Online status #105690   2009.03.02 05:35 GMT+1 óra  
az összes shadowmapnek ezek a "betegségei" - elkerülni nem lehet őket, csak elrejteni...

-a fénytől távoli oldalakra pl nem szabad árnyékot vetni
-a shadowmap felbontásának abszolut értelemben vett növelése ill. a relativ növelése segít a "kockákon" - erre a lispsm az tényleg jó, viszont nagyon pontosan kell a "virtuális" fénypoziciót fokuszálni - ennél jobban már csak a trapezoid shadow map tud fokuszálni, de ott már akkora a shadowmap mélységbeli torzítása, h egy fragment programmal kell neked interpoláltatni a mélységeket
-sokszor használják még a parallel split shadow mapet, de az megeszi a fillratet reggelire
-érdemes elmosni a "kockákat" sima blurral v percentage closer filterrel

természetesen ezek az esetek nem vonatkoznak az omni fényekre
alias aalberik
   
nadam - Törzstag | 364 hsz       Online status #105689   2009.03.02 05:29 GMT+1 óra  
szombatha:
Nem tudok segíteni, 'én úgy oldottam meg', hogy a shadow mapem felbontása, és a scene geometriája olyan, hogy ne nagyon látszódjon kockásodás... Másrészt én eleve PCF-es soft shadowot csinálok, ami azért is jó, mert a kockásodást elnyomja valamennyire...

Csak azért írok, hogy megjegyezzem: az ilyen problémáknál látszik, hogy a real-time ray-tracing-é a jövő: fényévekkel egyszerűbb kompromisszummentes árnyékot csinálni vele.
   
szombatha - Tag | 97 hsz       Online status #105686   2009.03.02 05:00 GMT+1 óra  
egy kicsit ha lehet visszatérnék a shadow témához. Volt megint egy kis időm és eljátszadoztam a ShadowMap-es árnyékképzéssel. Alapvetően működik, de ahogy egy kicsit tesztelgetem, mindig kiderült, hogy nem a kivánt eredményt hozza.

Mondok egy példát: megcsináltam a kis három toruszomat, meg a négy kockámat, meg gömböket amik az árnyékot fogják vetni. Majd megcsináltam a ground-ot amire az árnyék fog vetülni (meg persze az előbbi objektumok egymásra is vetik az árnyékot). Felülről megvilágitottam őket és láss csodát szép volt, jó volt, gyors volt. Aztán elkezdtem a fényforrást úgy elmozgatni, hogy az árnyékok jóóóóóóóól elnyúúúúúljanak. Természetesen az árnyék nagyon csúnyán bekockásodott, mivel túl nagy lett a vetett árnyék mérete, az árnyékot magába foglaló textúra mérete viszont limitált. Találtam a neten egy LISPSM "Light Space Perspective Shadow Maps" implementációt, 2006-os fejlesztésű, csak jókat irtak róla, de pontosan ugyanazokkal a "betegségekkel" küzd, mint az én kis próba shadowmap alkalmazásom (kockásodik, villog). Kiváncsi lettem és kicsit nagyitó alá vettem (jobb hijján) a régi jó öreg GTA SA-t. Kb. egy óra vizsgálódás után kiderült, hogy a GTA SA.-ban kínosan ügyeltek a fejlesztők arra, hogy túl éles szögben bevetődő fények(=elnyúlt árnyék) ne legyenek (vajon miért? ).

Ha valaki esetleg tud olyan whitepaper-t, ahol a fenti SM problémára értelmes megoldást adnak, akkor azt légyszi küldje el. Az általánosságban leirt hárombetűs varázsszavaktól légyszi kiméljetek, konkrét megvalósitási leirás kellene, ha van. Előre is köszi!

Ezt a hozzászólást szombatha módosította (2009.03.02 05:14 GMT+1 óra, ---)

   
bmateusz - Tag | 121 hsz       Online status #105630   2009.03.01 05:36 GMT+1 óra  
Én is végigjártam ezt az utat, és arra jutottam, az összes ilyen obj betöltő lib bugos. Így írtam egy sajátot, de az se tetszett.. Végül maradt a Milkshape 3D formátum, gyors, kis méretű, animációt is tud, kezdésnek jó

   
kicsy - Szerkesztő | 4304 hsz       Online status #105628   2009.03.01 05:26 GMT+1 óra  
Végülis csak első találat volt opengl obj loader sztringre.
kicsy ● SilentVertigo Team - project Solarah
http://blog.yscik.com
   
Thrall - Törzstag | 609 hsz       Online status #105625   2009.03.01 04:14 GMT+1 óra  
Idézet
kicsy :
http://sourceforge.net/projects/objloader/

De neked is ugyanannyi ráguglizni, mint nekem.


Köszi szépen, na azt nem tudom, hogy majd hogy tudom használni, de kiderítem.
Kerestem Google-el, de ezt sepeckó nem láttam...
Jatekfejlesztes.hu közös projekt: próbálunk összerakni egy olyan csapatot, akik együtt el tudnak készíteni egy komolyabb játékot megfelelő minőségben. Érdekel?
Link:
JF.hu közös projekt
http://frogbonegame.uw.hu/
   
proof88 - Törzstag | 528 hsz       Online status #105458   2009.02.27 02:59 GMT+1 óra  
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [15] [20] [25] [30] [35] [40] > 45 < [50] [55] [60] [65] [70] [75] [80] [82]