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] [22]
fpeti - Törzstag | 1280 hsz       Online status #93309   2008.07.30 11:39 GMT+1 óra  
Idézet
AmidaBucu :
Olyan mintha a z tartalma bizonyos távolságonként ismétlődne.



Na ez már jobb, most már sikerült nem csak thumbnailbe belinkelni a képet... tényleg olyan, ha az intenztás változása azt jelentené.. nem igazán értem, hogy kerül a téglatextúra a z-be, de biztos neked sincs rá sok időd
Ilyen hibával még nem találkoztam de olyan, mintha a z nem 0-1 közé esne, hanem simán nőne, de gondolom w- vel osztasz, meg már mondtad is, hogy igen, nincs ötletem.

Z: 0.f-1.f
   
AmidaBucu - Tag | 281 hsz       Online status #93305   2008.07.30 08:39 GMT+1 óra  
Nah már nagyon nem vágom, csak azt hogy a mélységgel van vmi geb@sz.

http://www.ilab.hu/jf/datas/users/987-amidae%202008-07-30%2017-34-00-13.jpg
Olyan mintha a z tartalma bizonyos távolságonként ismétlődne.
Ami tönkremehet, az tönkre is megy!!!
   
Asylum - Törzstag | 5440 hsz       Online status #93304   2008.07.30 07:45 GMT+1 óra  
akkor nem. de ha elég közel megyek akkor már igen.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
TPG - Tag | 3402 hsz       Online status #93303   2008.07.30 07:36 GMT+1 óra  
Idézet
Asylum :
rájöttem, hogy a pom eredménye a mesh-töl is eléggé függ...és ez probléma, és igazából nem értem, hogy miért...valaki tudja? Azon a vidám kis disc.x en tökjol müködik, nem torzul, de egy kockán viszont borzalmas, még akkor is, ha sok vertexböl áll..mi a különbség?


Ha a kocka egy adott oldalát teljesen szemből nézed, akkor is?
Reality is almost always wrong. - House

   
newversion - Tag | 197 hsz       Online status #93302   2008.07.30 07:02 GMT+1 óra  
mert a pom-pom egy szar sose használnám
bár vannak pontosabb algoritmusok , de engem rohattul hidegen hagynak
vagy sima normalmap, vagy akkor má relief
   
Asylum - Törzstag | 5440 hsz       Online status #93291   2008.07.30 04:41 GMT+1 óra  
rájöttem, hogy a pom eredménye a mesh-töl is eléggé függ...és ez probléma, és igazából nem értem, hogy miért...valaki tudja? Azon a vidám kis disc.x en tökjol müködik, nem torzul, de egy kockán viszont borzalmas, még akkor is, ha sok vertexböl áll..mi a különbség?
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
AmidaBucu - Tag | 281 hsz       Online status #93261   2008.07.29 13:55 GMT+1 óra  
Hát, a Depth-t tartalmazó texturát kirajzoltattam már a képernyőre és -sima View vagy ViewProjection térben lévő z-t- és egy sima fehér képernyő jött elém, de közeli pixeleknél megszürkült, annak arányában, mien messze van. ha jól tudom ez így jó.
A normálokat is kirajzoltattam. ami pixel a z tengely irányában "nézett", kék volt. A példakocka más oldalainak másmás szine volt. Ez is jó szerintem.
Néhány hszszel lejjeb beraktam a képeket, mit hülyül a kód.
Szerintem a depth értékével lehet baj, mer a kép alapján olyan, mintha nem átmenetesen, hanem ugrásszerűen lenne a pixeleknek mélysége. Ilyen a kamera sikjára párhuamos "nemtomhogyhivják" vannak. Azé teszek a kdoddal egy összehasonlitást azt kisül valami.
fpeti
ennél a résznél az Out.Depth COLOR0-1-2-3? (nem DEPTH..)

Jajám!

Nah itt van, ahogy te szeretnéd
Kód:
             IN.tex -= halfpixel;//csak neked :D
float depth = tex2D(depthtex, IN.tex.xy).r;

float4 pos;
pos.x = (IN.tex.x-0.5)*2;
pos.y = -((IN.tex.y-0.5)*2);
pos.z = depth;
pos.w = 1;

pos = mul(pos, IVP);
pos /= pos.w;


Egyedüli különbség, hogy míg te a positionbol számoltad ki a texturakordinátát, én csak szimplán azt használtam. Amuyg meg, TUTI hogy a depthvel vana baj. De mikor kirajzlom a méylséget, jónak tűnik. Amugy nem tom elmagyarazni a hibát, mer nagyn eredeti . Csak képpel tk szolgálni, ami lejjebb van, vagy esetleg egy teljes forráskoddal (de gondolom ahoz nincs elég időd )

Amugy meg olyasmit csinál, hogy "felosztja" a teret a kamera sikjára párhuzamos sikokra, és azoknak a z-jével számol. Tehát némely szomszédos pixel z-értéke közöt nem egy minimális különbség van, hanem egy nagy szakadék. És ahogy megyek előre vagy hátra a kocka fala felé, a fény néha mögé kerül, néha elé(és """"működik"""" a világítás).

Azt azér megkérdezhetem, hogy projekciós térben a a z értékis [-1,1]es interva... rangeben van?
Monnyuk probáltam lementeni a sima kamera terében lévő z-t is, de ugyanaz az eredmény .

Ezt a hozzászólást AmidaBucu módosította (2008.07.29 14:42 GMT+1 óra, ---)
Ami tönkremehet, az tönkre is megy!!!
   
fpeti - Törzstag | 1280 hsz       Online status #93260   2008.07.29 13:14 GMT+1 óra  
Lehet kicsit egymás mellett beszélgetünk, bemásolom az én fénykódom egy részletét, mintha más lenne itt-ott:
Kód:
void ps_color( float4 Pixelpos: TEXCOORD0,
out float4 c0: COLOR0)
{
    // sceen coord
    Pixelpos.xy /= Pixelpos.w; // -1,+1 között lesznek így
    // tegyük át 0-1 közé
    float2 texpos = float2(Pixelpos.x,-Pixelpos.y)*0.5+0.5;
    texpos -= HalfPixel; // NÁLAD EZ NINCS? állítólag kell.. ;)
    float depth = tex2D(S1,texpos).r;
    float4 worldpos;
    worldpos.xy = Pixelpos.xy;
    worldpos.z = depth;
    worldpos.w = 1.0f;
... a többi ok.

a másik:
Kód:
// PS
Out.Depth = IN.Depth.x / IN.Depth.y;

ennél a résznél az Out.Depth COLOR0-1-2-3? (nem DEPTH..)

Így részletekben nehéz kitalálni.. egyébként mit csinál rosszul?
leellenőrizted, hogy a z jó-e, a normálok jók-e.
Szín alapján meg lehet mondani mi a baj, ahogy 2-vel ezelőtti postomban is mutattam, rajzoltasd ki a buffereket, melyik hogy néz ki..legalább az legyen meg, hogy a mrt-s rajzolásnál, vagy a fényeknél van a bibi.. addíg csak találgatunk.
   
AmidaBucu - Tag | 281 hsz       Online status #93232   2008.07.29 07:18 GMT+1 óra  
Kód:
// VS
Out.Pos = mul(IN.Pos, WVP);
Out.Tex = IN.tex;
Out.Depth.x = Out.Pos.z;
Out.Depth.y = Out.Pos.w;
....
// PS
Out.Depth = IN.Depth.x / IN.Depth.y;

//fények

float4x4 WVP;
float4x4 IVP;
.....
// PS
float Depth = tex2D(depthtex, IN.Tex.xy).r;

float4 WPos;
WPos.x = 2*IN.Tex.x-1;
WPos.y = 1-2*IN.Tex.y;
WPos.z = Depth;
WPos.w = 1;

WPos = mul(WPos, IVP);
WPos /= WPos.w;


Nah, így probálkoztam visszafejteni a poziciót. De természetesen valamit eltégláztam benne.
Ami tönkremehet, az tönkre is megy!!!
   
fpeti - Törzstag | 1280 hsz       Online status #93215   2008.07.28 13:14 GMT+1 óra  
Idézet
AmidaBucu :
Jah. Nagyon nem vágom, mert a kod ,amit beillesztettem, nem tűnik rosznak. Hol irtam el vmit?
Jah,a tiédet nemértem, mert sok benne a változó, ami nekem ismeretlen.

Jah, amugy meg mikor a mélységet mntjük le akkor a pos zjét a VP térben vagy a V térben kell lementeni? És hogyan érhetem azt el hogy mikor mentek ki, a pixelsahderben a mélységet ne 8, hanem 16 bitre mentsem ki?



A kód, amit adtál nem foglalkozik a z-írással, szal fogalmam sincs, az jó-e, ez a kódrész jónak néz ki.
A z-t a WVP szorzással kapod, amiből a z,w-t a LINKELT példa átadja a ps-nek és ott osztja a z-t w-vel, és azt kell vmelyik color-ba írni.

Érdemes neki legalább 16, de még jobb 32 bites RT-t használni, ezt a rt textúra létrhozásnál kell megadni neki mégpedig a D3DFMT_R32F D3DFORMAT képében
16 bitesnél mondjuk jó lehetne a D3DFMT_G16R16F (minden rt-nek 32 bitesnek kell lennie, lehetne mint 64 is, de az nagyon durva lenne) - itt marad 16 bited üresen, oda még lehet valamit tenni.
   
AmidaBucu - Tag | 281 hsz       Online status #93212   2008.07.28 11:10 GMT+1 óra  
Jah. Nagyon nem vágom, mert a kod ,amit beillesztettem, nem tűnik rosznak. Hol irtam el vmit?
Jah,a tiédet nemértem, mert sok benne a változó, ami nekem ismeretlen.

Jah, amugy meg mikor a mélységet mntjük le akkor a pos zjét a VP térben vagy a V térben kell lementeni? És hogyan érhetem azt el hogy mikor mentek ki, a pixelsahderben a mélységet ne 8, hanem 16 bitre mentsem ki?
Ami tönkremehet, az tönkre is megy!!!
   
fpeti - Törzstag | 1280 hsz       Online status #93169   2008.07.27 12:08 GMT+1 óra  
Nálam sima diffúzra ez van:
Kód:
// ================= color only ===============================
// per pixel light, color only
void vs_color( float3 pos: POSITION,
out float4 oPos: POSITION,
out float4 oPixelpos: TEXCOORD0)
{
// scale obj space
float3 newp = pos* Pos_radius.w; // nyújtás
newp +=Pos_radius.xyz; // offset middlepoint in world space

oPos = mul(float4(newp,1),mVP);
// Itt a screen space pos kell a pixel shadernek!!!
oPixelpos = oPos;
}

// color only
void ps_color( float4 Pixelpos: TEXCOORD0,
out float4 c0: COLOR0)
{
// sceen coord
Pixelpos.xy /= Pixelpos.w; // -1,+1 között lesznek így
// tegyük át 0-1 közé
float2 texpos = float2(Pixelpos.x,-Pixelpos.y)*0.5+0.5;
texpos -= HalfPixel;

float3 LightPos = Pos_radius.xyz;

// mIVP - projekciós(view) mátrix inverze
float depth = tex2D(S1,texpos).r; // z buffer value
float4 worldpos;
    worldpos.xy = Pixelpos.xy;
    worldpos.z = depth;
    worldpos.w = 1.0f;
    worldpos = mul(worldpos,miVP);
    worldpos /= worldpos.w; // így jön vissza az x,y,z

// fényerő
float att = (1-saturate(distance(worldpos,LightPos)/(Pos_radius.w)));

// végre számoljunk pixel-light vektort!
float3 pixeltolight = normalize(LightPos - worldpos);
// bump normal
float3 normal = tex2D(S0,texpos)*2-1;
float NdotL = saturate(dot(normal,pixeltolight));
c0 = LightColor* (att * NdotL);
}


Idézet
AmidaBucu :
Jah amugy a depth-t jo ugy elmenteni, hogy redbe a (z) és greenbe a (w), és majd a többi efektben elosztom őket? Vagy nem igy kell?


Elég a z/w-t kiírni, itt hol is van az erre vonatkozó kód? mert ez
Kód:
float depth  = tex2D(depthtex, IN.tex.xy).r

csak kiolvassa... nem kell a w a RT-be...z el kell vele osztani ps-be és kiírni a z-t..
Nem árt tudni mi van a rt-kben, érdemes kirajzoltatni mindet, pl nálam:
[img]
http://ilab.hu/jf/datas/users/776-deferred%203%20screen.png
[/img]
   
AmidaBucu - Tag | 281 hsz       Online status #93165   2008.07.27 05:13 GMT+1 óra  
Sikerült lementeni a képet 3 részre (szín, mélység, normal)
De az alább kód furcsán működik,
Kód:
float4 PS(VS_OUTPUT IN) : COLOR0
{
float3 normal = 2*(tex2D(normaltex, IN.tex.xy)-0.5).xyz;
float4 diff = tex2D(difftex, IN.tex.xy);
float depth  = tex2D(depthtex, IN.tex.xy).r;

float4 pos;
pos.x = 2*(IN.tex.x-0.5);
pos.y = -(2*(IN.tex.y-0.5));
pos.z = depth;
pos.w = 1;

pos = mul(pos, IVP); //ez tuti nem rosz, az eredeti, nem kifordított alakja rendesen müködik més effektben
pos /= pos.w;

float3 tL = normalize(lPos-pos.xyz);

float d = max(dot(normal, tL),0);
float4 color = d * diff;
    return color;
}




Talán a VP mátrixot nem jó kifordítani d3dxmatricInverse függvénnyel?

Lehet hogy mivel ilyen érdekes a kameráéra párhuzamos síkk vannak, hogy a z-t mentettem volna le rosszul?

Jah amugy a depth-t jo ugy elmenteni, hogy redbe a (z) és greenbe a (w), és majd a többi efektben elosztom őket? Vagy nem igy kell?

Ezt a hozzászólást AmidaBucu módosította (2008.07.27 09:49 GMT+1 óra, ---)
Ami tönkremehet, az tönkre is megy!!!
   
AmidaBucu - Tag | 281 hsz       Online status #93140   2008.07.25 17:24 GMT+1 óra  
nah, már vágom ( nem egészen).
Csak a texturakordinátát át konvertálom "rendes" [-1,1] kordináttá és "kiforditott" viewprojjal beszorzom. Igy megvan az x meg az y az z meg a depth bufferből (RT).

[megértettem]

Ezt a hozzászólást AmidaBucu módosította (2008.07.26 05:49 GMT+1 óra, ---)
Ami tönkremehet, az tönkre is megy!!!
   
newversion - Tag | 197 hsz       Online status #93139   2008.07.25 15:18 GMT+1 óra  
ez ps3-as engine, amiben van egy 8 magos proci is, simán áttolhatja a procinak meg vissza
belefér
   
fpeti - Törzstag | 1280 hsz       Online status #93137   2008.07.25 14:08 GMT+1 óra  
1 ja, a z-t el kéne menteni, dof-ot még nem csináltam. (amúgy nálam a vs kiszámolja a z,w-t, átadja ps-nek, és ott osztja z-t a w-vel.)

2 az 'ds' elég érdekes, mivel a stencil is benne van, ezek szerint ez a z buffer, a klasszikus 24D8S (24 bit a z buffer 8 bit a stencil).
Erre én is kiváncsi lennék, hogy tudják ezt használni, tudtommal nem lehet z bufferből csak úgy olvasgatni, stencilt lehetne RT-be rakni?. kétlem - deakkor honnan van nekik a z?
pedig oda van írva:
"Position computed from depth buffer and pixel coordinates". ezt nagyon nem értem - én egy rt-ben tárolom a z-t, máshol így csinálják, ez elég nagy hülyeség lenne, ha simán a zbufferből lehetne használni..ráadásul ekkor a stencilt is lehetne olvasni... húúha.

3. Hogyan gondolod menteni? mert az x,y,z csak 0-1 közé eshet, ráadásul 8 bites pontossággal semmit sem érhet szvsz, 16-tal meg sok helyet foglal - vagy 32biten meg 3 RT-t is elvisz, nagyon nem éri meg - több számolás ugyan, de vissza lehet számolni screenspace-ből, elvileg itt is ez van, csak az a frány z honnan jön nekik?

- valaki más fogja ezt? Itt a relink:
http://www.guerrilla-games.com/publications/dr_kz2_rsx_dev07.pdf
   
AmidaBucu - Tag | 281 hsz       Online status #93108   2008.07.25 04:48 GMT+1 óra  
tehát ha nekem tegyük fel hogy dof kéne (majd nagyon ská ),akkor előbb a positiont beszorzom worlddel, majd viewvel. És az igy kapott z-t feltom használni dofra?

Amugy szeretnék kérdezni még vmit.
Néztem vmeik tutort, amit ti linekletek (killzone2).
Ott 4 rendertargetet és egy ds-t használtak lementésre. A DS-ről nem ir semmit hogy miaz, neten se találni nagyn, szerintetek mi?

Jah még azt is megszeretném kérdezni hogy
Lementsem-e a positiont a gbufferbe?
Ami tönkremehet, az tönkre is megy!!!
   
Asylum - Törzstag | 5440 hsz       Online status #92796   2008.07.19 10:53 GMT+1 óra  
ha viewprojba rakod akkor azzal levetited a képernyöre, ha csak view be akkor a kamera terében lesz (a három kamera vektor által meghatározott térben).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
AmidaBucu - Tag | 281 hsz       Online status #92785   2008.07.19 08:15 GMT+1 óra  
már megnéztem mind a kettőt amit küldtetek, köszi is. csak egy kicsit már belezavarodtam mer minda kettő példa egy picit máskép dogzik. az egyik a view spaceba rakja a normált a másik meg simánscak world be. Gndolom mikor a viewben van a normal szamad használni a
Normal.z = sqrt(1.0f - Normal.x2 - Normal.y2) kódot. ugye? Azt hadd kérdezzem meg hogy itt viewbe vagy viewprojectionba kell rakni a normalt?

De ha normal nem a worldban van, akkor monnyuk egy PPL shaderben a fényeket (ha többet akarok használni) a PSben kell egyesével átforgatni a térbe. Jol gondolom ugye? vagy ez vagy az. Ti feláldoznátok egy szabad heyet, hogy később gyorsabb legyen a számolás?

Ezt a hozzászólást AmidaBucu módosította (2008.07.19 08:46 GMT+1 óra, ---)
Ami tönkremehet, az tönkre is megy!!!
   
fpeti - Törzstag | 1280 hsz       Online status #92784   2008.07.19 08:08 GMT+1 óra  
Nálam a pos nincs mentve, a z buffer értékéből és a screenpos-ból számolja vissza.. mondjuk a colorkomponensek alapból csak 0-1 között tárolnak, az posnak nem valami jó... de jobb, ha megnézed a linken, amit írtam, mert vagy 3 hónapja csináltam, kisestek apróbb részletek
   
AmidaBucu - Tag | 281 hsz       Online status #92783   2008.07.19 08:00 GMT+1 óra  
positiont és a normalt mentsem le wvp-be forgatva, mikor deferredhez mentek?

Ezt a hozzászólást AmidaBucu módosította (2008.07.19 08:06 GMT+1 óra, ---)
Ami tönkremehet, az tönkre is megy!!!
   
fpeti - Törzstag | 1280 hsz       Online status #92782   2008.07.19 07:38 GMT+1 óra  
Idézet
newversion :
nah hát ezért maradtam a forwradrnál , mert szeretnék finom fémeket, a specularral játszani, emberi bört , nem gumiarcokat
de ha mattelgyárban játszodik a gém , no problémo



Az az igazság, a per pixel speculartól remélek sokat.. majd meglátjuk, de nem törekszem fotórealizmusra (nemigazán a valóságban játszódik majd a gém, ha lesz ), beletörne a fogam, nem akarom ezt 10 évig írni.

Idézet
Asylum :
látom nálad müködik a normal / parallax mapping mégse szolsz egy szot se



Ezen oszt' nincs parallax (még nem is írtam olyat sose), ez csak deferred normalmapping.. .
Miazhogynemmondoksemmit, amikor mindíg mondok?
   
AmidaBucu - Tag | 281 hsz       Online status #92781   2008.07.19 07:37 GMT+1 óra  
mondom, nézd mega linket amit néhány kommentel előbb raktam be, ott a stalkerről van szó és hogy hogy használja ezt a technikát. egész jól.
Ott van még valahol egy link a killzone-hoz. Ott is 4 négy rt van, és nagyon szép kis grafkot csinál.

4ggyel is lehet szépet csinálni ezek alapján. gondolom nem sok idő és szinte már minden kari joval több tr-t fog támogatni.
Ami tönkremehet, az tönkre is megy!!!
   
newversion - Tag | 197 hsz       Online status #92780   2008.07.19 07:23 GMT+1 óra  
nah hát ezért maradtam a forwradrnál , mert szeretnék finom fémeket, a specularral játszani, emberi bört , nem gumiarcokat

de ha mattelgyárban játszodik a gém , no problémo
   
Asylum - Törzstag | 5440 hsz       Online status #92779   2008.07.19 07:19 GMT+1 óra  
látom nálad müködik a normal / parallax mapping mégse szolsz egy szot se
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
fpeti - Törzstag | 1280 hsz       Online status #92778   2008.07.19 07:18 GMT+1 óra  
Az én játékom egy műanyaggyárban fog játszódni...
még van 2 üres komponens, plusz egy egész RT, majd meglátom, eddig ez van, most gémpléjre gyúrok, eddig tényleg eléggé plasztikus:

Ez csak a bumpmap, a színe még nincs is használva... hupszi.
   
newversion - Tag | 197 hsz       Online status #92776   2008.07.19 07:06 GMT+1 óra  
szin? ez mind? specular adatok ,reflection adatok, refractio,sss,fresnel
és ezeknél erösség, color adatok
   
fpeti - Törzstag | 1280 hsz       Online status #92775   2008.07.19 07:05 GMT+1 óra  
Idézet
newversion :
itt egy kis doksi a deferredröl, de engem nem mozgat meg maradok a jo öreg forwardnal

http://www.guerrilla-games.com/publications/dr_kz2_rsx_dev07.pdf



Ez tényleg nagyon jó, az alapokat én annó ebből szoptam:
http://ziggyware.com/readarticle.php?article_id=155

Esetleg:
SetRenderState(D3DRS_COLORWRITEENABLE, 0xffff);
ez kapcsolja be azt, hogy mind a 4 RT-re írjon dá shéder.
   
fpeti - Törzstag | 1280 hsz       Online status #92774   2008.07.19 07:00 GMT+1 óra  
A legfontosabb, hogy a pixel színe, pozíciója, felületi normálisa meglegyen.
A színt muszáj tárolni, a z-buffert is, valamint a normált, ami akkor 2 vagy 3 komponensű:
Nálam így van eddig:

3 rendertarget van eddig a deferred shadernek
-------------------
1. rgb+1 valami (még nemtom)
2. normal(x,y,z) + valami (ezt se)
3. 32 z buffer
-------------------
plusz van a 4 RT, amibe fényinfók mennek. (itt szembesültem azzal, hogy a lebegőpontos RT-k nem támogatják az additive-alphablendinget.pedig hdr-hez jól jött volna, mindegy.. )

Utána a deferred shaderben elő kell állítani a pixel térbeli helyzetét, a normálját, és mehet a per-pixel menet.
   
newversion - Tag | 197 hsz       Online status #92773   2008.07.19 07:00 GMT+1 óra  
itt egy kis doksi a deferredröl, de engem nem mozgat meg maradok a jo öreg forwardnal

http://www.guerrilla-games.com/publications/dr_kz2_rsx_dev07.pdf
   
AmidaBucu - Tag | 281 hsz       Online status #92772   2008.07.19 06:50 GMT+1 óra  
Jah, akkor miker mentek le, akkor szorozzak be world majd view matrixxal? vagy hogy
tegyük fel hogy van egy vektorom de még semmit se csináltam vele. Te mit csinálnál vele?

Jah amugy az előbbi linken, amit muttatam, le van irva hgy csinálj (plusz efekttel) AA-t vagy legalábbis egy fakét, és irják, hogy néha nem müködik rendesen, de gondolom ez elhanyagolható probléma. Tehát ez aa probléma is kiőve.

Ezt a hozzászólást AmidaBucu módosította (2008.07.19 06:56 GMT+1 óra, ---)
Ami tönkremehet, az tönkre is megy!!!
   
fpeti - Törzstag | 1280 hsz       Online status #92771   2008.07.19 06:49 GMT+1 óra  
Jah, a deferred shader normálos részének pont az a lényege, hogy a normálokat worldspace-be forgatja, így lehet negatív is..
Eszi a PS-t rendesen, a fények rajzolásánál meg a pixel térbeli pozícióját is esetleg vissza kell számolni (ha nincs eltárolva), szal itt is a pixelshadert cincálja.
   
newversion - Tag | 197 hsz       Online status #92770   2008.07.19 06:41 GMT+1 óra  
ha a vertes shaderben forgatod be a light meg view vectorokat a textura spacebe (inverz)
a pixel shader gyors lesz
   
AmidaBucu - Tag | 281 hsz       Online status #92769   2008.07.19 06:30 GMT+1 óra  
Jam már vágom. A z-teszt magátol elvégzi a piszkos munkát. Tehát mikor mentjük le az adatokat a dx magátol kihaggya azokat a helyeket amik htat forditanak nekünk és a mögötte lévő következő jóval számol, de mivel ezek a vektorok nem a kamera terében vannak, hanem a valós térben a z lehet ugy negatív, hogy a vektor és a -(kamera iránya) kisseb szöeg zár be mint 90fok.

De ha belenne forgatva abba a térbe, akkor ténbyleg működne. De akk a tvábbi efektek lassabbak lennének a plusz mátrix szorzások miat
Akk marad aza megoldás amit te is csináltál.

Tehát a választás. +1 szabad hely a texben, vagy gyorsabb efektek. Sztem az a +-1 elhanyagolhato ahz képest, hogy rövidebbek lesznek a shaderek
Ami tönkremehet, az tönkre is megy!!!
   
newversion - Tag | 197 hsz       Online status #92768   2008.07.19 06:27 GMT+1 óra  
textura spaceben sose lesz negativ, a normal mindig a felületböl kifele mutat
   
fpeti - Törzstag | 1280 hsz       Online status #92767   2008.07.19 06:17 GMT+1 óra  
Idézet
AmidaBucu :
Jah találtam a neten egy képletet, amivel elegendő a normálnak csak az x és y komponensét elraktározni, majd PS-ben lehet a Z-t visszafejteni
Kód:
Normal.z = sqrt(1.0f - Normal.x2 - Normal.y2)
Nos, nem vágom, hogy hgy mködhet ez a kód. Tudtommal igy csak az abszolutértékét lehetne vissaz fajteni a 3. kmponensnek v. minek hivjam.


Szerintem is, és ilyen esetekben szvsz nem valami jó:

Ezt anno én is néztem, és akkor én is cinkesnek gondoltam, mert nem jöhet ki negatív z, ami elvileg felénk mutat, a pozitív meg elfele... mondjuk így meggondolva a másik irányra nagyon sokszor nincsen szükség (amikor camera view fele néz a normál), mert az backface, így elég lehet, ekkor meg lehet az x,y-t 16 biten tárolni, nagyobb lesz a pontosság... állítólag szebb is. (nekem mind a 3 'eltárlódik'

Valaki csinált már ilyet?
   
AmidaBucu - Tag | 281 hsz       Online status #92765   2008.07.19 04:54 GMT+1 óra  
monynuk a stalker grafkoja nem ál messze a normális minőségtől...
jah és a forward rendering a "simát" jelenti? izé? és olyat lehet hogy az első körben kimentek vmennyi cuccost. A kapt eredményeket félrerekom vhova. És utána már nyomathatok, monnyuk shadowmappot?

Jah találtam a neten egy képletet, amivel elegendő a normálnak csak az x és y komponensét elraktározni, majd PS-ben lehet a Z-t visszafejteni
Kód:
Normal.z = sqrt(1.0f - Normal.x2 - Normal.y2)
Nos, nem vágom, hogy hgy mködhet ez a kód. Tudtommal igy csak az abszolutértékét lehetne vissaz fajteni a 3. kmponensnek v. minek hivjam.

Ezt a hozzászólást AmidaBucu módosította (2008.07.19 06:11 GMT+1 óra, ---)
Ami tönkremehet, az tönkre is megy!!!
   
newversion - Tag | 197 hsz       Online status #92763   2008.07.19 04:23 GMT+1 óra  
normális minöséghez 50 adat kell
és az antialias is nehézkes deferreddel
   
AmidaBucu - Tag | 281 hsz       Online status #92762   2008.07.19 04:16 GMT+1 óra  
megnéztem, és tényleg csak 4et tud a karim. És hiszek neked, az bizton nem elég sok mindenre. De találtam egy cikket, ahol a s.t.a.l.k.e.r. renderelése a téma, és szó esik a deferred shadingrol is, ahogy az is szimplán csak 4et használ. Tehát eltud raktározni 16 adatot.
GPU Gems 2
Persze lehet hogy elolvastam valamit, akkor sziggyatok le nyugodtan. ( ugyis van valami fontos amit nem vettem észre biztosan). Én hiszek newversionnak, hogy négy nem elég, de akkor valaki oszlassa el a felhőket körülöttem plz.
Ami tönkremehet, az tönkre is megy!!!
   
newversion - Tag | 197 hsz       Online status #92748   2008.07.19 01:03 GMT+1 óra  
"Amúgy a "fostömeg" megfogalmazés a deferred shader xbox támogatottságára utal? "

nem, müvészeti szempontbol vannak fenntartásaim, minden anyag müanyag, mivel nem fér el elég anyag paraméter a 4 rendertargetba
ezért irtam hogy a 8 rendertargettel má tetszik a buli, csak ahhoz hardver is kell
sokat gondolkoztam melyik legyen és maradtam a forward mellett, még akkor is ha lassabb lesz, bár nem valoszinü
   
fpeti - Törzstag | 1280 hsz       Online status #92740   2008.07.18 17:48 GMT+1 óra  
Én 7300GS-en csinálok., mint kiderült..... egy "fostömeg"-et , ha nincs nagyon sok full screen fény, akkor megvan a 60-80 fps.
Azért az nem rossz, hogy nem kell 300 shadert megírni, és annyi fényforrás lehet benne, amennyit akar az ember... csak ne álljon benne túl sokban a kamera.
Az biztos, hogy eszi a fillrate-t, valamint ennyi fénynek lehetetlen még dinamikus árnyékot is vetni, de mindennek van pro/kontrája.
Nekem eddig bejött, sok fény esetén, főleg, ha mind dinamikus, elég sokat kell számolgatni, mire kijön, melyik objektumot mely fény(ek) érik, utána ezt kirajzolni esetleg több menetben (egyben is lehet).... játéka válogatja, legtöbben nem fontos sok fény, elég egy fő, meg egy zseblámpa, osz kalács.

Nekem csak a megközelítés tetszik, hogy egyszer rajzoljuk az ojjekteket, utána a fényeket, egymásról tudniuk sem kell, mégis faszányos a vége... szvsz sokkal könnyebb megcsinálni, mint a forward rendert (sok fényre).
Valamint a drawcall count-ot lent tartja, mert mindent lehet instacolni. (ez is gémfüggő persze)

- reklám vége -

Amúgy a "fostömeg" megfogalmazés a deferred shader xbox támogatottságára utal?
   
newversion - Tag | 197 hsz       Online status #92737   2008.07.18 16:23 GMT+1 óra  
gondolom igen, de ez a deferred shading nem pont kezdöknek valo , meg amugyis egy fostömeg
az uj kártyákon má elmegy mivel 8 rendertargetet tudnak
de 4 az lof@szra se elég
   
AmidaBucu - Tag | 281 hsz       Online status #92736   2008.07.18 16:09 GMT+1 óra  
azt még hadd kérdezzem meg, hoogy ha több rendertargetet adunk meg, akkor a PS
eredményei(COLOR0, COLOR1 stbstb) maguktól kerülnek bele a rendertargetekbe különkülön?
Ami tönkremehet, az tönkre is megy!!!
   
newversion - Tag | 197 hsz       Online status #92723   2008.07.18 08:57 GMT+1 óra  
if-el azért ne probálkozz mert az kicsit lassu lesz
inkább használd a stencil buffert
   
AmidaBucu - Tag | 281 hsz       Online status #92722   2008.07.18 08:52 GMT+1 óra  
Jo, tehát amennyi cucc, annyiszor kell kirenderelni különkülön felületre, okok köszi.
Ami tönkremehet, az tönkre is megy!!!
   
newversion - Tag | 197 hsz       Online status #92721   2008.07.18 08:01 GMT+1 óra  
AmidaBucu - Tag | 281 hsz       Online status #92720   2008.07.18 07:00 GMT+1 óra  


Ja vágommá

jah, valamit szerettem volna még kérdezni.
Ha jók a guglis képeségeim, akkkor a defferred shading arra jó, hogy a teret kevesebbszer keljen kirajzolni, ugye? Akkor kettőt kérdeznék. 1., kilehet menteni egy felületre a cuccokat (normal, szin stb), egy felületre, egymás mellé?
2., ugye a proginak tudnia kéne hogy hol mien effekt kell, akk (lehet nagy lámaság) lehet olyat, hogy
Azt is képben szinekkel jelzem, hogy hol, mit kell lefuttatni? És ha ilyet lehet, hogy lehet azt megcsinálni, hogy mikor a szin alapján hiv egy shadert ne szoljon be, hogy tulléptem a 64 utasitást.

Csak azér ,mer akkor az összes lehetséges effektnek egy helyen kéne lenni, az meg baromi sok utasítás, nem lehet valahogy szét különiteni? Hogy egy if után egy include vagy mi álljon?

Ezt a hozzászólást AmidaBucu módosította (2008.07.18 07:56 GMT+1 óra, ---)
Ami tönkremehet, az tönkre is megy!!!
   
Asylum - Törzstag | 5440 hsz       Online status #92717   2008.07.18 06:16 GMT+1 óra  
javaslok rákeresni a "homogén koordináták" c szavakra
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
gaborlabor - Moderátor | 4449 hsz       Online status #92716   2008.07.18 05:41 GMT+1 óra  
AmidaBucu - Tag | 281 hsz       Online status #92714   2008.07.18 04:39 GMT+1 óra  
joj mek azonnal
de mondmeg mék akkor utolsoként a w mit tartalmaz?
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]