Hi,
I am using hardware shadow mapping to create shadows in a scene and I would like to blur the depth texture used as the shadow map. I am creating multiple shadow maps per frame so I need to blur them quickly (i.e., not copy them to memory and blur them myself). Anyone have any ideas?
Thanks in advance,
Michael Sechrest
You cannot blur these maps.
You need to filter them post depth r test. If you blur them you get a useless depth value.
Filtering these maps correctly requires multiple texel samples tested against r then texture filtered, in hardware during fragment generation. Setting a bilinear texture filter will do this, but it’s just a bilinear filter of a discrete result. It will still alias.
Speaking of which, I’m really looking forward to where hardware will be able to do the quad-lookup post-shading interpolation for smoothed shadow buffer edges.
I suppose you sort-of get it now if you turn on FSAA 
AA is not the same as I’m sure you realize, the filter must change with the scale of the texels. You get it by turning on GL_LINEAR filters on the depth texture. That is what I described in my post.
I dunno if GF3 supports it (I thought it did) but I’m used to implementing depth texture shadows on systems which do support the multiple tap post test filtering.
[This message has been edited by dorbie (edited 06-06-2002).]
Dorbie,
Yes, anti-aliasing is only the same if depth buffer texture texels are as big as screen pixels, which is unlikely in the general case.
Your explanation about using a bilinear filtering on the depth texture appears ambiguous to me. What it appears to say to me is that a bilinear filter will filter the texel (depth) values, just like blurring would do, which is useless, but your comment appears to indicate that you’re saying the hardware does the right thing, which is filtering post-depth-test.
Ie, this is what I think the hardware does with linear filtering, and what I read into your comment:
4 Texels --> 4-to-1 Filtering --> 1 light coverage test --> 1 color generation
This is what I want the hardware to do:
4 Texels --> 4 light coverage tests --> 4 color generations --> 4-to-1 Filtering
However, reading the spec more closely, it says that “This extension defines two new operations to be performed on texture values before they are passed on to the filtering subsystem” which indeed seems to indicate that the latter pipe is what happens, and I now have the appropriate context to unambiguously parse your statement.
I’d hoped to avoid ambiguity. In my first post I said that filtering must occur AFTER the test against R, that is the shadow test. When I then say bilinear filter of a discrete result, the discrete result is the shadow test.
I closed my second post talking about hardware support for “multiple tap post test filtering”. The test here again is the shadow test.
My “test against r” is what you call the light coverage test. Testing texture fragment against fragment r coordinate is how this is done although it’s been implemented by testing against a second texture fragment on less capable hardware, which may be why you missed my intent.
If you need a more detailed explanation of the fragment test against projected r I’ve put something together here:
http://www.dorbie.com/uav.html
Using the OpenGL API this is enabled by turning on GL_LINEAR texture filtering on the depth map texture. The test against R occurs for each sample depth independently and the result is then filtered. It just happens automatically when you turn on GL_LINEAR filters on a depth texture where the extension is REALLY supported. On a system where you use the hack of comparing one depth texture fragment against another range texture fragment and no real extension support as per the spec it clearly wouldn’t work to turn on GL_LINEAR filtering because the texture filtering merely produces incorrect depth for the test.
Page 43 onwards in this presentation has some relevant information:
http://developer.nvidia.com/docs/IO/1252/ATT/ShadowMapping.pdf
Looks like there is hardware support for this from NVIDIA.
[This message has been edited by dorbie (edited 06-06-2002).]
Actually, the only part I was missing (which was crucial) was those words from the spec. It’s all clear now. Thanks anyway.
What I find a real bummer is that neither Matrox (Parhelia) nor ATI (Radeon 8500) seems to support the appropriate SGIX extensions. That’s a real bummer, and means that shadow buffers aren’t really a valid alternative to stencil shadows for consumer hardware 
u can shadowmap on any hardware (with various results)
the major problem with shadowmaps is they dont work to well for positional lights (the most common kind)
jwatte, I don’t know how I could have been clearer. I agree it’s a shame there isn’t broader support for the extension.
Zed, the percentage closer filtering solves some of the aliasing issues. It’s ironic that the technique was first used for positional lights.