Cascaded Shadow Maps Look Bad

Started by
36 comments, last by RobM 9 years, 2 months ago

The S.x and S.y are the scale of the scene on the X and Y. Because I'm using an AABB to determine what should be in the shadow map, so it isn't always a square to fit the 1024*1024 shadow map, so its scaled to fit with optimal space usage.

When you create your orthographic matrix for rendering the first shadow cascade, the width and height (S.x and S.y) should be just big enough to encompass the first slice of your view frustum as seen from the light as L.Spiro mentioned.

Imagine your physical camera frustum has been split into 4 pieces along the z direction. When looking from the light's position, your orthographic view width and height should only be big enough to encompass the camera frustum slice you're working on.

If your first slice is fairly small, say 10 units, the width and height of the orthographic projection will probably be fairly small too meaning if you're using a 1024x1024 shadow map, you will get a fairly large amount of detail.

The S.x and S.y are for the crop matrix which makes the map encompass the frustum slice.

Advertisement
The code you sent initially doesn't seem to have any reference to the camera frustum slices, it looks like the orthographic projection matrix width and height is created based on a frustum with near 0 and far 1000 - unless I'm missing something?

The code you sent initially doesn't seem to have any reference to the camera frustum slices, it looks like the orthographic projection matrix width and height is created based on a frustum with near 0 and far 1000 - unless I'm missing something?

The frustum slices are inputed with the distances[] array. The orthographic projection doesn't change from the frustum splits, the crop matrix handles all of that.

But you're creating a new orthographic projection matrix for each shadow map/slice right? You would need to because as you work through the slices, they get progressively bigger meaning you'll need to adjust your width and height to encompass them.

But you're creating a new orthographic projection matrix for each shadow map/slice right? You would need to because as you work through the slices, they get progressively bigger meaning you'll need to adjust your width and height to encompass them.

No, thats what the crop matrix does. It will make the scene bigger or smaller so that the bounding box always fits onto the shadow map.

No, thats what the crop matrix does. It will make the scene bigger or smaller so that the bounding box always fits onto the shadow map.

Then you have a different crop matrix for each cascade…yes?


as you both assumed that I was taking into account the scene geometry, which I am not.

I’ve made no assumptions—I’ve never heard of using a crop matrix for cascaded shadows, and don’t understand the approach you are taking enough to make any assumptions.
What I described in my last post isn’t based on assumptions about what you are doing, it’s just the standard way it is done in the industry.


From the sounds of it, it is also more efficient and more straightforward than what you are doing, and will definitely eliminate the problem you have with zaggies, so if your current approach isn’t working I’d suggest just dropping it and starting over using the standard approach. If it has one advantage at all, it’s that by being the standard approach you can certainly find more information on/help with it.


L. Spiro

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid

No, thats what the crop matrix does. It will make the scene bigger or smaller so that the bounding box always fits onto the shadow map.

Then you have a different crop matrix for each cascade…yes?


as you both assumed that I was taking into account the scene geometry, which I am not.

I’ve made no assumptions—I’ve never heard of using a crop matrix for cascaded shadows, and don’t understand the approach you are taking enough to make any assumptions.
What I described in my last post isn’t based on assumptions about what you are doing, it’s just the standard way it is done in the industry.


From the sounds of it, it is also more efficient and more straightforward than what you are doing, and will definitely eliminate the problem you have with zaggies, so if your current approach isn’t working I’d suggest just dropping it and starting over using the standard approach. If it has one advantage at all, it’s that by being the standard approach you can certainly find more information on/help with it.


L. Spiro

I was under the impression that the way I've been doing it is the standard way. I've looked at 9-10 different references and none of them do it the way you just described. If you have a reference, I'll take a look at it.

I was under the impression that the way I've been doing it is the standard way. I've looked at 9-10 different references and none of them do it the way you just described. If you have a reference, I'll take a look at it.

It's not the way I've ever seen it done if I'm honest. The way I thought you were doing it in simplistic terms is this:

1) Cut the camera's frustum into, say, 4 slices in the z direction

2) For each frustum slice, find where the light source would be, it should be roughly at the centre of the frustum slice positioned toward the sun orthographically. Create an orthographic projection matrix from this light position, set the width and height to match the bounds of the camera frustum slice and render

3) repeat step 2 for each frustum slice. The light positions for each frustum will move along the z vector of the camera frustum but as sunlight is considered orthographic, the light direction will be the same for each frustum slice - just its position will be different

Regarding your objects, for each frustum slice you need to render the objects that are inside or intersect that frustum slice and render those. The near and far planes should enclose all objects that can possibly cast shadows into that camera frustum slice so if you have a bird that is between the sun and a camera frustum slice, it should be rendered regardless of whether it is actually inside the camera frustum slice..

I would suggest doing some more research on cascaded shadow maps and find one with some good diagrams of how this works - it might help you to see where you're going wrong in your code - I wouldn't just rely on one example implementation as some are easier to follow/understand than others.

This topic is closed to new replies.

Advertisement