Beyond3D Forum

Andrew Lauritzen · 25-Apr-2007, 04:33

Hello again all. I promised to post the updated D3D10 demo of variance shadow maps, so here it is!

Since the original summed-area variance shadow maps thread and demo, I've done a decent bit of work. In particular, the application has been ported to D3D10, improved in several ways, and new techniques, features, and a new scene have been added.

A summary of the available techniques:

Normal ugly shadow maps.
Hardware accelerated percentage-closer filtering.
Variance shadow maps with trilinear/anisotropic filtering, and blurring to clamp minimum filter width. Also supports multisampling.
Summed-area variance shadow maps as described in the previous thread, except now with support for multisampling, as well as both an fp32 and int32 implementation.
Parallel-split variance shadow maps, which help magnification as well.

Shadow MSAA makes a *huge* difference in motion (use "animate light" checkbox). It really has to be seen to be believed, but even for really large minimum filter widths, swimming is still somewhat visible without MSAA. With even 4x MSAA swimming is drastically reduced or eliminated.

int32 is also really awesome for summed-area tables, and is the preferred implementation. Two things make this the case: the extra bits of precision over fp32, and the overflow behavior in D3D10. The latter works because overflow is wrapped in D3D10 which means that we only need to waste W*H bits of the SAT for accumulation where WxH are the dimensions of the maximum filter width. This maximum filter width can be bounded fairly conservatively (ex. 64x64 is plenty - probably overkill for most implementations). The results of int32 make numeric precision a non-issue again, and save a ton of memory bandwidth since there's no need to distribute precision into 4 components.

Parallel-split variance shadow maps are also really cool, especially with the new, larger "convoy" scene. Three 512x512 variance shadow map splits with 4x MSAA and a bit of blurring looks fantastic and has excellent performance, and the quality can go up from there if necessary. Note that this implementation is relatively unoptimized; it's more of a "proof of concept". In particular, the shadow split locations could be chosen a lot more sensibly, and even some basic frustum culling would greatly improve the performance of rendering the different shadow map splits.

There's a few details that come up with PSVSM that I thought you guys may be interested in as well. Feel free to skip over the next few paragraphs if not.

First to get consistent blurring over the different shadow splits one needs to scale the blur kernel size by the ratio of texel sizes between the current split and the full shadow frustum. This is fairly easy to do and very nicely hides the split locations as well, even in motion (see screenshots below). Note that in this demo I round the scaled filter widths to the nearest integer for simplicity; quality could certainly be improved further by allowing non-integer blur kernels.

The second detail is the "fun" one: the splits are rendered into a texture array and the applicable split is computed in the fragment shader when shading the scene. This split index is used to choose the appropriate projection matrix and texture array element. This poses a problem, however, for computing texture coordinate derivatives and LOD, since different pixels in the same quad may choose different slices, resulting in unrelated texture coordinates and nonsensical derivatives/LOD. Other implementations have not noticed this problem because without variance shadow maps (and proper shadow filtering), there *is* no LOD computation as things are at best bilinearly sampled.

To solve this problem we really want to arbitrarily choose one of the two split indices and make sure they are consistent across the quad (note that I'm assuming only two split indices in a quad, but this turns out to be completely reasonable). After some head scratching I came up with the following code:

Code:

// GLOBAL
const int SplitPowLookup[8] = {0, 1, 1, 2, 2, 2, 2, 3};


// IN FRAGMENT SHADER:
...
// Compute which split we're in
int Split = dot(1, Input.SliceDepth > g_Splits);
    
// Ensure that every fragment in the quad choses the same split so that
// derivatives will be meaningful for proper texture filtering and LOD
// selection.
int SplitPow = 1 << Split;
int SplitX = abs(ddx(SplitPow));
int SplitY = abs(ddy(SplitPow));
int SplitXY = abs(ddx(SplitY));
int SplitMax = max(SplitXY, max(SplitX, SplitY));
Split = SplitMax > 0 ? SplitPowLookup[SplitMax-1] : Split;
...

The idea is that while differencing doesn't give us an idea about where we are in an arithmetic sequence (ex. it will always return 1 or 0 for a sequence like 0, 0, 1, 2, 2, 2, 3, ...), it *does* tell us where we are in a geometric sequence. In particular, we will recover 2^(x+1)-2^(x) = 2^x, so taking the log2, we can recover x! (SplitPowLookup is just a small log2 lookup table). This allows us to make an choice about which split to use (x or x+1) and guarantee that the choice will be the same in the other pixels in the quad. Thus, the derivatives will be meaningful.

Ugly trick, I know, but it works like a charm! It's also less ugly than my first idea which was to compute which pixel the current fragment is in the quad using vpos % 2

Anyways grab the demo here: Variance Shadow Maps Demo (April 26, 2007)
Source will be released with GPU Gems 3, and the accompanying chapter covers pretty much everything you ever wanted to know about variance shadow maps and shadow map filtering in general.

Please note the requirements (as detailed in the included Readme):

Any reasonably modern CPU/RAM
Windows Vista (for D3D10)
A D3D10 capable video card
DirectX Redist April 2007
Available free from http://www.microsoft.com (search for the above)
Visual C++ 2005 Redistributable Package
Available free from http://www.microsoft.com (search for the above)

Some screenshots:

SAVSM:

PSVSM:
Note that this quality level is greatly superior to stock PSSM/CSM, even when the latter have much larger shadow maps and more splits. Check out the PSSM demos if you don't believe me.

PSVSM Splits:
Zoom in and note that pixel quad trick at work.

VSM for the same scene:
Note how much poorer it looks compared to the above - the effect is even more pronounced in motion, and for lower resolution shadow maps.

In any case, go pick up a copy of Gems 3 when it comes out and enjoy the chapter. I'm pretty happy with it so far, and I think anyone interested in real-time shadowing algorithms will find that it contains a lot of useful information. Plus I'm sure that the rest of Gems 3 will be at least as good, if not better than my chapter, so it's worth it in any case

To summarize though:
- For constant filter-widths, variance shadow maps + all the filtering and MSAA the hardware can give you + blurring is amazing and super-fast.
- For variance filter-widths (plausible soft shadows algorithms), summed-area variance shadow maps with int32 + MSAA also looks amazing and is quite fast as well, especially compared to the alternatives.

Also, if anyone happens to be going to I3D 2007 next week, come check out my poster; I'd love to chat!.

Enjoy,
Andrew Lauritzen
University of Waterloo / RapidMind Inc.

PS: Some people have asked about a 360/PS3 demo of variance shadow maps. I'd love to do it, but I don't have access to the necessary hardware and dev kits right now. Of course if anyone can help on that front... :P

[EDIT] Updated demo to include Readme.

AlStrong · 25-Apr-2007, 06:10

My eye-sockets are clearly not big enough right now.

Well done.

Btw, there's no readme in the rar file.

Quote:

PS: Some people have asked about a 360/PS3 demo of variance shadow maps. I'd love to do it, but I don't have access to the necessary hardware and dev kits right now. Of course if anyone can help on that front... :P

How about using the XNA tools for the 360? "All" you need is a 360 + HDD and the XNA Creator's Club membership.

Quote:

Q: How much does XNA Game Studio Express cost? Is there a difference between Windows and Xbox 360 development?
A: Visual C# Express, the XNA Game Studio Express tools and runtime environment for Windows are all FREE. To develop, debug and/or play games on the Xbox 360, however, you must have an XNA Creators Club subscription purchased directly from the Xbox Live Marketplace. Two subscription options are available: $99 per year or $49 per four months.

http://msdn2.microsoft.com/en-us/xna/aa937795.aspx

Graham · 25-Apr-2007, 11:42

Ok this is a random thought, you mention problems on the quad level with splits differing between quads - on the 360 shader implementation there are special attributes for if branches that make them operate at the quad level, an 'ifall' and 'ifany' style. Could these possibly be used for a more elegant solution? (these are exposed in XNA)

Looks very good

Andrew Lauritzen · 25-Apr-2007, 14:54

Quote:

Originally Posted by AlStrong

Btw, there's no readme in the rar file.

Whoops, sorry... I went to all the trouble of updating it and then forgot to include it

I'll add it to the zip when I get home.

Quote:

Originally Posted by AlStrong

How about using the XNA tools for the 360? "All" you need is a 360 + HDD and the XNA Creator's Club membership.

I don't have a 360

Also I was under the impression that the XNA tools don't give you a whole lot of access to the specific hardware. In particular, I'd need control over the EDRAM and a few other hardware-specific features to make an efficient implementation. Plus I'd have to recode it all in C#, although I'd be willing to do that if necessary...

Quote:

Originally Posted by Graham

Ok this is a random thought, you mention problems on the quad level with splits differing between quads - on the 360 shader implementation there are special attributes for if branches that make them operate at the quad level, an 'ifall' and 'ifany' style. Could these possibly be used for a more elegant solution? (these are exposed in XNA)

That's interesting, I hadn't heard of these instructions. They could probably be used to similar effect, but I'm unsure... if they don't tell you which pixel in the quad you are, then they are no better than checking if derivatives == 0. I'll look into that though as it sounds interesting.

Graham · 25-Apr-2007, 22:25

Actually I think I might be wrong.
The official documentation is a bit less clear...

http://msdn2.microsoft.com/en-us/library/bb313968.aspx

Code:

ifAll 	Executes the conditional part of an if statement when the condition is true for all threads on which the current shader is running. 
ifAny 	Executes the conditional part of an if statement when the condition is true for any thread on which the current shader is running.

Sorry bout that

[edit]
*HOOT HOOT*

this may be even better:

http://msdn2.microsoft.com/en-us/library/bb313942.aspx

Code:

getCompTexLOD2D 	
For 2D textures, gets the LOD for all of the pixels in the quad at the specified coordinates.

Andrew Lauritzen · 25-Apr-2007, 23:41

Quote:

Originally Posted by Graham

this may be even better:
getCompTexLOD2D

No dice - it takes the texture coordinates as a parameter and thus will have the same problem for different splits. I'm pretty sure that the only way one can solve this (other than my current solution) is if there was some instruction that forced - arbitrarily - the four pixels in a quad to go down the same control flow path, or choose the same value.

Andrew Lauritzen · 26-Apr-2007, 17:45

First, thanks for the front-page link!

Second, I'd just like to mention that there's nothing preventing one from doing summed-area variance shadow maps with parallel-split (or cascaded) shadow maps (PSSAVSM?

). Indeed that would probably be a really good combination for two reasons:

1) PSSM generally only needs smaller shadow maps (3 512x512's is usually plenty) which are significantly cheaper to generate SATs with and have less numeric problems to boot (although with int32, numerics are pretty much fine even for large shadow maps).

2) The texel ratio scaling can cause some large filter widths in some cases which can get expensive with standard blurred VSMs. This wouldn't be a problem at all with SAVSM.

The filtering techniques and projection splitting/warping techniques are entirely orthogonal, and I would have implemented them this way in the demo if not for the absolute inadequacy of HLSL/Fx for doing that sort of abstraction and encapsulation. Thus the only reasons why I only implemented PSVSM are time and laziness

PSSAVSM would indeed be very cool. Why not even throw in some soft shadows using PCSS and get parallel-split soft summed-area variance shadow maps (PSSSAVSM?

). One could even throw in some trapezoidal shadow mapping on each of the splits, but may be getting excessive - particularly on the acronym front

IbaneZ · 27-Apr-2007, 11:06

I just wondered why it's so damn crowded in 3d T&A all of a sudden.

chenmengji · 27-Apr-2007, 12:09

Hi there.First to thank AndyTX's VSM source code.VSM is a decent way to take care of shadow map.No doubt that Variance Shadow Maps can be continually improved along with Hardware upgrading.The new techniques in your VSM demo for D3D10 is awesome.It will be more meaningful and effective if you put those new techniques back for D3D9.Keep good working

Attaching some screenshots for my VSM test running on Virtools 3.5 with
D3D9/ShaderModel2.0.

Shadow based on VSM
1

http://img243.imageshack.us/img243/8...70427b1ak0.jpg

2

http://img132.imageshack.us/img132/1...70427b2wm1.jpg

3

http://img227.imageshack.us/img227/1...70427b3bd5.jpg

4

http://img221.imageshack.us/img221/3...70427b4hh0.jpg

chenmengji · 27-Apr-2007, 12:26

512x512
img224.imageshack.us/img224/5228/devr200704275121qv2.jpg

1024x1024
img228.imageshack.us/img228/8459/devr2007042710241pe5.jpg

Parallel-split researching...
img172.imageshack.us/img172/6964/devr2007042714530623tx5.jpg

Above all are 4xAA screenshots.

chenmengji · 27-Apr-2007, 13:36

Reissue one screenshot

http://img224.imageshack.us/img224/6...rtools2sk0.jpg

Andrew Lauritzen · 27-Apr-2007, 16:42

Quote:

Originally Posted by chenmengji

It will be more meaningful and effective if you put those new techniques back for D3D9.

Yeah I know... I'm just lazy and back-porting to older APIs/hardware just isn't fun, which is a primary motivating factor when you're working for no pay

Thanks for sharing the screenshots! Shadows are nice, and I'm looking forward to seeing the fully-shaded scenes. One minor note about the code in the second window - with respect to VSM epsilon while I originally modified that variance as you have done there, recently I've just been clamping the minimum variance to some value, which seems to work pretty well and is a bit simpler. Either way should be fine though, just thought I'd mention.

wolfgang · 27-Apr-2007, 18:54

Hey Andy,
great looking screenshot.
The idea of using a distribution of shadow samples based on probability is great. The main problem with Variance shadow maps are the light bleeding artefacts. It seems like some people found ways to get around those by choosing a different probability equation (covered in ShaderX6

... couldn't resist).
Did you use a trick to get rid of light bleeding in your plain variance shadow map implementation?

After having solved depth aliasing / light bleeding artefacts and after we have found ways to blur the penumbra with hardware, the next frontier is probably how to construct the light view frustum in the most efficient way to save more cycles by using smaller maps. Additionally low-res shadow maps start flickering when you move around the camera. This is also an interesting area of research.
Did you look into light view frustum construction a bit ... any advice?

- Wolfgang

Andrew Lauritzen · 27-Apr-2007, 19:47

Quote: