A while ago I already posted a couple of snippets improving the quality of the existing PSSM shadows within the gamestudio templates.
Looking at that code again I found a couple of issues and things to improve.
I also plan to include point and spot lights at some point.

PSSM Improvements (so far):
- No flickering if the camera moves.
- Slightly tighter frustums resulting in slightly improved shadow resolution.
- Kinda hacky, but still a lot better biassing using depth derivatives.

The biggest still existing issue is the way the shadows are mixed with the scenes shading, which is just totally wrong, but this should be handled in custom shaders for the scene objects and is not really part of this.

You can get the code on github.

Here is an ugly screenshot of my testlevel (the worst way to present shadows is on untextured cubes...):

hi Slin,

I found "shadow_stencil = 8;" mode very slow in real outdoor environments (no difference in small test levels), comparing to solutions when no stencil buffer used, I would really prefer an object shader based solution instead, with "shadow_stencil = -1;". It would eliminate some issues with 32b textures (it is really disturbing when an entity has both 32b and 24b textures).

As I remember txesmi had a contribution where he made it with pssm (combined with a deferred version)...

Thanks slin!
But I got some problems with it, same as with standard pssm shadows
Actually the shadows overlap my ZNEAR weapons and the TRANSLUCENT entities overlap the shadows

sivan, it is mostly about the improved split calculation and nobody stops you from using the exact same shadow code in your object shaders. A depth prepass might also be a good idea, or just render depth, normals and textures and everything else you need into multiple render targets and do some deferred shading. There are pros and cons to everything, a deferred approach (or maybe even light prepass) might be the most performant with gamestudio though (with newer DirectX and OpenGL versions you can do some really nice stuff with reusing depth buffers and providing lots of data to shaders in a fast and comfortable way).

Ch40zzC0d3r, those issues are not really related to the shadow. ZNEAR renders an object in front of things while it really is behind. The only solution for that is to not use znear and solve the issue with weapons inside walls by not allowing the player to get that close to the wall, at least not in a way the weapon could pass through it.
Transparent things in general are problematic in real time rendering due to the way sorting is solved with a depth buffer. So if you happen to have some translucent entities that need to cast shadows, there are solution for it, but they tend to have some restrictions. Receiving shadows should be fine though?

Thanks for the answer!
I nearly fixed the bugs, only one is left.
I have a normalmapping object shader and when I apply the material then the shadows overlap my weapon. They dont overlap with default object shader. Any ideas? I can also post the code of it if you need it

Neat!

I know its essence is the new split calculation, I use it already in MapBuilder, really nice and flicker-less. I just tried to convince you to not to use the stencil buffer in 3DGS. I think I will implement it and make a fork on github.

I took a deeper look at my object shader and came to the conclusion that the bone animation shader is the one which puts the shadows infront of my models.
But why those 2 lines change the depth of the zbuffer?



EDIT: Also the shadows created by those GPU bone animated models are wrong. The shadows dont have any animation

sivan, I know that you used that old snippet, but it had some issues I fixed in this version. And I know that the stencil buffer approach sucks, but it has the advantage of just working good enough for most people here. Everything else needs too much of a custom rendering approach for most people to handle.

Ch40zzC0d3r, in vp_depth.fx and also in vp_pssm.fx at the top is an uncommented #define BONES, just make sure that define in set in both shaders and it should work fine with bone animations. The difference is that the DoBone will apply the bone transformations in the vertex shader to each vertex, to actually make the model animate. So without it, it will generate depthmaps and shadows as if the models would not be animated.

Cool! Thank you Slin!