Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


BlueSpud

Member Since 17 Jul 2013
Offline Last Active Apr 24 2015 05:26 AM

Posts I've Made

In Topic: Cascaded Shadow Maps Look Bad

10 February 2015 - 02:51 PM

 

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.


In Topic: Cascaded Shadow Maps Look Bad

09 February 2015 - 07:57 PM

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.


In Topic: Cascaded Shadow Maps Look Bad

09 February 2015 - 07:47 PM

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. 


In Topic: Cascaded Shadow Maps Look Bad

09 February 2015 - 07:36 PM

 

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.


In Topic: Cascaded Shadow Maps Look Bad

09 February 2015 - 07:16 PM

 

I'm completely stumped, as the code looks like it matches the math from Nvidia to me. My new guess is that its the crop matrix, because even if there was a problem with the orthographic projection, the crop matrix should fix that.

I don’t know what your source material is but if it is the link posted earlier I don’t see where they address the tightening of the projection matrix around the objects they encompass—for that discussion to take place there has to be some mention of an AABB or bounding sphere.

#1: Gather objects in frustum.
#2: Determine the ranges of your cascades as described previously.
#3: For each cascade:
* 1: Create the planes based on the current orthographic projection matrix. It is well known how to extract planes from any matrix. You will now how a new frustum for that cascade (omit the near plane—this allows you to gather objects infinitely towards the sun).
* 2: Gather the objects that are in that frustum.
* 3: Among those objects, use their AABB’s or bounding spheres to tighten the shadow frustum around each object as closely as possible. It’s easy enough to find the distance from an AABB to a plane, but after you’ve gathered the mins and maxes in every direction only adjust the shadow frustum inwards (never make it wider—it is already considered to be at its maximum size.)

In step 3 you are gathering min/max distances in each orthographic direction, which is the information need to reconstruct the orthographic projection matrix.


L. Spiro

 

That assumes that I am using the scene in the cascade splits. I'm not actually doing that, I'm using the camera frustum to determine where the splits are. Basically it is for each cascade as follows:

1. Get the corners of the camera frustum in clip-space

2. Then put them into world space and then into light space.

3. Calculate a AABB of the projected coordinates in light space.

4. Create a crop matrix that fits the bounding box completely to the screen

5. Multiply it by the orthographic projection to get a final projection matrix

 

I think thats where the confusion came from, as you both assumed that I was taking into account the scene geometry, which I am not.

 

Don't forget that near and far planes on an orthographic projection don't change the size of the image that is rendered. An object that is at 10 units away will appear the same size as one that is 2000 units away as there is no perspective calculation. They just determine what is rendered inside your othographic frustum in terms of the z value relative to your camera's direction.

I'm not familiar with OpenGL but I believe your S.x and S.y values represent the width and height of your orthographic view matrix, try scaling these values - if I remember correctly, using 512 x 512 as width and height rendered to a 1024 x 1024 texture should effectively render the image twice the size giving you finer shadow map texels when used in your final image. If you do this, you'll need to remember that you've scaled when your shader gets the value from the shadow map.

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.


PARTNERS