I use these splits to calculate the corners of the cascade frustum that is being considered. So if I am going to update the first cascade shadow map I use the first and second frustum split positions. ie. m_fSplitPositions [0] and m_fSplitPositions [1].

So now I have 8 view space corners for the split frustum in view space. I generate the bounding box of these points and get the center. Again this is in View space. I take the max AABB point, subtract from the centroid I calculated and get it's length. This is what I use as the radius of the sphere that encloses this split frustum.

I then multiply the View Space frustum center by the inverse view to get the center in world space. I do the above for all FOUR cascade frustums when I am done I have FOUR spheres in TOTAL. One for each split sub frustum. Since I have 4 cascades I have 4 spheres.

I use m_cShadowMatrix [4] to generate the shadow maps in my shadow atlas..... So In the shader I generate the vertices of the shadow caster into word space and then multiply like so:

m_cShadowMatrix * m_cWorldMatrix * vsInput.vPosition;

In the pixel shader I save out the z value.

Is my algortihm sound? Or perhaps I missed something in my understanding of the algorithm. I would appreciate any help anyone can give me as to where I could be going wrong. Also if anyone knows of any demos with source that I could run to test this algorithm I would be ever so greatful.

It seems doubtful that misunderstanding the overall algorithm is the source of a totally blank screen; presumably, if the algorithm as you're implementing it seems to make sense to you, you'll at least get some kind of output, even if it's not correct. That said, what you're describing (with words) seems reasonable; with the code/math, it's hard to say (at least for me) whether you've overlooked something.

In fact, it seems like a bit too much code for it to be practical to find a bug just by reading the whole thing, particularly since the bug may well stem from the execution of one or more seemingly-trivial steps. Since you've already got the code broken down into smaller, more manageable chunks, have you already tried testing some of those smaller parts on some fixed input to see if you get results that are consistent with what you expect?

My prediction is that you'll find that some small part of your implementation just doesn't do what you think it does; my experience has always been that once I get done fixing problems like that, I've already gotten enough feedback that any fundamental logic errors become immediately apparent (either that, or things just work).

I find it instructive to start at the end of the pipeline and use comment codes to shut off everything. Comment out everything in the shaders, only have what is necessary to produce some form of output. For instance, have your vertex shader output only what is necessary to get it working, which is only position.

Now make sure that the fragment shader is outputting only color. If you get this far then you know that they are both setup and activated properly. Now start moving the comment codes and re-compile as you re-add a line or two at a time.

Also, you can setup a screen aligned quad and use this to display the shadow texture(s).

If this is the part where you see nothing but a white screen, then maybe try and adjust your camera's near and far settings. If you are using a very big spread between these two then maybe you are stretching out the z-axis enough to blank out the shadows. For example, if you are using near = 0.001, far 10000, then you might see nothing but a white screen for the depth texture. Try setting up some keyboard controls and adjust them starting at something like, near = .1, far = 100. Now if you actually can see the shadows, adjust them as needed.

Then again, I would suppose that some camera setups may not exhibit this issue.

Consider it pure joy, my brothers and sisters, whenever you face trials of many kinds,3 because you know that the testing of your faith produces perseverance.4 Let perseverance finish its work so that you may be mature and complete, not lacking anything.

When I did this, I validated each step before moving on. The first thing I did was draw a visualization of a frustum from an object's point of view, then I could move my camera around and look at it. Then I split it into 4 cascades and again draw each frustum split on screen.

Once you have that, then you know that's working and can move on to the orthographic projection step (which I rendered into textures and drew those as quads on the screen to validate those).

One thing I have noticed in the shader is that when I multiply by the combined light view and orthographic projection matrix for a specific frustum, the generated point is NOT in the range -1.0f to 1.0f in both the x and y.

This seems to be the problem. Isn't the projection matrix supposed to get the coordinates in these ranges? Has anyone else encountered this? Also if you do not think this is an issue won't it be an issue when the shadow map is sampled using these coordinates?