spot light soft shadow (variance vs depth pcf)

for spotlight I use VSM and rather small shadow maps which I then blur (normally spotlight shouldn't cove to much world space). Shadows are far from hard and you might have some light bleeding but the overal results looks really soft. For characters and other object which need to cast high detailed shadows you need another solution anyway

VSM and PCF will give you the same results for a single planar occluder and receiver (as proven in the paper). As mentioned light bleeding can occur when the depth functions becomes more complex though.

Still don't think of them as separate things: VSM is a fast way to do PCF (and it can do more with hardware, like mipmapping and aniso). Indeed the two can be combined in some good hybrid strategies. PCF is just the brute-force way to filter the depth distribution.

Blurring performance should actually be pretty good, depending of course on your kernel size. Still, we could easily get 13x13 blurs of 1024x1024 shadow maps on modern hardware at quite fast speeds. Some tips:

1) You can get two samples at once using bilinear filtering hardware (ask for a pixel between the two that you want, with the fractonal part being the relative weights that you want each pixel to get).

2) Make *sure* you're using a separable convolution, like Gaussian, and do the horizontal and vertical passes separately.

3) You can also apply smaller kernels several times instead of one large kernel. Ex. apply a 3x3 kernel, then triple the Gaussian sigma value and apply it again.

4) ATI can use Fetch4 to get 2-4 pixels at once if you split your textures into two one-component ones. May or may not be worth it.

There's more stuff, but those should get you up to quite a fast speed. In my experience VSM can be implemented with a very small performance hit over regular shadow mapping, and *much* better quality. Also note that as Guoshima mentions, you don't need as large a shadow map since VSM can hide aliasing much better without needing to resort to huge resolutions. Thus on equal-quality comparisons, VSM can be a *huge* win (as also shown in the VSM paper).

Quote:

Original post by Guoshima For characters and other object which need to cast high detailed shadows you need another solution anyway

ok so what is this solution ?
I just need to know how I can have a decent blur when I 'm not using variance shadow map
I know I will never have the same blur quality but I need decent quality and for now all my blur shaders tests were very bad ! :(

Quote:

Original post by AndyTX Thus on equal-quality comparisons, VSM can be a *huge* win (as also shown in the VSM paper)

the problem is that I'm working on a Nvidia hardware and writing to a 64bits (8bytes) render target (instead 32bits / 4 bytes) is twice more costly than writing just in a 24 depth buffer (and I can disable color write)
is that possible to use another format for the render target ?

so I have the variance shadows working on small render target, and the blur is very nice, but I have to enhance the blur of my classic depth shadow map ! ;)

I've found Manual Bilinear 3x3 PCF (weighted PCF, not the simple averaging) gives very good results even with a large magnification of a small shadow map. Its quite expensive though, as it takes 9 samples. It looks much better than some limited VSM blurs, but is probably/most-likely much more expensive. Better VSM blurs (which require more time) would probably be just as good minus any light bleeding artifacts. NOTE: My VSM experience is somewhat limited as I got it working, but spent most of the time dealing with 16bit fp precision issues on nvidia hardware for moderate to long ranges (even storing -1->1, and trying fp16x4). Also had issues with nvidias fp16 texture filtering causing artifacts compared to manual bilinear filtering in "large" light ranges. Haven't had time to get back to VSM due to other work. fp32x2 works quite well, but is sloooooowww on most current cards.

You could probably get similiar results with 3-4 weighted hardware bilinear PCF (nvidia cards only) lookups, offset from the original sample points.

A 4x4 dithered average PCF (only 4 samples per pixel, mentioned in one of the graphics gems books i think) looks good for less work, but still has some visible blockiness in the worst situations due to the averaging. It does require the screen position to calculate the sample offsets, so its still got a few more instructions than a standard 4 sample filter.

I hear of people using rotated sample locations (4 samples or more) to good effect, but I haven't tried it much. If anyone (wolf?) wishes to speak about there usage/attempts at this, it would be welcome by me as well.

Anything that is ordered (such as averaging PCF) will probably look "blockier" unless jittered, or rotated. The bilinear weighting helps this to some effect compared to simple averaging, but its still not as good as jitter/rotated. I'm no expert on this subject, so you can always just try things. There are a few papers out there discussing and comparing different PCF techniques and Poisson disc filters and the like.

All that said, I would also keep working on VSM. I think it has good potential, and anything that could reduce texture mem usage for shadows (ie store at lower resolutions for comparable quality) will help speed tremendously.

Quote:

Original post by zoret the problem is that I'm working on a Nvidia hardware and writing to a 64bits (8bytes) render target (instead 32bits / 4 bytes) is twice more costly than writing just in a 24 depth buffer (and I can disable color write) is that possible to use another format for the render target ?

Texture formats are certainly a problem right now as they are highly unorthogonal on both vendors...

Unfortunately, you will probably need at least 16 bits for depth and another 16 for depth^2. Theoretically all you need then is 32-bits, and indeed you can use G16R16 on ATI. Unfortunately I know of no similar format on current NVIDIA cards, and thus you'll have to use 4x fp16 (annoyingly enough, 2x fp16 is not renderable).

I expect this will get better with new hardware, but for now you may just have to eat the bandwidth cost, making the shadow map smaller if necessary.

Quote:

Original post by multisample Better VSM blurs (which require more time) would probably be just as good minus any light bleeding artifacts.

Yep - actually it's possible to reproduce exactly any uniform linear sampling that you do with a preprocessing step with VSMs. In particular NxN guassians are what we used ithe most in the paper. The advantage of doing it in advance is that you only have to do it once per shadow map pixel (rather than per fragment), and it's often separable (such as gaussian), making really huge filter kernels quite viable.

Quote:

Original post by multisample Also had issues with nvidias fp16 texture filtering causing artifacts compared to manual bilinear filtering in "large" light ranges.

You too? I thought it was just me! I was always surprised when the manual bilinear filtering produced better results than the hardware... guess they're doing it in lower precision somewhere...

Quote:

Original post by multisample I hear of people using rotated sample locations (4 samples or more) to good effect, but I haven't tried it much.

ATI has quite a few papers on this. Indeed the goal is to try and futher hide the discrete nature of the shadow map - it works well with enough samples. On ATI you can use Fetch4 to do quite a few samples and get a pretty good result actually.

Regarding bilinear weights, you should probably always use them. Otherwise you're going to be dealing with only N possible contributions... unless you're taking 256 samples or more (unlikely), this is quite undesirable.

Quote:

Unfortunately I know of no similar format on current NVIDIA cards, and thus you'll have to use 4x fp16 (annoyingly enough, 2x fp16 is not renderable).

Both D3DFMT_G16R16F and D3DFMT_G16R16 are renderable and filterable on my 6800GT.

Quote:

Both D3DFMT_G16R16F and D3DFMT_G16R16 are renderable and filterable on my 6800GT.

Actually, only fp16x2 is renderable on the 6/7 series (according to NVIDIA's GPU Programming Guide and my experience). Both formats are filterable. NVIDIA could be using an fp16x4 in the background behind our back, but I don't think they are.

AFAIK, filtering on NVIDIA's hw happens at the same bit/precision as the source, so fp16 is filtered using fp16, rgba8 using rgba8, and fp32 as fp32. Hence filtering results can be less than spectacular when you filter outside of the range/precision of the source.

Quote:

Original post by AndyTXATI has quite a few papers on this. Indeed the goal is to try and futher hide the discrete nature of the shadow map - it works well with enough samples. On ATI you can use Fetch4 to do quite a few samples and get a pretty good result actually. Regarding bilinear weights, you should probably always use them. Otherwise you're going to be dealing with only N possible contributions... unless you're taking 256 samples or more (unlikely), this is quite undesirable.

I haven't found many papers that use only around 4-6 samples which is what I am finding as acceptable for what I need (multiple lights, multiple shadows, current gen). If I had only 1 shadow the 12 sample one might be doable. Anyone have a reference to any lower sample rotated/jittered versions that look good ?

As for the Bil weights, I totally agree. I messed around with this a bit and i personally think its almost essential. Someone could probablty work out the 4x4 dithered to use bil weights for each pixel and get good results. At a decent distance the 4x4 dithered looks pretty good (due to the "noise" factor), so a bilinear weighted version may work well.

As per VSM and fp16, I was fighting the filtering problems (I could live with manual filtering if I can blur them), but I still had problems with the medium to larger light ranges. I believe its due to the "square" of the depth, since it requires much more precision than the depth itself. I was wondering if the Ch. Inequality would work with depth and sqrt(depth) as that might give better results (in this case treating sqrt(depth) as the random variable, and depth as the "square" of the random variable. You would probably still have issues though. What were your results with light ranges that were acceptable (relative to your smallest shadowable range) ? Maybe I should move this to another thread as I think I may have hijacked it a bit :)

Quote:

Original post by multisample I believe its due to the "square" of the depth, since it requires much more precision than the depth itself.

Yeah, the higher moments need more precision to represent. Specifically, Chebyshev's inequality is highly numerically unstable.

Quote:

Original post by multisample I was wondering if the Ch. Inequality would work with depth and sqrt(depth) as that might give better results (in this case treating sqrt(depth) as the random variable, and depth as the "square" of the random variable.

I'm not sure if that would help. I think we're actually dealing with a "true" precision issue here, in that we've lost too much data to properly combine lots of distributions and still get an extremely accurate result.

Quote:

Original post by multisample What were your results with light ranges that were acceptable (relative to your smallest shadowable range)?

We got decent results for fp16 and fx16 (better with the latter of course), and pretty much perfect results for fp32 (as expected with a 24-bit mantissa). fx32 would be ideal, and potentially one could encode it into 4x fx8, but one may lose precision in the process.

Quote:

Actually, only fp16x2 is renderable on the 6/7 series (according to NVIDIA's GPU Programming Guide and my experience). Both formats are filterable. NVIDIA could be using an fp16x4 in the background behind our back, but I don't think they are.

Hmm, that's strange. Like you said, the GPU programming guide says that D3DFMT_G16R16 is not renderable, but the caps viewer on my machine says it is. Anyone actually tried this out on a geforce 6/7?

Quote:

Original post by jamesw Hmm, that's strange. Like you said, the GPU programming guide says that D3DFMT_G16R16 is not renderable, but the caps viewer on my machine says it is. Anyone actually tried this out on a geforce 6/7?

Sigh, I hate the caps stuff ...

I believe it can have the "usage" of rendertarget (ie D3DUSAGE_RENDERTARGET), but its not a RenderTarget "format". In the Caps viewer for this laptop (Nvidia 6800 Go), D3DFMT_G16R16 is not listed under "Render Target Formats" but is listed as a texture format that can have RenderTarget usage. I believe all this means is that it can be used as a source or dest when doing a StretchRect from texture to texture. I could definitely be wrong about this, so you may want to ask Nvidia. My hunch is to believe the table in the GPU Programming Guide though.

Stranger still! D3DFMT_G16R16 is listed under render targets and has render target usage on my 6800 GT!

Caps viewer page

What driver ver are you on? I'm on 93.50 (the instrumented version that comes with nvPerfKit2.1) but the first time I checked i was on 84.21.