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]
Asylum - Törzstag | 5455 hsz       Online status #154403   2011.06.15 12:26 GMT+1 óra  
Az a baj, hogy én ebböl a modszerböl nem látom hogyan kapnál lineáris depth-et.
Én igy számolom (részlet a celshadinges tutoribol):

Kód:
float2 clipPlanes = { 0.1f, 3.0f }; // lehet kisebb is mint a valodi

void vs_main(
   in out float4 pos   : POSITION,
       in float3 norm  : NORMAL,
   in out float2 tex   : TEXCOORD0,
      out float4 normd : TEXCOORD1,
      out float3 ldir  : TEXCOORD2)
{
    pos = mul(pos, matWorld);
    normd.xyz = mul(matWorldInv, norm);
   
    ldir = lightPos.xyz - pos.xyz;
    pos = mul(pos, matView);
   
    normd.w = (pos.z - clipPlanes.x) / (clipPlanes.y - clipPlanes.x);
    pos = mul(pos, matProj);
}


A world space pos-rol meg valami olyasmit irnak, hogy a VPOS regiszterböl (screen space koord) számolod vissza. Nyilván mivel lineáris a depth a z-t könnyü kiszámolni, az xy-t pedig a viewproj mátrix inverzével beszorzod. Egy pillanat.

Ez nem tudom, hogy jol müködik-e, mert nem használtam élesben (csak teszt jelleggel):

Kód:
/**
* \brief Unproject a screen space point to world space
*/
void vectorUnproject(in out float4 pos, float2 sxy, float2 nf)
{
    matrix projInv =
    {
        1 / sxy.x,          0,  0,                               0,
                0,  1 / sxy.y,  0,                               0,
                0,          0,  0,  -(nf.y - nf.x) / (nf.x * nf.y),
                0,          0,  1,                        1 / nf.x,
    };
   
    pos = mul(projInv, pos);
    pos = mul(matViewInv, pos);
   
    pos /= pos.w;
}


sxy itt asszem a proj mátrix 11 és 22 helyen levö eleme tehát ez a tangenses/aspektes marhaság. Viszont ez a nemlineáris depth-hez van, tweakeld át
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Pretender - Törzstag | 2498 hsz       Online status #154402   2011.06.15 11:44 GMT+1 óra  
Na jó, ez most már zavar... Deferred shadingen dolgozgatok, és valahogy el szeretném érni, hogy működjön ez a szutyok lineáris depth-tel is. (megj.: position.z / position.w-ből szerzett depth esetén működik az újraszámolás, lásd : off topic)
A Gbuffer vertex shaderje: (a 30.0f a far plane, egyelőre hardcoded, ha működni fog, nyilván átírom)
Kód:
float4 wpos = mul(Position, world);
float4 vpos = mul(wpos, view);
Position = mul(vpos, proj);

Depth = vpos.z/30.0f;

Ezzel kapok egy view-space depth-et [0;1] között. Nagyon szép és jó, de ebből kellene nekem a lighting pass-ban a pixel shaderben egy world-space position.

Olyasmiket nézegettem, meg kitalálgattam, meg ilyesmi (), hogy kell egy sugár a kamerától a kamera far planejéig az adott pixelen keresztül. Ezt kell beszorozni az adott pixelnél lévő depth értékkel (ami ugye ha 1, akkor kapjuk meg azon a helyen a legnagyobb távolságot, a far plane egy adott pontját)

Rengeteg oldalt megnéztem már, de igazából egyik sem működött, szóval várom a vállalkozó szellemű emberek segítségét

   
Pretender - Törzstag | 2498 hsz       Online status #140288   2010.09.02 17:14 GMT+1 óra  
oke, never mind.

   
Pretender - Törzstag | 2498 hsz       Online status #137447   2010.07.14 20:51 GMT+1 óra  
Ertheto volt
Hat tul sok ilyen nincs. Igazabol csak Poziciot szamolok ujra vertex shaderben, azt meg ugye (majd) a billboard miatt kell.
Megnezek mar egy kodot, lehet, hogy valamit nagyon elrontok

   
Kuz - Törzstag | 4455 hsz       Online status #137444   2010.07.14 20:25 GMT+1 óra  
Fáradt vagyok, de megpróbálok értelmes mondatot kihozni ebből :
Bár nem értek a témához, de nem lehet csoportosítani bizonyos számolásokat batchenként, hogy egy bizonyos batch-hez egy valamilyen shader számolás tartozzon? Szóval, hogy egy batchen belül ne kelljen minden objektumhoz kiszámolni valamit, hanem összesen 1x legyen valami kiszámolva per batch, és azt felhasználni a többi 15 objektumhoz? Ez érthető volt?
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???

   
Pretender - Törzstag | 2498 hsz       Online status #137442   2010.07.14 19:43 GMT+1 óra  
naja, a vege lemaradt:
Kód:
Out.Position = mul(inPos, viewProj);

Mindenhol ugyan azt a viewProj matrixot hasznalom, szoval elvileg az jo

Mellesleg 4056 "fuvet" rajzolok ki instancinggel (egyenkent nyilvan 2 haromszogbol allnak), 250-es size-t engedett max. a shader, szoval 16 teljes, ill. egy 17. nem teljes "batch"-ban rajzolom ki oket. Hat, ezen a laptopon (mobility hd 2400) eleg lassu (20 fps korul van, ha ennyi "fuvet" latok egyszerre. Es akkor ezek meg nem billboardok, es nincs is rajtuk arnyalas)

   
TPG - Tag | 3402 hsz       Online status #137441   2010.07.14 19:41 GMT+1 óra  
" Output.Position = mul(finalPosition4, preViewProjection); "
Nem olvastam végig a cuccokat amiket linkeltél, csak a shader kódokat néztem (ergo igazából még mindig nem értem hogy konkrétan miért meg hogy működik ), de a fent idézett sor, vagy ahhoz hasonló volt mindkettőben. Ez nem hiányzik neked a cucc végéről, vagy ha esetleg ott van, az a mátrix tuti jól van beállítva. Mert a képeken látható torzulást ilyesfajta hiba okozhatja.
Reality is almost always wrong. - House

   
Pretender - Törzstag | 2498 hsz       Online status #137440   2010.07.14 19:34 GMT+1 óra  
Hat en ilyet talaltam kamera fele forgatasra
Itt volt. Itt meg valami hasonlo.

   
TPG - Tag | 3402 hsz       Online status #137439   2010.07.14 19:13 GMT+1 óra  
Az az utolsó két sor, az mi a rossebet is csinál? Lehet benne van a hiba de nem akar leesni.
Reality is almost always wrong. - House

   
Pretender - Törzstag | 2498 hsz       Online status #137435   2010.07.14 12:35 GMT+1 óra  
Ez a billboard dolog nem adja magat:
Kód:
float3 instancePosition = positions[In.Instance];
float4 inPos = float4(In.Position.xyz + instancePosition, 1);

float3 eyeVector = viewProj._m02_m12_m22;

float3 right = normalize(cross(eyeVector, billboardAxis));
float3 up = normalize(cross(right, eyeVector));

inPos.xyz += (In.TexCoord.x - 0.5f) * right;
inPos.xyz += (0.5f - In.TexCoord.y) * up;

Egyik iranybol nezve:
Masik iranybol nezve:
Szoval igy valtozik a szelessege. Hol rossz? (korulneztem neten, kb. mindenhol igy csinaljak)

   
Pretender - Törzstag | 2498 hsz       Online status #137405   2010.07.13 19:00 GMT+1 óra  
Talan nem tokeletesen ide illo, de: Melyiket csinalnatok inkabb?
amit en lattam instancingos cuccot, ott ugy csinalta, hogy:
Kód:
float4 InstanceData[200] : BOXINSTANCEARRAYDATA : register(c16);

//application to vertex structure
struct a2v
{
    float4 position   : POSITION0;
    float3 normal   : NORMAL;
    float2 tex0       : TEXCOORD0;   
    float instance    : TEXCOORD1;
};
void vs( in a2v IN, out v2p OUT )
{       
float4 data = InstanceData[ IN.instance ];
float4 instancePos = IN.position;
instancePos.x += data.x;
instancePos.y += data.y;
instancePos.z += data.z;
//....
};

Azon gondolkoztam, hogy nem jobb-e ugy, hogy szinten a Vertex shader inputkent megkap egy float3-mat, ami a poziciot jelkepezi (ami ugye instancenkent mas). Vagy az igy nem jarhato ut, esetleg lassabb...?

   
Seeting - Törzstag | 2306 hsz       Online status #130769   2010.04.10 17:20 GMT+1 óra  
Milyen tutorialt ajánlotok a post process effectek könnyed elsajátításához? (OpenGL-ben)

Itt egész jók vannak, de ezek csak demók magyarázat nélkül:

http://encelo.netsons.org/programming/opengl
   
Eldor - Tag | 163 hsz       Online status #130759   2010.04.10 13:47 GMT+1 óra  
Innet leszedhetitek: www.theprecursor.atw.hu/tpge.tar.gz
A program jelenleg csak Linuxon futtathato. (SDL shared objectek kellenek hozza)

   
Eldor - Tag | 163 hsz       Online status #130758   2010.04.10 13:38 GMT+1 óra  
De ha a kameraval mozog a feny, akkor a diffuse resze miert mukodik tokeletesen? Akkor annak is teljesen mas kepet kene adnia, ha elfordulok a kameraval. Vagy rosszul gondolkodom?

   
Asylum - Törzstag | 5455 hsz       Online status #130751   2010.04.10 11:54 GMT+1 óra  
A reflektált vektort a fragment shaderben szokás kiszámolni. Sőt igazából nem is szokás, helyette a félvektort szokták kiszámolni (normalize(lightdir + viewdir)) aztán ennek a dotja a normállal adja meg a specular-t.
Viszont mint már említettem ha view spaceben végzed ezt az egészet, akkor naná hogy a kameráddal együtt mozog...
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Eldor - Tag | 163 hsz       Online status #130750   2010.04.10 11:11 GMT+1 óra  
Egyebkent a "varying vec3 half_vector1"-et valojaban "varying vec3 reflected_vector1;"-nek kene hivni. Csak valahogy ez maradt benne a programban (probalkoztam half vectoros megoldassal is, az is ugyanezt a hibat produkalta).

   
Eldor - Tag | 163 hsz       Online status #130748   2010.04.10 10:52 GMT+1 óra  
Elvileg a fenyen is vegrehajtodik ugyanaz a transzformacio. Mashol is megkerdeztem es azt mondtak, hogyha meghivom a glLightfv(...,GL_POSITION,...) fuggvenyt, akkor beszorzodik a gl_LightSource[x].position a gl_ModelViewMatrix-al. Igy gyakorlatilag a fenyt is objektumkoordinatakent adom meg, ami transzformalodik szemkoordinatava.
Egyebkent sem hiszem, hogy ez lehet a problema, mivel a diffuse vilagitasnal is felhasznalom ezt az erteket es ott tokeletesen mukodik.

   
Matzi - Szerkesztő | 2521 hsz       Online status #130747   2010.04.10 10:39 GMT+1 óra  
Eldor:
Ha a fényed a világ térben van megadva, akkor a vertexedet miért a nézeti térbe transzformálva vonod ki belőle? (gl_ModelViewMatrix)
Kód:
position=vec3(gl_ModelViewMatrix*gl_Vertex);

vertex_to_light_vector1=gl_LightSource[1].positio​n.xyz-position;

Nem értek a GLSLhez, de ez azért szemet szúrt. Persze ha nem ez a gond, akkor bocs.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
Eldor - Tag | 163 hsz       Online status #130746   2010.04.10 10:18 GMT+1 óra  
Már más fórumon is feltettem a kérdést, de ott nem nagyon akarnak foglalkozni vele, vagy nem tudnak rá válaszolni. Remélem, hogy tudtok segíteni.

Írtam egy egyszerű shadert GLSL-ben, ami egy diffuse és egy Phong féle specular fényt használ. Teljesen magam írtam bele mindent. A diffuse shader része tökéletesen működik, sajnos a specular produkál furcsa hibákat. Például függ attól, hogy merre nézek, pedig elvileg csak a pozíciómtól kéne függenie.

Vertex shader
Kód:
smooth varying vec3 normal;
smooth varying vec3 vertex_to_light_vector1;
varying vec3 half_vector1;

smooth varying vec3 position;

const vec3 BLACK=vec3(0.0,0.0,0.0);

void main()
{
vec3 normalized_normal;
normal=gl_NormalMatrix*gl_Normal;
normalized_normal=normalize(normal);

position=vec3(gl_ModelViewMatrix*gl_Vertex);

vertex_to_light_vector1=gl_LightSource[1].positio​n.xyz-position;
half_vector1=reflect(vertex_to_light_vector1,normalized_normal);

gl_Position=gl_ModelViewProjectionMatrix*gl_Verte​x;
}


Fragment shader
Kód:
smooth varying vec3 normal;
smooth varying vec3 vertex_to_light_vector1;
varying vec3 half_vector1;

smooth varying vec3 position;

const vec3 BLACK=vec3(0.0,0.0,0.0);

void main()
{
float tmp_alpha;
vec3 normalized_normal;
vec4 frag_color=vec4(0.0,0.0,0.0,0.0);

tmp_alpha=gl_FrontMaterial.ambient[3];

float intensity1=0.0;
vec3 normalized_vertex_to_light_vector1;
vec3 normalized_light_direction1;
vec3 normalized_reflected_light_vector1;
float specular_intensity1;

normalized_normal=normalize(normal);
normalized_reflected_light_vector1=normalize(half_vector1);

normalized_vertex_to_light_vector1=normalize(vertex_to_light_vector1);

specular_intensity1=pow(max(dot(normalize(position),normalize(normalized_reflected_light_vector1)),0.0),gl_FrontMaterial.shininess);

intensity1=dot(normalized_vertex_to_light_vector1,normalized_nor​mal);

frag_color+=gl_FrontMaterial.diffuse*(gl_LightSource[1].ambient)*intensity1+specular_intensity1*gl_LightSource[1].ambient;

gl_FragColor=vec4(frag_color[0],frag_color[1],frag_color[2],tmp_alp​ha)+gl_FrontMaterial.emission;
}


Ráadásképp ebben a sorban szerintem elvi hibás is, mivel nem normalize(position) kellene bele, hanem normalize(-position), mégis így működik többé kevésné jól a dolog: specular_intensity1=pow(max(dot(normalize(position),normalize(normalized_reflected_light_vector1)),0.0),gl_FrontMaterial.shininess);

A C forráskódomban a beállítások:
Kód:
glMaterialfv(GL_FRONT,GL_DIFFUSE,(float[]){0.001,1,0.001,1});//material color
glMaterialfv(GL_FRONT,GL_EMISSION,(float[]){0,0,0,0});
glMaterialf(GL_FRONT,GL_SHININESS,64);

glLightfv(GL_LIGHT1,GL_AMBIENT,(float[]){1,1,1,0});//light color
glLightfv(GL_LIGHT1,GL_POSITION,(float[]){0,0,15,1});//light position

Tudja valaki, hogy mi a hiba benne?

   
Eldor - Tag | 163 hsz       Online status #130615   2010.04.07 23:02 GMT+1 óra  
Nagy nehezen, de azt hiszem, leesett. Köszönöm.

   
Asylum - Törzstag | 5455 hsz       Online status #130614   2010.04.07 22:58 GMT+1 óra  
A view spacebe való transzformálással azt éred el, hogy a fény a kamerához képest végig ugyanott lesz (pl. elemlámpa).

A fény meg nem "tolódik el"...a kamera forog el, a fény az a helyén marad, world spaceben.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Eldor - Tag | 163 hsz       Online status #130613   2010.04.07 22:56 GMT+1 óra  
Bocs lehet, hogy picit fogalomzavarban vagyok.
Ha jól tudom, akkor a view space-ben úgy vannak a dolgok, mintha a kamera az origóban lenne és -z felé nézne. Kérlek, javíts ki, ha rosszul tudom.
Ha glLightfv(GL_LIGHTx,GL_POSITION,vec)-el megadjuk a fény helyét és utána elforgatjuk a kamerát, akkor a fény pozíciója is változik a kamerához képest. Ezért gondoltam úgy, hogy transzformálódik.

   
Asylum - Törzstag | 5455 hsz       Online status #130608   2010.04.07 22:46 GMT+1 óra  
Fényeket mióta transzformálunk view spacebe?
Amit shader paraméterként kapsz az mindig interpolálódik a vertexek között.
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Eldor - Tag | 163 hsz       Online status #130605   2010.04.07 22:22 GMT+1 óra  
GLSL-ben azt tapasztaltam, hogy minden gl_LightSource.position transzformálódik anélkül, hogy én azt megszoroztam volna a gl_ModelViewMatrix-al. Ugyebár a gl_LightSource struktúrák mind a vertex és mind a fragment shaderben használhatóak. A kérdésem az, hogy interpolálódnak-e a fragment shaderben a fényforrások pozíciói. Valamint, hogy van-e másik olyan beépített változó, amivel a GLSL magától végez el valamilyen műveletet, és ha igen akkor milyet. GLSL specifikációban nem találtam semmi ilyesmire utaló részt, de az is lehet, hogy csak nem voltam elég alapos.

   
dvorgaz - Törzstag | 575 hsz       Online status #130429   2010.04.05 20:17 GMT+1 óra  
Idézet
Matzi :
le kellene osztani a pos.w-vel



Áh, kösz; ez volt a megoldás
   
Matzi - Szerkesztő | 2521 hsz       Online status #130428   2010.04.05 20:11 GMT+1 óra  
Most így látatlanban két vad tippem van, az egyik, hogy a pixelshadernél a koordináták közül ki kéne írni, hogy csak az xy-t kell használni, a másik, hogy a vertex shaderben le kellene osztani a pos.w-vel, az ugyanis lehet, hogy 1-nél nagyobb.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
dvorgaz - Törzstag | 575 hsz       Online status #130426   2010.04.05 19:51 GMT+1 óra  
Lenne egy olyan problémám, hogy van egy depthmap-em, ami akkora felbontású, mint a backbuffer. Van pár billboard, amire textúraként a depthmap ottani részét szeretném ráhúzni, szóval az árnyalt pixel képernyő koordinátája alapján kéne a depthmap-ből mintavételezni, viszont valamiért nem jó:

Kód:
VSOut nnTexturedVS( VSIn input)
{
VSOut Output = (VSOut)0;
   
float4 pos = mul(input.Position, WorldViewProjection);

Output.Position = pos;

Output.ScreenPos.x = (pos.x / 2.0f) + 0.5f;
Output.ScreenPos.y = (pos.y / 2.0f) + 0.5f;
Output.ScreenPos.y = 1 - Output.ScreenPos.y;

Output.TextureCoords = input.TextureCoords;
   
return Output;   
}

float4 nnTexturedPS(VSOut PSIn):COLOR
{
float4 d = tex2D(DepthTextureSampler, PSIn.ScreenPos);

color = d
color.a = 1.0f;

return color;
}


ezmiérnemjóez

Úgy tudom a WorldViewProjection trafó után, ami látszik a képernyőn, annak -1 és 1 közti koordinátájúnak kéne lennie, ezért lett átalakítva, hogy 0 -1 közti legyen így lehessen textúrát mintavételezni vele, viszont szemmel láthatóan szar. Mit rontottam el?
   
fpeti - Törzstag | 1291 hsz       Online status #125563   2010.01.04 15:09 GMT+1 óra  
Deferred shader-nél normál tárolására sok módszert:
http://aras-p.info/texts/CompactNormalStorage.html
   
screat - Tag | 382 hsz       Online status #118737   2009.10.07 10:28 GMT+1 óra  
persze... azért van ott a kód mellékelve, mert ötletem sincs, hogy mi baja lehet...a texture a surface release, aztán reload, csak amikor a load jönne, akkor valamiért nem csinálja a textúrát. Olyan, mintha még be lenne állítva rendertargetnek.
load előtt, és unload végén (azthiszem) van egy game->GetDevice()->SetRenderTarget(0, NULL);
ennél többet nem tehetek, és mégis elszáll...

szerk.:
sipalee-é a csoki.
Nagyon amatőr voltam: GetRenderTarget(id, &surface) volt.
Amikor device reset volt, és azután hívódik meg ez, akkor a 0. rendertarget bizony üres.

Ezt a hozzászólást screat módosította (2009.10.07 12:06 GMT+1 óra, ---)
még csak padawan...
Dont worry, be hippy - Fanni :)
   
Asylum - Törzstag | 5455 hsz       Online status #118735   2009.10.07 10:03 GMT+1 óra  
rendertargeteket ugye releaseled és ujrakreálod?
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
screat - Tag | 382 hsz       Online status #118731   2009.10.07 08:23 GMT+1 óra  
Na, ha már deferred shadingnél tartottunk... Akadt egy "kis" problémám. Ha device lostot idézek elő, akkor a resetkor összehányja magát, és elszáll. Mindez nem történik meg, ha egy rendertargetet sem setelek be.
Aki rájön, az kap egy csokit!
1403-pack.zip
még csak padawan...
Dont worry, be hippy - Fanni :)
   
screat - Tag | 382 hsz       Online status #118725   2009.10.07 07:04 GMT+1 óra  
Ja, vagy végre sikerül jól megcsinálni azt az átkozott deferred shadinget. Tengnap nézegettem videókat, elég szép tud lenni...
még csak padawan...
Dont worry, be hippy - Fanni :)
   
sirpalee - Tag | 1282 hsz       Online status #118724   2009.10.07 07:02 GMT+1 óra  
Szvsz egy normal map bőven elég lesz. Úgysincs időd szerteszét optimizálni, a többi meg nagyon számításigényes. Az u3.0 is főleg normal mapekkel operál és bőven szép.
raytraceisten és übermedic
   
screat - Tag | 382 hsz       Online status #118723   2009.10.07 06:56 GMT+1 óra  
dx9re kéne egy jó kis mapping, de nekem még egy jó normal mapping is elég lenne, csak eddig valahogy sose olyan lett, mint amilyennek kéne.
még csak padawan...
Dont worry, be hippy - Fanni :)
   
sirpalee - Tag | 1282 hsz       Online status #118722   2009.10.07 06:51 GMT+1 óra  
Akkor pontatlan dolgokat írt, mert nem az összes dx9-es egységben van tessalator (n-patch felosztó). Persze lehet még csak a rad 9xxx széria idején írta.

Vagy pedig a R2VB funkcionalitásról volt szó. De a klasszikus hardveres tessalator egység az x1xxx szériában már nem volt benne.
raytraceisten és übermedic
   
Matzi - Szerkesztő | 2521 hsz       Online status #118721   2009.10.07 06:45 GMT+1 óra  
Ati kártyákon megy dx9 alatt is a tessellation. Egy munkatársam ebből diplomázott.
If your game idea starts with the story it’s not a game idea.
Stories in games are optional.
   
sirpalee - Tag | 1282 hsz       Online status #118720   2009.10.07 06:42 GMT+1 óra  
DX9, DX10 v DX11?
raytraceisten és übermedic
   
screat - Tag | 382 hsz       Online status #118719   2009.10.07 06:39 GMT+1 óra  
Nem mondtam, h csinálok, csak, hogy akarok!
Ha nem lenne elég a normal map, akkor melyiket lenne érdemes? relief? displacement? parallax?...
még csak padawan...
Dont worry, be hippy - Fanni :)
   
sirpalee - Tag | 1282 hsz       Online status #118718   2009.10.07 06:30 GMT+1 óra  
Ez DX10-es technika. Vagy geoshadert használ, vagy tessalationt. (amit geoshaderrel generál )

Ah most olvasom kommentekbe, hogy instanced tessalation. DX9-en is mehet akkor, de felejtős
raytraceisten és übermedic
   
Asylum - Törzstag | 5455 hsz       Online status #118715   2009.10.07 06:07 GMT+1 óra  
Elvileg dx9 alatt is megy. Hajrá, ülj neki (én már a parallax occlusionnál elvéreztem)
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
screat - Tag | 382 hsz       Online status #118714   2009.10.07 06:02 GMT+1 óra  
még csak padawan...
Dont worry, be hippy - Fanni :)
   
sirpalee - Tag | 1282 hsz       Online status #118705   2009.10.07 01:54 GMT+1 óra  
A bump megegyezik az úgynevezett height mappal. Max alatt valószínűleg ő samplezte is a közeli pixeleket és ez alapján sötétítette, világosította őket. Vagy pedig lekérdezett pár pontot, és arra illesztett egy planet és annak a normaljaval számolt. Bonyolultabb esetben lehet raymarcholni a height mapot (relief mapping), az szép eredményt ad, míg nem túl éles szögből nézzük a felületet (ilyenkor szétesik, tele lesz artifactoc-kal, és hogy ezeket megszüntessük, így nagyon növelni kell a lépések számát, amiatt mégjobban pixel shader intenzív lesz). Viszont lehet benne self shadowing stb.

Valvénak van egy ssbump nevű technológiája, ami elég jól tud kinézni, viszont szükség van hozzá egy precalc textúrára. Itt lehet róla olvasni bővebben : http://www.valvesoftware.com/publications/2007/SIGGRAPH2007_EfficientSelfShadowedRadiosityNormalMapping.pdf

Defferred shadinges megoldásokban meg általában view space történik a számítás... Ha meg van tessalator egység a kártyában, akkor meg már lehet displacement mappinggal is foglalkozni (geo shader nagyon gyönge ilyen célra), az nagyon szép eredményt tud adni. Persze még lehet szórakozni REYES-el is, de az már más téma .
raytraceisten és übermedic
   
TPG - Tag | 3402 hsz       Online status #118699   2009.10.06 16:19 GMT+1 óra  
Idézet
2SD :
köszönöm a gyors választ, de arra nem mondtatok semmit, hogy a bumpnak miért elég a fekete-fehér, a normalnak meg miért kell ilyen sok színből állnia. [hellyel-közzel értem egyébként, amit leírtatok, de túlzás lenne azt mondani, hogy az egészet - pöppet alacsonyabb szinten játszom egyelőre..]


A bump map egy magassági térkép, annyit jelöl hogy az adott pixel milyen messze van az eredeti helyétől. A normal map ezzel szemben azt jelöli hogy az adott pont normálja merre néz (ezért színes, a normál vektor egy 3D-s vektor 3 komponenssel). Bump-ból lehet normált generálni, a különbség a kettő közt a működés, meg a matek ami ahhoz kell hogy működésre bírják.
Reality is almost always wrong. - House

   
Asylum - Törzstag | 5455 hsz       Online status #118697   2009.10.06 16:08 GMT+1 óra  
Akkor az inkább specular vagy gloss map volt nem?
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
2SD - Tag | 463 hsz       Online status #118696   2009.10.06 16:07 GMT+1 óra  
Idézet
Archenemy :
"A bump map lényegében annyit csinált, hogy a mélyebben lévö részeket sötétebben rajzolta ki, még ilyen "fake" térhatást sem keltett mint a normal map"

Hát, nemtom. Maxban keltett.


Tényleg, ezt akartam én is írni. Anno Q3 ba is elég jól nézett ki, akkoriban meg szerintem még nem nagyon volt normal map - legalábbis használva biztosan nem.
C4Ninja
   
Archenemy - Törzstag | 625 hsz       Online status #118695   2009.10.06 16:03 GMT+1 óra  
Ez számomra is rejtély, tekintve, hogy bump mapból lehet normalt generálni, van rá valami PS plugin.

"A bump map lényegében annyit csinált, hogy a mélyebben lévö részeket sötétebben rajzolta ki, még ilyen "fake" térhatást sem keltett mint a normal map"

Hát, nemtom. Maxban keltett.
------------------------------------
Army of Pixels @ facebook
------------------------------------
A világon a legjobban az ész van elosztva: mindenki meg van róla győződve, hogy neki több jutott.
   
2SD - Tag | 463 hsz       Online status #118694   2009.10.06 15:58 GMT+1 óra  
köszönöm a gyors választ, de arra nem mondtatok semmit, hogy a bumpnak miért elég a fekete-fehér, a normalnak meg miért kell ilyen sok színből állnia. [hellyel-közzel értem egyébként, amit leírtatok, de túlzás lenne azt mondani, hogy az egészet - pöppet alacsonyabb szinten játszom egyelőre..]
C4Ninja
   
Asylum - Törzstag | 5455 hsz       Online status #118693   2009.10.06 15:31 GMT+1 óra  
Kicsit megspékelve: A lenti textura valoszinüleg egy egyoldalas falról lett megcsinálva, az ottani world space beli normálok alapján (tipikusan mintha a z tengelyen elöre nézne).
Viszont nekem ugyebár kockám van, és például annak a bal oldalára baromira nem lenne jó egy z irányú normál, hiszen az bal oldalon többnyire -x irányu.
Ezért kell mindent áttranszformálni ebbe az egyetlen textúra/tangens térbe (ami vicces módon vertexenként más).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
sirpalee - Tag | 1282 hsz       Online status #118690   2009.10.06 15:13 GMT+1 óra  
A bump map ténylegesen fekete fehér, ami itt látszódik az normal map.

Úgy kell elképzelni, hogy a felületen van egy koordinátarendszered (ún tangent space), ahol a Z merőleges a felületre, az x a tangens és az y a binormal irányába néz (vagy fordítva). És a normal mapen a 128, 128, 128 a 0,0,0 pont. Azaz, ha van 128, 128, 256 az pont felfelé néz (tehát a normal map nincs hatással). Emiatt van, hogy * 2 - 1-el be kell szorozni, mert így kapod meg a tényleges normal vektort. (alapban 1.0 - 0.0 között van az érték, de neked 1.0 és -1.0 között kell, és emiatt kell ez az extra szorzás).
raytraceisten és übermedic
   
Asylum - Törzstag | 5455 hsz       Online status #118689   2009.10.06 15:13 GMT+1 óra  
A bump map lényegében annyit csinált, hogy a mélyebben lévö részeket sötétebben rajzolta ki, még ilyen "fake" térhatást sem keltett mint a normal map.
Ez utóbbi meg azért ilyen sok szinü mert egy high poly modell külöbnözö irányu normáljai vannak benne (tömöritve a 0...1 tartományba).
C++ fordítóval és macival alszom
http://darthasylum.blog.hu/
   
Frissebbek | Korábbi postok
[1] [2] > 3 < [4] [5] [6] [7] [8] [9] [10] [15] [20] [22]