• Advertisement
Sign in to follow this  

shadow mapping

This topic is 4426 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, When building the shadow map are you suppose to just write the distance from the light source to the pixel, for each pixel? In vertex shader: out.depth = distance(lightPos, vertex); In pixel shader: return interpolated depth; Is that the basic idea? This way each pixel in the shadow map stores the pixel depth from the light source.

Share this post


Link to post
Share on other sites
Advertisement
There are lots of SM implementations kicking around, so it's possible something like that works - but it's not what my current prototype code is doing [smile]

I configure the view/projection to be equivalent to that of the light and transform the vertex as normal. I then send the resultant 'Z'/'Depth' component on to the pixel shader for interpolation and output.

There are a couple of articles on this website that have example code. Might be worth a look. Soft-Edged Shadows is one that I've been using a lot.

hth
Jack

Share this post


Link to post
Share on other sites
Relevant fragment from the aforementioned article:

// Shadow generation vertex shader
struct VSOUTPUT_SHADOW
{
float4 vPosition : POSITION;
float fDepth : TEXCOORD0;
};

VSOUTPUT_SHADOW VS_Shadow( float4 inPosition : POSITION )
{
// Output struct
VSOUTPUT_SHADOW OUT = (VSOUTPUT_SHADOW)0;
// Output the transformed position
OUT.vPosition = mul( inPosition, g_matLightViewProj );
// Output the scene depth
OUT.fDepth = OUT.vPosition.z;
return OUT;
}

float4 PS_Shadow( VSOUTPUT_SHADOW IN ) : COLOR0
{
// Output the scene depth
return float4( IN.fDepth, IN.fDepth, IN.fDepth, 1.0f );
}


hth
Jack

Share this post


Link to post
Share on other sites
Thanks. I have another question. What do you do when the projective texture coordinates go outside the [0, 1] range, which happens when an object is outside the light's frustum? Do you use a transparent color border?

Share this post


Link to post
Share on other sites
Also, can shadow maps handle directional lights? Do you just use an orthographic projection matrix? What if you want shadows on an outdoor scene, where the directional light comes from the sun? Wouldn't the light frustum be huge? Is that okay?

Share this post


Link to post
Share on other sites
For directional lights I guess orthographic projection should do the trick. The light´s frustum would be huge for outdoor areas, that´s correct. But that would mean you would have to send loads of geometry to the GPU for calculating the shadow map that you won´t see in the final render. You should try to size the light´s frustum down so it just encompasses the camera frustum in order to avoid processing invisible geometry.

I have one question concerning that code sample posted by Jolly Jeffers:
Why is fDepth needed? It is just the same as OUT.vPosition.z? So the pixel shader should be able to build the output vector using that instead of fDepth.

Share this post


Link to post
Share on other sites
Quote:
Original post by matches81
I have one question concerning that code sample posted by Jolly Jeffers:
Why is fDepth needed? It is just the same as OUT.vPosition.z? So the pixel shader should be able to build the output vector using that instead of fDepth.

I'm not 100% sure as I didn't actually create that code - it's just copy-n-pasted from the article I linked to [smile]

I would imagine they should be functionally the same - it's just whether there is some issue with re-using what is effectively the depth buffer contents in the pixel shader. I've not had a chance to test such things extensively, but I've read enough posts on DIRECTXDEV about staying well-clear of the heirarchical-Z and fast-z-reject algorithms if you want decent performance.

Cheers,
Jack

Share this post


Link to post
Share on other sites
Quote:
Original post by matches81
I have one question concerning that code sample posted by Jolly Jeffers:
Why is fDepth needed? It is just the same as OUT.vPosition.z? So the pixel shader should be able to build the output vector using that instead of fDepth.

Yup, it's not needed. But I put it in there just to make things clear as to how the z-depth is acquired from the transformed position.

Share this post


Link to post
Share on other sites
Quote:
Original post by matches81
I have one question concerning that code sample posted by Jolly Jeffers:
Why is fDepth needed? It is just the same as OUT.vPosition.z? So the pixel shader should be able to build the output vector using that instead of fDepth.


Pixel shader versions up to SM2 (I'm not sure about SM3) cannot read the IN.Position value. It must be provided in another form, "like" a tex-coord.

Share this post


Link to post
Share on other sites
@sirob:
I don´t know for sure, but at least on my machine EffectEdit doesn´t give any errors when I access the IN.Position value, whether I use ps_1_1, ps_2_0 or ps_3_0. Seems to work just fine for me...

Share this post


Link to post
Share on other sites
Apart from crashing a lot when I do it, NVidia's FX Composer gets a compilation error when I access the position of a pixel. I've tested it in PS1.1 and 2.0 (1.4 and 3.0 cause a crash consistently).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement