Sign in to follow this  

Sunlight shadows

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey guys, I really need some help here :( I am working on outdoor shadows but I can't seem to make it work well. I do have some experience with shadowmapping spot and pointlights, but never before with directional lights. The great distance of the sun seems to be the problem. For the shadowmap I use an orthographic projection with its center targed at 256 units infront of the player's feet. (It moves with you). I often read directional lights dont have a position, but I need a position to give to the viewmatrix so it knows what exactly to project right? And also to messure distances that I can store in the shadowmap? I have a terrain of 1024x1024 units, which has some hills on the edges. The highest point on the terrain is at 120 units. For testing purposes I put a cube, a sphere and a torusknot of radius 5 units in the map. I need help setting the parameters right, cause Ive tried just about everything and can't get a half descent result. - Position of the sun? -> I tried (500,500,500) to get 45 degrees. - Width of the othrographic projection? -> I tried 512x512. - Near and far clip planes of othroproj? -> I tried 0,1024. - MaxDepth to use in the shader? (tex2Dsample * MaxDepth = storedDistance) -> I tried 1024; - Depthbias? -> I tried everything. Can you tell what values you guys normally use? Btw. I know it will never work well with SSM, and I am eventually going for PSVSM but I want to get SSM to work first before I go on. But it just looks way too crap even for SSM with a smap res of 2048x2048.

Share this post


Link to post
Share on other sites
Typically I'll get a "position" for the sun's shadow caster by finding the centroid of the camera's view frustum, then backing up in the opposite direction of the sunlight. Then what I'll do is I'll create a view matrix using D3DXMatrixLookAtLH with that new position as the eye point and the centroid as the lookAt point. From here I'll transform the corners of the camera's view frustum to "shadow space" by transforming them with the matrix created with the call to D3DXMatrixLookAtLH. Once you have these 8 coordinates, if you find the min and max x, y, and z you can figure out the parameters you need to create the orthographic projection.

Share this post


Link to post
Share on other sites
Ty MJP, it is a little better now, but not great.

About your method:
- How much do I "back up" from the centroid? Right now I do 725 units.
- The far 4 points of the view frustum are at the far cameraclipplane correct? If so, that's 1024 units! Which means the orthoprojection width is roughly 1024 aswell! That seems too big, so I chose half that. (which means the far terrain will not be shadowed :()

In this video I use an orthoproj of 512x512 with a 2048x2048 shadowmap:

[url]http://www.youtube.com/watch?v=QinO13cnWGk[/url]

- Sun is 725 units away from the centroid.
- DepthBias = 2.2
- MaxDepth = 1024.0

Any idea what is causing that extreme flickering/waving/dancing of the shadows??
I've already tried playing with the bias but this seems the least awfull setting.

Share this post


Link to post
Share on other sites
Yeah if you cover your entire view frustum with just a single shadowmap with a single projection, you unfortunately get some of the problems you encounter. You'll generally end up with a wide projection which causes your shadowmap to get stretched out pretty far (and consequently causes a good bit of the shadowmap's texels to be wasted). To get around these issues you'll need to look into techniques that partition the view frustum in order to waste less shadowmap texels, like parallel-split shadow maps.

I can't watch your video right now since I'm at work, but I'll check it out later. It's probably a biasing problem...bias is very difficult to set correctly since you may need to change it depending on the slope of the occluder and receiver. Rendering backfaces can help in some situations, or you can consider something like VSM where biasing isn't an issue.

Oh and btw...for links here you have to use HTML and not BBCode, same for images.

Share this post


Link to post
Share on other sites
I understand MJP, it was just worse then I expected. I hope it will look good once I get PSSM in, but that will take me a while.


Meanwhile I have come up with another improvement:

Instead of using a grayscale shadowmap, I spread the depth values over 3 color channels. This gives me 24 bits instead of 8 bits to store the depth in. Net result is 3x less artifacts with a 3x smaller bias :)
It works and I can clearly see the visual improvement!



Thinking about this I got another idea:
When using PSSM I could store all 3 shadowmaps in 1 texture. One in every color channel. This should save alot of memory...

What do you think?

Share this post


Link to post
Share on other sites

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

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this