This topic is 4099 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

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

##### Share on other sites
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]

##### Share on other sites

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

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

##### Share on other sites
Yeah exactly :) The direction of comparison only matters for selecting which "tail" of the distribution you are using (i.e. t < mu or t > mu).

On a separate note, have you had much luck with the light bleeding reduction stuff that I sent you? It seems to work pretty well with my "toy" scenes at least.

##### Share on other sites
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 ...

##### Share on other sites
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?

##### Share on other sites
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.

##### Share on other sites
Is there any way for VSMs to look nice on older machines? I tried using them with some older hardware, and I couldn't get them to look decent without 32f color channels.

##### Share on other sites
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.

##### Share on other sites
Doing nothing but changing from 16:16 to 32:32 improved my VSM implimentation immensely. I haven't done much with it so perhaps I was doing something wrong.

8:8:8:8 is basically the same as 16:16 as far as precision goes right?

• 35
• 12
• 10
• 9
• 9
• ### Forum Statistics

• Total Topics
631358
• Total Posts
2999531
×