Hi, I have implemented PSVSM (parallel split + variance shadow map). I have one little issue, with some shadow corruption occuring depending on the position of the camera. What is strange is that the issue doesn't appear if I don't blur the shadow map. Have a look at these two screen shots, the problem appear on the foreground in the second screenshot (blur kernel width = 6) : no blur blur I am using the same blur shader that the VSM author published in GPU Gems. I have also checked my sampler states (tried clamp, wrap, mirror) but it didn't have an influence. Please note the projection matrix is expanded in order to blur correctly. So I am a bit lost, any feedback would really help me.

I am scaling the blur filter kernel size according to the area covered by each tile.

However, the problem occurs in a single slice. See the colors, red being the first tile, green the second, blue the third, etc...

Quote:Please note the projection matrix is expanded

what do you mean with this?

looks to me as if the normal of this triangle in your terrain is flipped and therefore not lit or something.

Hi,

First thanks for having taken some time answering my thread; Andy, I am going to continue on gamedev, as it seems there are more people here (and the guy I was secretely trying to get involved answered on both fora ;)

OK, first, wolf, by expanding my projection matrix i mean expand the clip region covered in order to have a correct blurring at the edges, as suggested by Andy in his chapter.

Then, the colors indicate which split is currently used, red being the first one. So the problem is not related to any slice boundary change.

I think I have found the problem. It is due to the fact that my Z-Far was set using the frustum points only; I thought, i don't need to render objects that are not in the view frustum, and not between light and frustum. However, this is why the blur then fails. The rendered area is being blurred with a part of the shadow map that hasn't been rendered into (I guess).



See the drawing above. Initially I was setting the Z-Far plane using the frustum points only.

I use a directional light. What I do now to create the matrices:
- first put light position in frustum center.
- with all frustum points and caster bounding boxes visible (in frustum or with sweep test along light direction), project on this axis, get min and max Zlight
- move the light backward (using ZMinLight computed at previous step) to set the light at the right position, to make sure all object will be rendered
- then compute projection matrix and crop matrix

In the first method (the one that has shown the issue), I was using far plane number 1 on drawing. So some region (near the near plane of the camera frustum in the drawing) were blurred with (0,0) (texels not being rendered) producing wrong result. I this theory possible ?

However, in my configuration where I have one big low-res terrain mesh, I get huge ZFar and ZNear values (when computing dot product between bounding box and light pos/dir). In the example, I would get plane 2 as Z Far (in my scene, ZFar can be 44000.0 with this method; same problem with ZNear).

Right now I am clamping my values to some constant, to reduce the ZFar-Znear range. Otherwise precision would be very bad. However this is a bit of a hack.

A solution would be to decompose the big mesh into smaller chuncks.

Do you see any other solution available ?



Another problem I now have is this. Look at the screen shot below, I am using SH to render the scene, and get some issue with shadow boundaries, as I don't use NDotL but rather a SH representation of the sky. Using NDotL would reduce in a too dark scene...

See the red arrows (only first texture slice is debug-displayed):




First, I don't understand why I get a hard shadow on the tail of the aircraft ? I know theorically the tail should be all dark, because the sun is from the other side. But because of the SH lighting I have no way of differentiating ambient and diffuse lighting. I simply compute the SH light factor, and scale it according the shadow result.
If I scale using NDotL, the shadows are nice, but the scene gets too dark (because ground NDotL is nearly 0, so ground gets black). Is there a solution to my problem ?

Thanks a lot guys for your help, I appreciate. And to be honnest I am quite happy to get help from 2 famous guys ;)

Once I have solved this, I have 1-2 other questions for you Andy regarding the article... going to bother you ;)

PS: if you want to see some source code just ask..

[Edited by - gjaegy on February 8, 2008 3:01:13 AM]

Hi Andy,

Thanks a lot for your answer. I am on the way solving the blur issue properly.

Concerning the NDotL issue, I am not sure to model the sun light as a simple directional light. This would remove any indirect lighting effect produced by light bounces.
An option would be to create two SH light sources, splitting the original one into two one (ambient and diffuse). This would keep the benefit of SH concerning indirect lighting, but would require some additional VS instructions ;(
I will have a try.

One question on another subject, as to be honnest I am not sure about this, what happens if fDepth is < 0 ? From what I have seen it seems to work, but as your mathematic background is better as mine, your point of view would interest me. I could of course avoid this situation, if negative distance work, the source code remains simpler...

Another question I have, in the book the following snippet, found on the CD, is different. To be honnest I know it works, but as I am a bit curious, I would like to understand why you commented out the last part of the function. To be honnest I didn't understand the

float2 ComputeMoments(float Depth){    // Compute first few moments of depth    float2 Moments;    Moments.x = Depth;    Moments.y = Depth * Depth;        // Ajust the variance distribution to include the whole pixel if requested    // NOTE: Disabled right now as a min variance clamp takes care of all problems    // and doesn't risk screwy hardware derivatives.    //float dx = ddx(Depth);    //float dy = ddy(Depth);    //float Delta = 0.25 * (dx*dx + dy*dy);    // Perhaps clamp maximum Delta here    //Moments.y += Delta;    return Moments;}

And I forgot to say: your algo simply rocks. I now use a 4 x 1024 x 1024 texture array, using geometry instancing and the GS to render to the 4 slices in one pass, without any warping technique. An the result is much more realistic and actually good-looking as with my previous method (CSM with 4 slices, all packed into one big 4k x 4k shadow map texture, using a modified TSM warping method). The old method looked nice, but the texture needed to be 4x bigger (2x2) to get a decent result (for a 2000m / 3000m shadowed area) !