Skip to main content
GameDev.net gamedev.net
🔒 Locked 🎮 Unity

Question about singlepass parallel-split shadow mapping

Started by B_old Apr 22, 2009 at 8:50 AM 11 replies 2.2k views
Original Post
B_old
B_old
Hi, I have been wondering about implementing parallel-split shadow mapping. Do most people apply all the shadow slices in a single pass or one pass for each slice? Suppose we do do it in one pass. Then we have several projection matrices for the shadow. Usually I would transform a vertex with this matrix in the vertex shader and use that in the pixel shader. Should I do this for every matrix now, or should I pass the vertex to the pixel shader and transform it with the projection matrix there? On the one hand, I have to do a transformation for every pixel now, on the other hand, I have to pass less data between vertex and pixel shader. What is the common solution to this?
MJP
MJP
For rendering the shadow map I do it with 1 pass per split. The only way I know of to do multiple splits per split is to use a geometry shader to duplicate geometry that intersects with multiple splits, similar to CubeMapGS sample in the DX SDK. However I'm not sure it's really worth the effort, since for cube maps that technique tends to be a wash performance-wise to the slow GS performance for amplification.

For generating the actual shadow occlusion, I do it with 1 pass. I just figure out the view-space depth of a fragment, then branch on that and choose the correct shadow projection matrix to apply to the fragment position so I can do the shadow map comparison.
B_old
B_old
Hi,
I also plan to generate the shadowmap 1 pass per split.
I believe the way you do the shadow occlusion is done in the same way I tried to describe. Thanks for the info.
Scoob Droolins
Scoob Droolins
Quote:
Original post by MJP
For generating the actual shadow occlusion, I do it with 1 pass. I just figure out the view-space depth of a fragment, then branch on that and choose the correct shadow projection matrix to apply to the fragment position so I can do the shadow map comparison.

I do the same thing, but from looking at ps asm output, the HLSL compiler will not generate any branch instructions in SM2. In SM3 you can get branching if the sampling of the shadow map is not part of the branch (you cannot do texture sampling inside a conditional). Also, the sampler index must be a literal number, not a loop variable. So this means that for a 4-split setup, you will be sampling shadow depth from all 4 shadow maps for every fragment, 3 results are thrown out, the relevant one is used. This is the best method I have seen so far - any way to do this more efficiently?

MJP
MJP
Quote:
Original post by Scoob Droolins
In SM3 you can get branching if the sampling of the shadow map is not part of the branch (you cannot do texture sampling inside a conditional).


Actually this isn't true. What you can't do is have calculate the gradients for mipmapping inside a branch, since adjacent pixels in a 2x2 quad may not take the same branch. You can get around it by explicitly calculating your gradients outside the branch using ddx() and ddy(), and then passing those in to tex2Dgrad. Or, if you're not using mipmaps (which is usually the case for sampling a shadow map), you can just specify that you won't the top mip level with tex2Dlod and then you don't need the gradients.

Personally I don't even use dynamic branching for selecting the right shadow matrix...I just flatten the branch because this is quicker on my target platform (Xbox 360).


Quote:
Original post by Scoob Droolins
Also, the sampler index must be a literal number, not a loop variable. So this means that for a 4-split setup, you will be sampling shadow depth from all 4 shadow maps for every fragment, 3 results are thrown out, the relevant one is used. This is the best method I have seen so far - any way to do this more efficiently?


This is true, but you don't need to have your splits as 4 separate textures. If you put them all on one large shadowmap texture, then instead of a sampler index you just need an offset for your texture coordinate. My HLSL code looks like this:
// Determine which shadow projection matrix to use[unroll(NUM_SPLITS - 1)]for (int i = 1; i < NUM_SPLITS; i++){		[flatten]		if (vPositionVS.z <= g_vClipPlanes.x && vPositionVS.z > g_vClipPlanes.y)	{		matLightViewProj = g_matLightViewProj;		fOffset = i / (float)NUM_SPLITS;		vColor = vSplitColors;		iCurrentSplit = i;	}}		// Determine the depth of the pixel with respect to the lightfloat4x4 matViewToLightViewProj = mul(g_matInvView, matLightViewProj);float4 vPositionLightCS = mul(vPositionVS, matViewToLightViewProj);float fLightDepth = vPositionLightCS.z / vPositionLightCS.w;	// Transform from light space to shadow map texture space.float2 vShadowTexCoord = 0.5 * vPositionLightCS.xy / vPositionLightCS.w + float2(0.5f, 0.5f);vShadowTexCoord.x = vShadowTexCoord.x / NUM_SPLITS + fOffset;vShadowTexCoord.y = 1.0f - vShadowTexCoord.y;    // Offset the coordinate by half a texel so we sample it correctlyvShadowTexCoord += (0.5f / g_vShadowMapSize);


So then vShadowTexCoord would be the texture coordinate I use for sampling the shadow map, and fLightDepth would be the depth value I compare against what I sample from the shadow map.


B_old
B_old
MJP: Do you know of a way to "just" calculate the split index in the pixel shader? Maybe I should try your method, although I don't know what [flatten] does.
Also I don't really understand the way you compare vPositionVS.z (which is the pixel depth in respect to the viewer?) with the clipplane?
Could you explain the meaning of this?
if (vPositionVS.z <= g_vClipPlanes.x && vPositionVS.z > g_vClipPlanes.y)
Why won't it be true for every split that is "deeper" than the current pixel?

I saw something about the frostbite engine, where they explain, that they generate the shadowmap for all splits in one pass using a texture array and geometry shaders, although I did not understand what exactly they do. Edit: I guess this is what you referred to in your first reply.

Another thing they do, is using bounding-box splitting (or something like that) instead of planes. I did not really understand that either.

On a more general note: How many splits/shadowmap-size do you use? I suppose it makes sense to decide on a number of splits and a certain size and then just try to make that look good.
MJP
MJP
Quote:
Original post by B_old
MJP: Do you know of a way to "just" calculate the split index in the pixel shader?


Well I do calculate the index of the split in my code...I stick it in "iSplitIndex".

Quote:
Original post by B_old
Maybe I should try your method, although I don't know what [flatten] does.


[flatten] is an HLSL attribute that tells the compiler that it shouldn't use dynamic branching. It's just a performance enhancement, it should have no effect on the result.

Quote:
Original post by B_old
Also I don't really understand the way you compare vPositionVS.z (which is the pixel depth in respect to the viewer?) with the clipplane?
Could you explain the meaning of this?
if (vPositionVS.z <= g_vClipPlanes.x && vPositionVS.z > g_vClipPlanes.y)
Why won't it be true for every split that is "deeper" than the current pixel?


Sorry, I probably should have explained that. What I do is I have an array of float2's in my shader, with the same number of elements as there are splits in my cascade. Like this:
float2 g_vClipPlanes[NUM_SPLITS];

Then for each split, I set the Z value (with respect to the camera) where the split starts, and where the split ends. So the array looks something like this:
g_vClipPlanes[0] = {-1, -25};g_vClipPlanes[1] = {-25, -75};g_vClipPlanes[2] = {-75, -200};g_vClipPlanes[3] = {-200, -500};


They're negative because I'm using right-handed coordinates. This is also probably why the inequality looks backwards.

Quote:
Original post by B_old
I saw something about the frostbite engine, where they explain, that they generate the shadowmap for all splits in one pass using a texture array and geometry shaders, although I did not understand what exactly they do. Edit: I guess this is what you referred to in your first reply.


Yup, that's exactly what I was talking about. Nice if you're targeting D3D10, but you can't do it in D3D9.

Quote:
Original post by B_old
Another thing they do, is using bounding-box splitting (or something like that) instead of planes. I did not really understand that either.


Hmm...I'm not totally sure either. What I do is I calculate the parallel splits, then for each split I come up with a bounding box that's aligned with the light source. Then I use the bounding box to to come up with an orthographic projection. This is pretty standard though, so I'd imagine they're doing something fancier.

Quote:
Original post by B_old
On a more general note: How many splits/shadowmap-size do you use? I suppose it makes sense to decide on a number of splits and a certain size and then just try to make that look good.


For the game I'm working on I use 4 splits, each sized 1024x1024.

Also I did make a sample a little while ago that you could look at. The only problem is that it's an extension of an earlier sample and I never got around to doing a new write-up, so the write-up in the zip is for the older sample that doesn't use PSSM. The code all works though. The other issues are that it uses XNA (which I'm not sure if you're using), and it uses deferred shadow maps which changes things a little bit. You should be able to figure out what's going on though regardless, it's pretty straightforward.
B_old
B_old
First of all: Thanks for the input!

Right now I am determining the split by a series of if else statements (if the fragment is not in the closest split it might be in the next one and so on...). But I will try your method. Maybe it improves performance to get rid of the elses.

I can't run your sample because I am missing the XNA stuff, but that deferred shadowmapping part got me thinking.
On the one hand I really like the way it cleans up the lighting shaders. Right now I am comparing hardware shadow maps (using the depthstencil) with variance shadow maps an the effectfiles are already getting ugly. On the other hand, once (if) I decide on one definite shadow technique, the deferred shadow mapping is just another overhead, isn't it?
MJP
MJP
Quote:
Original post by B_old
On the other hand, once (if) I decide on one definite shadow technique, the deferred shadow mapping is just another overhead, isn't it?


No, not necessarily. They can actually be a pretty big performance win, depending on what you're doing. This is because you get better pixel shader performance when you do all of the shadow mapping in one full-screen pass, because you're always utilizing all 4 shaders in a quad. This doesn't happen when you render your scene geometry, since triangles won't always cover all 4 pixels. It actually gets worse as your polygon count goes up and triangles get smaller and smaller. So in the end it's about whether the increased efficiency balances out the overhead of seperating shadowing and lighting into two parts. For me it was a noticeable improvement on the 360, which is why I started using it in the first place. Simplifying my shaders was a nice side benefit though...it let me use PCF for the 360 and leave the option for VSM's on the PC.

B_old
B_old
Sounds intriguing.
Do you use the depthstencil buffer or do you write the z-values into a separate texture?
MJP
MJP
Quote:
Original post by B_old
Sounds intriguing.
Do you use the depthstencil buffer or do you write the z-values into a separate texture?


I render it into a seperate texture, only because there's no way to sample a depth buffer in XNA.
B_old
B_old
At least on nvidia cards you can use the depthstencil buffer for hardware accelerated shadow mapping, no?
Thanks again for all the answers. They were very helpful.

[Edited by - B_old on April 26, 2009 4:08:42 PM]
MJP
MJP
Quote:
Original post by B_old
At least on nvidia cars you can use the depthstencil buffer for hardware accelerated shadow mapping, no?


Indeed, in D3D9 you can use the depthstencil buffer directly for shadow maps but you need to use Nvidia and ATI-specific driver hacks to do them. However you can't use those on XNA, since it doesn't let you specify fourcc surface formats in order to maintain consistency between the PC and 360.

In D3D10 you can just sample the depthstencil buffer without any hacks since that's actually part of the API.

Quote:
Original post by B_old
Thanks again for all the answers. They were very helpful.


No problem, anytime.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.