Hi, I have Variance Shadow Maps running for a while now and I have now some time to improve them. The old thread was retired: http://www.gamedev.net/community/forums/topic.asp?topic_id=374989&PageSize=25&WhichPage=5 So I had to open up a new one. I want to look into light bleeding artefacts. What I did first is go through the equations and see that I understand everything. I need to write a short documentation on how it works. Here is what I have: ----------------- The value in x is the depth value that is calculated based on the distance of the light to the vertex. The value in x -also called Moment 1- is stored in the x channel of the two-channel render target in the first render pass. E(x) holds the result from filtering x. The value x^2 (Moment 2) is stored in the y channel in the first rendering pass. E(x^2) holds the result of filtering x^2. Equation for mean μ value: μ = E(x) = M1 The mean μ value and E(x) keeps the result of filtering the x channel of the texture that holds the x = depth values. Equation to calculate variance: σ^2 = E(x^2) - E(x)^2 = M2 - M1^2 x^2 is the depth value multiplied with itself and stored in the y channel of the render target. E(x^2) holds the result of filtering this value. Chebyshev's inequality (one-tailed version): P(x >= t)<=pmax(t) = σ^2 / (σ^2 + (t - μ)^2 The variable t holds current fragment depth. ----------------- The interesting part is that all implementations I see seem to exchange the t - u part in the source code. It comes down to the following two lines:

// 
float m_d = (moments.x - RescaledDistToLight);

// Chebyshev's inequality
float p = variance / (variance + m_d * m_d);

t is obviously the variable RescaledDistToLight and the mean value μ is moments.x ... which means it seems to come down to (-u -(- t))^2. If this is true I would use negative values in render targets? I guess I miss something here. The part I do not get is the following: P(x>=t) ... I can see that t is the fragments depth value, but x would be following the naming convention above the depth value that is stored in the x channel of the render target, but it would not represent the occluder depth distribution function ... which is probably E(x) or μ? So t > E(x) is a requirement but for t <= E(x) the standard shadow mapping would jump in. Any clarification is appreciated, - Wolf

Quote:(-u -(- t))^2

... I solved my own problem here :-) ... it does not matter if I write t - u or u - t because I just need the difference without looking at the sign ... if it ends up in minus the m_d * m_d line will make it plus anyway :-)

[Edited by - wolf on March 20, 2007 8:46:32 PM]

Hi wolf. Glad you figured it out on your own.

Andrew's done a whole bunch of new work on VSM since the I3D paper, some of it related to light bleeding.

See this thread: http://www.beyond3d.com/forum/showthread.php?t=38165

He is also contributing a chapter to GPU Gems 3 with his new research.

Hey this looks cool. I just checked out the demo and the results look great, but ... unfortunately the technique does not seem to be fast enough on my target hardware platforms :-) ... so I will invest some time to make VSM more bullet-proof.
Would you guys be interested in seeing the propsals regarding VSM for ShaderX6? I would appreciate your comments here. If you are interested in cross-referencing, talk to your editor if you can send me your paper and we will refer to it in ShaderX6 :-). We usually do things like this ...

One interesting thing: If I click distribute precision on my GeForce 7900 GTX there is no real difference in speed .. this might have something to do with the fact that the 7900 does not have a "native" 32:32 format. How does Summed-Area VSM work then with 16:16:16:16 render targets?
The softness slider is mind-blowing :-) ... hm the difference between 32:32:32:32 and 32:32 is obvious :-) ... cool.
What does light bleeding reduction do? Using the Markov term? What does softness do?

we use some of your suggestions for reducing light bleeding that were made in certain scenes where self-shadowing of characters is important. Thanks for this.

I believe with the current implementation this will be difficult. If even a 16:16 render target is not enough, you will have problems to run 32:32 on older hardware. What you might try is to distribute the two 16-bit values over 8:8:8:8 ... some hardware platforms need this.