Summed-Area Variance Shadow Maps (Demo)

[ChasB]

Averaged Area Tables

Anyone tried using these instead of Summed Area Tables?
(you just divide by the nr of pixels during creation which is probably still i/o bound)
These often require much less precision (so can fit into an 8-bit surface)
which should be faster to read and filter when used.

Chas.

 

[Andrew Lauritzen]

Do you have a link? I'd certainly love to try anything that could fix the precision problems!

 

[Simon F]

Anyone tried using these instead of Summed Area Tables?
(you just divide by the nr of pixels during creation which is probably still i/o bound)
These often require much less precision (so can fit into an 8-bit surface)
which should be faster to read and filter when used.

Chas.

I've never heard of these before but if I'm correctly guessing what you are saying, how do you get correct results at all?
For example, how do you get an results when you are trying to compute the rectangle between, say, texels (1022,1022) and (1023,1023)? I would suspect the averages stored at the four locations correspending to the corners of that rectangle would all be indentical, which would result in a thoroughly incorrect zero result.

 

[Mintmaster]

I assume he's saying you multiply the fetched value by a number (depending on the fetch location) before doing the subtraction.

I suppose this might help in improving fixed point SAT's because it will help to avoid clamping, but you don't get any better precision for floating point, and it breaks hardware filtering too because N is different for adjacent pixels.

ChasB, the problem is precision, not range. Averaged Area Tables don't accomplish anything.

 

[Andrew Lauritzen]

Yeah, furthermore biasing by -0.5 accomplishes the same thing. Biasing by the mean theoretically ensures that the bottom right hand pixel has a value of 0.0 as well. i.e. each of the pixels in the SAT have a "true" value of value+bias*x*y. However when recovering the average, it's sufficient to just unbias the resulting value.