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

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2189
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] [22]
beast - Törzstag | 1241 hsz       Online status #95696   2008.09.08 03:20 GMT+1 óra  
Főleg, hogy a HL2 engine-t folyamatosan fejlesztik, mig az idTech4 már elég halott...

   
Asylum - Törzstag | 5455 hsz       Online status #95695   2008.09.08 03:13 GMT+1 óra  
a quake4-ben van más bump mappingen kivül?
anno a doom3 at is az vitte el a hátán...egyébként érdekes, hogy mikor a half-life 2 megjelent akkor mindössze annyit rottak fel neki h az árnyékok a doom3 ban szebbek. Nos ezt azota orvosolták, mig a q4-ben ugyanaz a vacak van (legalábbis én nemláttam soft shadow-t).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
syam - Törzstag | 1491 hsz       Online status #95688   2008.09.07 23:55 GMT+1 óra  
uigy a quake4 engine-jéből is lehet meríteni jó mélyen és ott még komment is van
alias aalberik
   
Asylum - Törzstag | 5455 hsz       Online status #95656   2008.09.06 06:51 GMT+1 óra  
nekem is feltünt de elég átláthatatlanok
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Kuz - Törzstag | 4455 hsz       Online status #95652   2008.09.06 04:55 GMT+1 óra  
Azért az nem gyenge, hogy a Mass Effect
...\Engine\Shaders
könyvtárban csak úgy ott figyelnek a shader kódok...
A memóriám már nem a régi. És ráadásul még a memóriám sem a régi...
Az élet attól szép, hogy bármi megtörténhet. És attól szar, hogy meg is történik...
Ha az egyik szinkronúszó megfullad, mit csinál a többi???

   
misi - Törzstag | 971 hsz       Online status #95644   2008.09.06 01:08 GMT+1 óra  
Azért kösz, a szándék a lényeg
   
Asylum - Törzstag | 5455 hsz       Online status #95642   2008.09.05 15:00 GMT+1 óra  
nem hozzáadni kell hanem szorozni
szerk.: ja látom te is rájöttél
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
misi - Törzstag | 971 hsz       Online status #95632   2008.09.05 09:51 GMT+1 óra  
Nem nagyon értek a shader-ekhez, de lenne egy olyan kérdésem, hogy van egy terrain, minden ploygon hoz ki olvasom melyik textúra mennyire kell ( blend... ), ügye ez egy textura map. Ezzel nincs is gond. De ezt szeretném színezni egy Colormap-al. Úgy csináltam beolvasom a színeket, és hozzá adom a textura map hoz. De ez nem jó mert nekem úgy kéne hogy alpha-s a szín vagyis úgy is színezze, és ne csak a 3 alap színnel... Így van megcsinálva:

float4 Color = tex2D(SandTextureSampler, input.texCoord) * TerrainColorWeight.b;
Color += tex2D(GrassTextureSampler, input.texCoord) * TerrainColorWeight.g;
Color += tex2D(RockTextureSampler, input.texCoord) * TerrainColorWeight.r;

//Colormap
Color.r += TerrainColorMAPWeight.r/TerrainColorMAPWeight.a;
Color.g += TerrainColorMAPWeight.g/TerrainColorMAPWeight.a;
Color.b += TerrainColorMAPWeight.b/TerrainColorMAPWeight.a;

Ez így nem jó. Vagy is az a a kérdés hogy tudok egy színhez úgy hozzá adni hogy az az alpha-val arányos legyen. Remélem értitek, és tud majd valaki segíteni.

Szerk.: Asszem sikerült. az alpa-t kell átfordítani, és nem hozzá adni kellet a szint hanem megszorozni vele:

//Colormap
Color.r *= TerrainColorMAPWeight.r/(1-TerrainColorMAPWeight.a);
Color.g *= TerrainColorMAPWeight.g/(1-TerrainColorMAPWeight.a);
Color.b *= TerrainColorMAPWeight.b/(1-TerrainColorMAPWeight.a);

Ezt a hozzászólást misi módosította (2008.09.05 10:30 GMT+1 óra, ---)
   
DMG - Szerkesztő | 3172 hsz       Online status #95626   2008.09.05 05:42 GMT+1 óra  
Kicsit leegyszerüsítettem a shadert, és gondoltam leírom ide pontosan mi is volt a probléma, mert az egyszerüsített shader is rendetlenkedett, azt miközbe írtam össze a dolgokat, rájöttem, hogy most meg kikommenteztem a 2. textúrát, mialatt próbálkoztam azt most ezért nem ment.
De most úgy néz ki, hogy az egyszerüsített shaderrel működik az átadás, szóval valami a shaderrel volt.
Már csak meg kell keresnek, hogy mi, de az már részlet kérdés, mert tudom, hol kell keresni.


Köszönöm a segítséget.

helyesbítek, ne a shaderekkel volt a baj (nagy állat fajta vagyok, hogy reprodukálni próbálom a hibát)

A glGetUniformLocation részek voltak elírva.

Ezt a hozzászólást DMG módosította (2008.09.05 05:47 GMT+1 óra, ---)
-----------------------------------------
Dont Listen to the Naysayers
   
DMG - Szerkesztő | 3172 hsz       Online status #95624   2008.09.05 04:16 GMT+1 óra  
Közben utóbbira rájöttem. Kezd tisztulni a köd.

a base_tex értéke glGenTextures-től jön, szóval nem lehet 0.

Kösz a linket, pár ilyet már átnézte, de ezt még nem láttam, talás segít.


Majd jelzem, mi lett.

Nagyon Kösz az eddigieket.
-----------------------------------------
Dont Listen to the Naysayers
   
syam - Törzstag | 1491 hsz       Online status #95623   2008.09.05 03:46 GMT+1 óra  
a fragment program müködésekor a texture enable/disable hatástalan

a base_tex értéke mennyi? (ha 0 akkor vagy gondban:])
az idézett kód alapból nem müködik, mert a tex unitok kaszkádszerűen müködnek, tehát ha a 0. unit nincs használatban akkor megszakad az egész texturázó pipeline

ez: http://www.gamedev.net/community/forums/topic.asp?topic_id=287220 talán segíthet
alias aalberik
   
DMG - Szerkesztő | 3172 hsz       Online status #95622   2008.09.05 02:53 GMT+1 óra  
Úgy tudom, hgoy ha shadert használok, akkor nem kell bekapcsolni.

De egyébként próbáltam.


Ahhoz, hogy a GL_TEXTURE1-es textúra unitot használjam, kell valami extension-t aktiválni? Lehet, hogy az maradt ki.

Mert, hogy ez sem hoz eredményt, csak szürke objektumot

Kód:
glUseProgram(NULL);
   
glActiveTexture(GL_TEXTURE1);
glBindTexture(GL_TEXTURE_2D, base_tex);
glEnable(GL_TEXTURE_2D);


Ennek működnie kellene shader nélkül nem?

Kilyukadt az agyam.

Ezt a hozzászólást DMG módosította (2008.09.05 02:58 GMT+1 óra, ---)
-----------------------------------------
Dont Listen to the Naysayers
   
beast - Törzstag | 1241 hsz       Online status #95621   2008.09.05 02:46 GMT+1 óra  
Engedélyezed a textúrázást az első (vagyis a második, vagyis a GL_TEXTURE1_ARB) unitra is?
Mivel alapból ki van kapcsolva, tehát:

Kód:
glActiveTextureARB(GL_TEXTURE1_ARB);
glEnable(GL_TEXTURE_2D);
glBindTexture(GL_TEXTURE_2D, normal_map);
glUniform1iARB(u_maxShader_normalAndHeight, 1);


Egyébként a GL_TEXTUREn és GL_TEXTUREn_ARB értékek megegyeznek, szóval mindegy.

   
DMG - Szerkesztő | 3172 hsz       Online status #95619   2008.09.05 02:35 GMT+1 óra  
Kéne egy kis help a mesterektől shader programozás kapcsán.

Egy ideje már szenvedek vele, eddig mindig megörültem, amikor találtam egy elírást a kódban, de már eljutottam arra a szintre hogy elvben minden fasza, mégsem működik.

Na szóval a textúra átadással vannak bajok.

egy textúrával még nincs baj multi textúránál van gubanc.

shader program nélkül leellenőriztem mind a két textúra jól betöltődik, de ha shadert hazsnálok, akkor nem hajlandó átadni rendesen.

így adnám át a textúrákat:

Kód:
glActiveTexture(GL_TEXTURE0);
glBindTexture(GL_TEXTURE_2D, base_tex);
glUniform1iARB(u_maxShader_baseAndGloss, 0);
   
glActiveTextureARB(GL_TEXTURE1_ARB);
glBindTexture(GL_TEXTURE_2D, normal_map);
glUniform1iARB(u_maxShader_normalAndHeight, 1);


viszont GL_TEXTURE1_ARB, mintha nem is létezne neki, nagy ívben tesz rá.

Meg nem igazán értem, hogy ha egy textúrával dolgozom csak, akkor nem mindegy, hogy milyen index alatt adom át?

Mert így nem működik:

Kód:
[code]glActiveTexture(GL_TEXTURE1);
glBindTexture(GL_TEXTURE_2D, base_tex);
glUniform1iARB(u_maxShader_baseAndGloss, 1);



lehet, hogy tök alapvető a problémám, de már belezavarodtam.

Előre is Kösz a segítséget.
-----------------------------------------
Dont Listen to the Naysayers
   
AmidaBucu - Tag | 281 hsz       Online status #94736   2008.08.20 11:12 GMT+1 óra  
Nah Shadowmap megvan csak csinál gy "artifactot" vagy mit. A blur miatt ottis "puhul" vagy eltünik az árnyék, ahol nem is kéne. Pl ha egy test az árnyék előt van, akkor az éle mentén jön elő ez a hiba.

Olvastam a vsm-ről is de az nekem még kinai és egész magyarázatot nem találtam hozzá. Azt pedig nem tudom mien anyagnál induljak el hogy megértsem a csebisev egyenlőtlenség használatát stb.

Ezt a hozzászólást AmidaBucu módosította (2008.08.24 02:17 GMT+1 óra, ---)
Ami tönkremehet, az tönkre is megy!!!
   
fpeti - Törzstag | 1291 hsz       Online status #94707   2008.08.19 16:31 GMT+1 óra  
Point-light-ra nyomsz SW-t 6* renderrel? szvsz nagyon sok - emiatt használnak inkább spotlight-okat ... nem is tudom shadowvolume-on kívül mi is lenne jó a villanykörtének..

Amúgy sw-re manapság sok helyen hallani egy pixelkernel-rotation (vagy milyen) módszerről, ott egy kis random textúrából olvasgatva koordináta-ofseteket kell pixelekkel átlagolni, én még nem csináltam ilyet, de ha a Crysis-ban bejött a cucc, csak nem lehet olyan rossz.
Asylum régebben linkelte errefele:
http://delivery.acm.org/10.1145/1290000/1281671/p97-mittring.pdf?key1=1281671&key2=9942678811&coll=ACM&dl=ACM&CFID=15151515&CFTOKEN=618461
   
AmidaBucu - Tag | 281 hsz       Online status #94704   2008.08.19 16:05 GMT+1 óra  
KK
Hozzáadtam 0.001-t. Igy Már nem masaztol (annyira). De az árnyék széle cikcakkos maradt igy is
Küldjek arrol is képet?

Akkor ehez csak a soft shadowmap jo?

Radásul nincs vmi trükkje a shadow mapnek?
Muszály egy shaderben számolnom a shadow mappet és PPL-t, mert csak igy tudom meghatárzni hol legyen érvényes a fény. De hála a kártyámnak 65 utasitás alá vagyok szoritva. Nincs vmi trükkje, hogy több shaderben van, de az eredmény ugyanaz?
Azon már gondolkoztam hogy átvetitem a shadow mappet egy texturába. De akkor max 16 shadowmappem lehet (4 RT*4 szincsatorna),mert tudnom kell meik fényhez tartozik az árnyék.
De egy pontfény alapból 6 shadowmap. Tehát max 2 pontfényem lehet?

Ezt a hozzászólást AmidaBucu módosította (2008.08.19 16:17 GMT+1 óra, ---)
Ami tönkremehet, az tönkre is megy!!!
   
Matzi - Szerkesztő | 2521 hsz       Online status #94697   2008.08.19 14:26 GMT+1 óra  
Szerintem it csak annyi a baj, hogy a kétféle távolság túl közel van, így néha úgy dönt, hogy hat az árnyék, néha meg nem. Edj egy epszilon-nyi távolságot a fénytől mért távolsághoz a textúrába mentett értékhez.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
AmidaBucu - Tag | 281 hsz       Online status #94695   2008.08.19 14:16 GMT+1 óra  
Nah Shadow mapp müxik már (hála a forumoknak ), csak kifelejtettem egy egyestz belőle. DE Olyan érdekesen maszatl ez az árnyék. http://ilab.hu/jf/datas/thumbs/987-dirtymap.jpg
Ami tönkremehet, az tönkre is megy!!!
   
AmidaBucu - Tag | 281 hsz       Online status #94556   2008.08.17 13:36 GMT+1 óra  
Hi! A Shadow Mappel lenne gondom. Elutottam addig hogy egy képbe kirajzolom a fény "kamerájától" vett távolságot (ez a textúra a 2es gomb hatására meg is jelenik a képernyőn).

És igy probálom használni:
Kód:
// VS
Output.tex = IN.tex;

// PS

// position kiszámolása depthből és texcoordból

float4 lpos = mul(mul(pos,LV),LP))
IN.lpos/=IN.lpos.w;
float2 sTexC = float2((1+lpos.x)/2,-(1+lpos.y)/2);

float c; // c mutatja hogy takarásban van e a pont

float SDepth = tex2D(shadowtex, sTexC).r;

if(SDepth < lpos.z) c = 0;
else c = 1;

De egyszerűen semmi!
Mármint csunyaság az 1000.en

Ha esetleg valaki ráérne, rá tudna nézni a shaderemre?

Ezt a hozzászólást AmidaBucu módosította (2008.08.18 13:24 GMT+1 óra, ---)
Ami tönkremehet, az tönkre is megy!!!
   
proof88 - Törzstag | 530 hsz       Online status #94511   2008.08.17 04:39 GMT+1 óra  
Üdv!

Itt is szólok, h elindult az általam szervezett engine verseny, ami itt elérhető: link
   
AmidaBucu - Tag | 281 hsz       Online status #93683   2008.08.05 06:34 GMT+1 óra  
Megvan oldva!
Igaz hatalmas rejtély. Ngaynehezen találtama aneten egy ilyen kodot:
Kód:
normal.z = -sqrt(1-dot(Normal.xy,Normal.xy));


Nah, most jöhet bloom. Nézegettem samplékat, de olyan mintha alig lenne több, mint egy blur.
Lehet hogy tévedek(vag yinkább valószínüleg), de igy csak az lesz "csillanva", ami közel áll a fehérhez. De mondjuk egy vörös fény is csillanhat, vagy nem?
Azt lehet ugy hogy külön texturába elmentem a speculart, elmosom, és ugy használom fel a végén?
Vagy olyan már van csak más a neve?

Ezt a hozzászólást AmidaBucu módosította (2008.08.08 03:45 GMT+1 óra, ---)
Ami tönkremehet, az tönkre is megy!!!
   
AmidaBucu - Tag | 281 hsz       Online status #93671   2008.08.04 16:07 GMT+1 óra  
fpeti
Szóval, milyen VS-ed van, mert nekem vs2005, ha neked 2008, akkor is bibi van..
Hát igen, bibi van ezekszerint.
És probáltad felrakni, amit abban a forumban mutattak? (Redistrizébigyo Package)
Ami tönkremehet, az tönkre is megy!!!
   
fpeti - Törzstag | 1291 hsz       Online status #93666   2008.08.04 12:59 GMT+1 óra  
Megvannak a dll-ek - ezek szerint nem az a gond.
Nem TCommanderből indítva azt írja, hogy nem futtatható mert a konfigurációja helytelen - telepítsük már újra.. googli ezt mondta rá (nem lepett meg):
http://prog.hu/tudastar/43068/Program+kompatibilitasa.html
másik:
http://prog.hu/tudastar/81081/Nem+tudok+VC+-szal+forditott+programot+futtatni.html
Szóval, milyen VS-ed van, mert nekem vs2005, ha neked 2008, akkor is bibi van..
   
AmidaBucu - Tag | 281 hsz       Online status #93653   2008.08.04 11:26 GMT+1 óra  
Idézet
Microsoft DirectX 9.0 SDK Update (October 2005)



Ezt az SDK-t használok. Abban van 27,33,36os verzió. Szerintem az uccsó.
Rapidra ne rakjam fel a dll-t?
Ami tönkremehet, az tönkre is megy!!!
   
fpeti - Törzstag | 1291 hsz       Online status #93636   2008.08.04 08:35 GMT+1 óra  
Idézet
AmidaBucu :
Nekem csak akkor irja ki ha nem csomagolok ki mindent egymás mellé.


Egy mappában vannak, de tényleg milyen redist kell neki?
(windows\system32\d3dx9d_34.dll a legmagasabb számú nekem, neked gondolom magasabb van..)
Sajna dll-files-on sincs már sokféle meg a MS dx update-je 80MB!, amit kicsit sokallok 1 dll-ért..de lehet letölöm azért a juniusit, remélem neked nem júliusi van...
- ha egyáltalán ez a hiba -

szerk: kipróbáltan júniusival, azzal is dettó.. nemtom.. másnak van ötlet?

Ezt a hozzászólást fpeti módosította (2008.08.04 09:00 GMT+1 óra, ---)
   
AmidaBucu - Tag | 281 hsz       Online status #93629   2008.08.04 07:25 GMT+1 óra  
Bocs későn vettem észre hpgy irtál
Igy csak updateltem alantabb
Ami tönkremehet, az tönkre is megy!!!
   
fpeti - Törzstag | 1291 hsz       Online status #93622   2008.08.04 07:07 GMT+1 óra  
Idézet
AmidaBucu :
Lehet ám! Ha több fénnyel akarsz dolgozni pélául normalmappingnál, bonyolultabb ha vertexshaderben transzformálod át a vektorokat a textura terébe. Egyszerűbb, ha át adod a TBN-mátrixot a pixel shadernek, és annyi fénnyel dolgozol, amennyit az sm-verziód megenged.
De gondolom ha egy vagy két plusz texcoordot adnék, megmakkanna



Aha, és tudja valaki, mennyi float-ot lehet max egy texcoord-ba tenni?? mert szvsz 4 a max, nekem ez volt a fura, de gondoltam ilyenkor hozzávesz még kettőt a compiler, hogy beleférjen a kilenc darab - de mondjátok, ha nem így van.

ps: deferred shaderben nincs is sm által megengedett max fényszám
   
AmidaBucu - Tag | 281 hsz       Online status #93613   2008.08.04 06:20 GMT+1 óra  
fpeti
Sajna exe nem indul "error executing program" ... milyen dx dll kell neki? (2008 márc van nekem d3dx9d_34.dll)

Nekem csak akkor irja ki ha nem csomagolok ki mindent egymás mellé.
Most felrakom méd 1x egy kicsit modositva az efekteket.
http://rapidshare.com/files/134775278/Projects.zip
1el és 'ö'-vel lehet váltogatni a final és normal "réteg" között // ezér ö mert a billenytyűzetet lusta vok átálitani angolról

fpeti

Kód:
float3x3 TBN : TEXCOORD2;

Ilyet tényleg lehet? - mert akkor tanultam ma is valamit (egy texcoordban 9 float.. lehet több coord-ot is használ?)



Lehet ám! Ha több fénnyel akarsz dolgozni pélául normalmappingnál, bonyolultabb ha vertexshaderben transzformálod át a vektorokat a textura terébe. Egyszerűbb, ha át adod a TBN-mátrixot a pixel shadernek, és annyi fénnyel dolgozol, amennyit az sm-verziód megenged.
De gondolom ha egy vagy két plusz texcoordot adnék, megmakkanna

fpeti

Aha, és tudja valaki, mennyi float-ot lehet max egy texcoord-ba tenni?? mert szvsz 4 a max, nekem ez volt a fura, de gondoltam ilyenkor hozzávesz még kettőt a compiler, hogy beleférjen a kilenc darab - de mondjátok, ha nem így van.



Sztem nem csak texccordok számával hanem a méretükkel is kell számolni.
Elfoglalhatnak 4 float-nyi helyet is. Plusz még van valamien VPOS és VFACE is. Tehát van elég hely bőven. Mondjuk álmos vagyok és ilyenkor még az 1*1 se megy.

Ezt a hozzászólást AmidaBucu módosította (2008.08.04 07:28 GMT+1 óra, ---)
Ami tönkremehet, az tönkre is megy!!!
   
fpeti - Törzstag | 1291 hsz       Online status #93567   2008.08.03 12:32 GMT+1 óra  
Sajna exe nem indul "error executing program" ... milyen dx dll kell neki? (2008 márc van nekem d3dx9d_34.dll)

Kód:
normal.w = 1.0;
normal = mul(V, normal);
normal /= normal.w;

Milyen mátrix ez a V? (view?)
w=1 : ez pozíció szorzása mátrixxal, a normál irányvektor, nem pos.
irány (normál) esetén (x,y,z,0) alak kell, mert csak a mátrix 3*3-as részét használja, eltolni nem kell a normálisokat. (Így w-vel sem kéne osztani) - gondolom.

Kód:
float3x3 TBN : TEXCOORD2;

Ilyet tényleg lehet? - mert akkor tanultam ma is valamit (egy texcoordban 9 float.. lehet több coord-ot is használ?)
   
AmidaBucu - Tag | 281 hsz       Online status #93566   2008.08.03 11:46 GMT+1 óra  
Ami tönkremehet, az tönkre is megy!!!
   
fpeti - Törzstag | 1291 hsz       Online status #93558   2008.08.03 10:48 GMT+1 óra  
Idézet
Asylum :
normal = mul(V, normal);// ja itt csak igy, forditva jó, de mért?

Asylum

a mátrixsszorzás NEM kommutativ





Itt azt szerette volna mondani, hogy fordítva kéne, hogy jó legyen, de így jó... viszont így sem jó
(elvileg transzonált mátrixoknál van ilyesmi)

AB: megnézném az exe-t, hogy lássam egyszer végre, pláne jó lenne a .fx file-t is egyszer egészben végignézni, mert ezekből a kiragadott sorokból lehetetlen bármit megmondani, szóval küggyé linket, vagy valami.
   
AmidaBucu - Tag | 281 hsz       Online status #93557   2008.08.03 10:27 GMT+1 óra  
Jo. Tudom, nem azon volt a téma hogy mér nem mind1, hanem mért.
Aigzábol azt nem sikerült összehozni, hogyan kell a normalt rendesen kamera térbe elforgatni.
Ami tönkremehet, az tönkre is megy!!!
   
Asylum - Törzstag | 5455 hsz       Online status #93555   2008.08.03 08:47 GMT+1 óra  
normal = mul(V, normal);// ja itt csak igy, forditva jó, de mért?

Asylum

a mátrixsszorzás NEM kommutativ

C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
AmidaBucu - Tag | 281 hsz       Online status #93554   2008.08.03 08:30 GMT+1 óra  
Nem müxik a normál lementése
A netren meg csak azt a gyökös visszafejtést mutatják.
Ami tönkremehet, az tönkre is megy!!!
   
AmidaBucu - Tag | 281 hsz       Online status #93453   2008.08.01 08:06 GMT+1 óra  
fpeti
Ugye TBN mátrixxal szorozva normálok a world spacebe kerülnek,(ez megvan?) és azt még beszorzod WVP-vel?
Akkor kétszer szorzod W-vel?
Egyenlőre nem fglalkoztam testek transzformálásával. Tehát a w nálam csak egy identitás mátrix.

Akkor G16R16 és G16R16F között annyi csak a különbség, hogy míg az előbbi tagjai [0,1] es intervallumban vannak, addik az utóbbi nem? (tehát lehet monnyuk 999.9999 is?)

KK még utánanézek, amit mondtál.

Nah elvileg meg van a normal raktározás. Kiis feszítettem. Ellenörzésképpen körbeforogtam a kamerával egy kocka belsejében, és azt tapasztaltam hogy minnél inkább szemben van a kamera a felülettel, az annál kékebb, viszont ha szűk szögből lát rá akkor már fehér. (Azt is nézni kell, hogy mivel kétcsatornás D3D format, azér a kék alapból max mindig)
Ez azt jelenti hogy müködik a normal ViewSpaceba valo átforgatása?
Viszont vissazfejteni nem tom
Kód:
// build pass
             normal.xyz = normaliza(IN.normal);
             normal.w = 1.0;
normal = mul(V, normal);// ja itt csak igy, forditva jó, de mért?
normal /= normal.w;
OUT.normal.r = 0.5*normal.x+0.5;//G16R16F
OUT.normal.g = 0.5*normal.y+0.5;//

//lighting pass

              float4 normal;
normal.xy = (2*tex2D(normaltex, IN.tex.xy)-0.5).xy;
normal.z = sqrt(1 - (normal.x*normal.x) - (normal.y*normal.y));
normal.w = 1;
normal = mul(IV, normal);
normal /= normal.w;


De nem eszi meg Viszont az se biztos, hogy a normalok jok)

Valaki nem nézné meg az exe-met. Csak annyi hogy egérrel körbeforog a kockában és megmonnya, hogy joe vagy rosz-e?

Ezt a hozzászólást AmidaBucu módosította (2008.08.02 14:05 GMT+1 óra, ---)
Ami tönkremehet, az tönkre is megy!!!
   
fpeti - Törzstag | 1291 hsz       Online status #93452   2008.08.01 07:51 GMT+1 óra  
Normálok WVP spaceben? Nekem ez kissé fura, lehet csak WV kellene ? (screen space..)
Vagy ezt láttad valahol?
Ugye TBN mátrixxal szorozva normálok a world spacebe kerülnek,(ez megvan?) és azt még beszorzod WVP-vel?
Akkor kétszer szorzod W-vel?
(én mondjuk simán letároltam a normált 8 bites rgb-ben, és nem volt csúnya, vagyis csak tbn-nel szorzom és szeva.)
ha 16bites Float-ban tárolod, akkor még ok a tárolás , ha 8 biten, akkor a -1 +1-et is el kell tolni 0-1 intervallumba, esetleg ez is lehet hiba.
   
AmidaBucu - Tag | 281 hsz       Online status #93449   2008.08.01 07:28 GMT+1 óra  
Jah, közben nem vettem le hogy irtál és csak updateltem
z-fájting tuti nem lehet, mer csak az az egy kocka van kirajzolva. Lehet ott rontottam el, hogy a normal xyz-nek 8-8 bitet adtam csak. Most probáltam ezt megoldani. Amit elrontottam bemásolva alantabb
Ami tönkremehet, az tönkre is megy!!!
   
fpeti - Törzstag | 1291 hsz       Online status #93445   2008.08.01 07:20 GMT+1 óra  
Most a messzi link nem müxik... kabaré, de a kettőből megvan, a messzi tényleg csúnya, nekem fel se tünt, mert túl sötétre van állítva a monitor.
A normálokkal nem kéne ennyire rossznak lennie annak a pár pixelnek.. nagyon fura ez már tényleg.. ha a z lenne itt ott rossz, az is okozhatná ezt..(messze kerülne a fénytől a pixel)
- ezt megnézheted, ha megnézed a z-s textúrát, produkálja ezeket a pixeles hibákat.
más ötletem nincs egyelőre. (kicsit z-fighting szaga is van, az nem lehet?)
   
AmidaBucu - Tag | 281 hsz       Online status #93440   2008.08.01 07:03 GMT+1 óra  
XD http://www.ilab.hu/jf/datas/users/987-kozel_1.jpg
http://www.ilab.hu/jf/datas/users/987-messzi.jpg

Nah itt van, rendesen(elöbb ö-betűt hagytam a ké nevében ). Oké már ez rendben, de az még nincs, hogy mér vn az hogyha távoloddok, megcsunyul a kép. Még emésztek. Monnyuk, lehet hogy a normáloknak adtam meg tulpici helyet.

Nah mosta a normalt szeretném elrakni, de csak a z xy-t. Igy próbáltam.
Kód:
// PS
normal = mul(normal, WVP);
normal = normalize(normal);
OUT.normal.r = normal.x;
OUT.normal.g = normal.y;

// visszafejtés
float3 normal;
normal.xy = tex2D(normaltex, IN.tex.xy).xy;
normal.z = sqrt(1-(normal.x*normal.x)-(normal.y*normal.y));
normal = mul(normal, IVP);


De nem müx mit rontttam el?

Ezt a hozzászólást AmidaBucu módosította (2008.08.01 07:26 GMT+1 óra, ---)
Ami tönkremehet, az tönkre is megy!!!
   
fpeti - Törzstag | 1291 hsz       Online status #93414   2008.07.31 16:17 GMT+1 óra  
Második kép 404.

Özzekh , magamtól idézek, lentebbről:
Idézet
fpeti :
A 8bit-re kikerülés nem a shaderben dől el, hanem a RT típusáról, ha R32 típusú, akkor az color.r be kell tenni a releváns adatot és kész, 32 biten tárolja.


Szal simán berakod a keletkezett z-t COLOR[0-1-2-3].r-be és kész, a többi COLOR.gba tök mindegy mit teszel, nem kerül bele a textúrába!.
Ha azt a G16R16-ot akarod csak z-re használni, szopacs, vagy a COLOR.r, vagy a COLOR.g-be írhatod a z-t, de mindenképpen 2x anyi helyet foglal (valami mást tehetnél a másikba).
   
AmidaBucu - Tag | 281 hsz       Online status #93413   2008.07.31 15:52 GMT+1 óra  
Huh.. Köszi!!! most jön az emésztés ideje
Viszont most kipróbáltam, vmit. G16R16 formátumot használtam rtnek.
És igy mintha most jó lenne. Tehát az lett volna a probléma, hgy rosz textura formátumot használtam? Azt még mindig nagyon nem értem hogy kell egy depth-re felhasználni 16bitet úgy hogy a kimeneti float alapból (meg az rt formátuma is) négy darab 8bites komponensre van felosztva(rgba).
De még egy ujjab probléma:
http://www.ilab.hu/jf/datas/users/987-messzi.jpg
http://www.ilab.hu/jf/datas/users/987-közel.jpg
Ha távolodok a kamerával, megcsunyul áleszcuzámmen
Ami tönkremehet, az tönkre is megy!!!
   
fpeti - Törzstag | 1291 hsz       Online status #93407   2008.07.31 15:15 GMT+1 óra  
Persze, hogy van:
'dsRender' az objektumokat rajzolja mrt-be (color, z, bumpnormals)
'dsPLight_diff' pedig egy point diffuse fényforrásnak van, colorbump, +specular
http://ilab.hu/jf/datas/users/776-effect.rar
- kommentekből látszik, szenvedtem vele én is..
- a .c kiterjesztés ne zavarjon, vc ide-vel szoktam őket szerkeszgetni, azért van, de amúgy .fx lenne.
   
AmidaBucu - Tag | 281 hsz       Online status #93402   2008.07.31 15:00 GMT+1 óra  
Nos, ahogy nézem mát ott rosz, mikor simán kirajzolom a texturát, amiben a mélységet raktározom. Eddig nem volt feltűnő, mert minden csupa fehér volt, de mikor elosztottam egy kisseb számmal a kimenő színt(mélységet),akkor már itt is megjelentek ezek a kamera sikjára párhu...
Neked nincs egy saját fx,cg vagy akármien fájlod amiben ilyet csinálsz?
Ami tönkremehet, az tönkre is megy!!!
   
fpeti - Törzstag | 1291 hsz       Online status #93319   2008.07.30 14:18 GMT+1 óra  
Attól még jónak kéne lennie a mrt-s z-nek... az lenne az első lépés, utána a létrejött texek használta.
Gondolom jó sok kód, ráadásul, ha te írtad, akkor te tudod benne megtalálni legkönnyebben a hibát, én ilyenkor le szoktam butítani a dolgot, és külön kipróbálni csak azt, ami valszeg nem megy.
pl kitalálni, a z milyen tartományban kerül a bufferébe.. osztogatva a színekből ki lehet találni..meg ilyesmi.
   
AmidaBucu - Tag | 281 hsz       Online status #93318   2008.07.30 13:50 GMT+1 óra  
És az nem lehet az ka, hogy rossz a VP mátrix inverze? Vagy akkor még ennyire se lenne jó?
Nekem ez az egész egy kész rejtély
Valakit lekéne téglázni, hogy hajlandó legyen rákkukantani az egész cumóra.
Ami tönkremehet, az tönkre is megy!!!
   
fpeti - Törzstag | 1291 hsz       Online status #93317   2008.07.30 13:24 GMT+1 óra  
Ha osztasz a w-vel, akkor igen, a Z a near-far plane közötti távolságon interpolál 0-1 között.
Ha túl messze lenne, akkor már nem is látszna das test
   
AmidaBucu - Tag | 281 hsz       Online status #93316   2008.07.30 13:18 GMT+1 óra  
Azt megkérdezhetem, hogy az xyz hármas a projekciós térben [0,1] intervallumban van? És a z is? Mer nem lehet az a baj hogytul messze van a test?
Ami tönkremehet, az tönkre is megy!!!
   
fpeti - Törzstag | 1291 hsz       Online status #93314   2008.07.30 12:23 GMT+1 óra  
Ezt a kódot már láttam, alapból így kell csinálni.
Bár:
most is csak fetételezgetni tudok, de kiszámolod a OUT.POS-t utána az OUT.Pos-t használod, amit itt nem állítasz be... részletekből nehéz.

A 8bit-re kikerülés nem a shaderben dől el, hanem a RT típusáról, ha R32 típusú, akkor az color.r be kell tenni a releváns adatot és kész, 32 biten tárolja.
Másrészről a 8 bites mélységgel se ilyennek kéne lennie.
   
AmidaBucu - Tag | 281 hsz       Online status #93312   2008.07.30 12:07 GMT+1 óra  
Nah, sikerült tovább jutnom a nyomozásban
Most ugy rajzoltattam ki a z-t hogy elosztottam egy kissebb számmal. És itt is megjelent az "ismétlődés". Ugyanugy, mit az előző képnél csak difftex nélkül. Kamera sikjára párhuzamosan.
fpeti, te hogy mented ki a mélységet? Én agy:
Kód:
// VS
OUT.POS = mul(IN.Pos, WVP);
OUT.Depth.x = OUT.Pos.z;
OUT.Depth.y = OUT.Pos.w; //float2

// PS

OUT.Depth = IN.Depth.x / IN.Depth.y; // Ha itt irtam rosszul vmit, akkor csak 8 bitre kerül ki a mélység, lehet ez a baj?

Nah itt valami rsz nekem?
Ami tönkremehet, az tönkre is megy!!!
   
Frissebbek | Korábbi postok
[1] [2] [3] [4] [5] > 6 < [7] [8] [9] [10] [15] [20] [22]