   Summed-Area Variance Shadow Maps
  Hey there!I don't know if anyone else here have implemented SAVSM, but if yes I need information.I have a DX10 game and had a working standard VSM for my shadows. I recently got my hands on the GPU Gems 3 DVD and though it would be great to implement SAT VSM (int format). It took me a while, but I integrated the code from the demo to my game. I finally managed to get it working "perfectly", both with and without MSAA for the shadow pass. I had lot of trouble debugging cause it seems both Pix and NvPerfHud don't seem capable of displaying INT textures. I even contacted AndyTX by e-mail, and he helped me to get it working, but did not answer for this question:I still have one problem remaining. It's not directly related to the SAT technique, but it might be. I'm using point lights with omnidirectional cubemap shadows and at the intersection of every shadow map there is a line artifact. If you don't mind the ugly test scene, you can view a screenshot there:http://img6.imageshack.us/img6/5397/cubemap.jpgAs you can see, the light is centered above the first platform and the "square" composed of lines artifact represent the "down" shadow map of the light. The diagonal lines represent the perspective view of all sides. The pixels in these lines appear lit when it's not supposed to be, and *sometimes* unlit when it's supposed to be.Since the demo only use a spotlight and hence never use the edges of the shadow map, anyone know if the SAT can gives invalid results at these edge? In my previous implementation of VSM, I encountered the exact same problem (or very alike) and fixed it by simply adding a few extra degrees to the usual (D3DX_PI * 0.5f) light projection. Unfortunately, it don't seems to work this time.I debugged invalid pixels using PIX and the relevant information I got is:-They sample the correct shadow map index.-Of course, LightTexCoord gives coordinates in the [0,1] range, but very close to extremities-Unfortunately, after filter tile size calculation, some values are slightly <0 or >1. On pixels who appear valid, this never happens.I then tried to clamp the Tile variable to [0,1], but it don't help.Next step I will look into PCSS...EDIT:I guess this could help. I took a screenshot zoomed-in on the problem.http://img12.imageshack.us/img12/154/zoome.jpgAs you can see, the part with incorrect lighting in the shadow area is about 1 texel wide (shadow map size), while the black line in the lighted area is always 1 pixel wide (render target size), no matter how close I zoom. There is also a small nearly unnoticeable shadow imperfection on the intersection.[Edited by - Dunge on April 25, 2009 2:08:27 PM]
  Sorry to bump back a 1month year old topic, but I would appreciate if somebody could help.I got a job and lost a lot of free time lately, so I hadn't touched at this project at all since. Unfortunately, I'm still stuck at the same point.I don't know why trying to sample the border of the shadow map don't work, but I guess it's normal if the sampling region wanted exceed it.When you think about it, it will also be impossible to combine two shadows textures into one sampling since, even if physically in the word the shadow maps reach an intersection, the sums are not related to each others.What would you recommend? I'm thinking about creating the shadow map just a few degrees wider, so the intersections are rendered twice in the shadow maps, but in the lookup function hopefully it will be able to sample correctly cause the sampled region won't be outside the texture. I just have to find out how to do the projection so it don't gives UV values in these borders.EDIT: Nah, nothing works.. I'm beginning to think that the problem could be something completely different and I'm just wasting my time trying to solve it this way. I really need help here.[Edited by - Dunge on May 17, 2009 12:11:31 PM];  Have you thought to a general driver issue?Can you test with a REF device?Have you tried with another adapter?It looks like the usual ATI issue on drawing complex scene, i had a lot of them that worked perfectly on a Nvidia card.Anyway, nobody can help you without showing code.   ;  Issues with values on or near texture edges screams 'filtering problems' to me.   ;  Yes I tested with the REF device, same problem.I couldn't post any source code because it's from the book DVD. Fortunately, I tried to remove the "spot attenuation" from the dvd demo, and it does have the same problem at the edge of the single shadow map. I then realized that slightly increasing the light FOV actually does fix this problem.But,.. this is only half of it. The 1-pixel wide bug is still there. It have nothing to do with SAVSM, only with my implementation of cubemap. To decide which index in my shadow map array to sample, I use this pixel shader code:float3 DirToLight = g_LightPositions[lightIndex] - input.WorldPos;int cubeMapNum = 0; // find shadow map index numberfloat maxCoord = max( abs( DirToLight.x ), max( abs( DirToLight.y ), abs( DirToLight.z ) ) );[flatten]if( maxCoord == abs( DirToLight.x ) )cubeMapNum = DirToLight.x > 0 ? 0 : 1;[flatten]if( maxCoord == abs( DirToLight.y ) )cubeMapNum = DirToLight.y > 0 ? 5 : 4;[flatten]if( maxCoord == abs( DirToLight.z ) )cubeMapNum = DirToLight.z > 0 ? 2 : 3;What's strange is if I comment it and force cubeMapNum to be only the front (2) or only the left 01) index, the "corrupt" pixel is correct in both case. But if I use this code, I get an incorrect line when two axis of DirToLight are nearly equal in value. The line also appear dashed. This scream float instability to me. When I debug using PIX, it tells me it use (2), which is because it entered both conditions. The exact same values, different results.[Edited by - Dunge on May 23, 2009 6:36:19 PM]