I recently was experimenting with PSSM on my terrain and was getting those cracks that occur when doing self shadowing. I read online that VSM doesn't have this issue so much, so I grabbed nullsquared's great VSM soft shadow demo and then hooked it up with the PSSM demo. This code is really unrefined, but it seems to be working so maybe it will help someone.

Oh bother, I just realized that I didn't implement the gaussian blur pass to the shadow maps to soften the shadows! argh. Well my frame rate is hovering around 30fps now so I'm going to focus on optimizing for a bit, but it shouldn't be hard to add the blur like nullsquared did in his VSM demo.

It would also be very interesting to see how higher order filtering using Bezier or Catmull-Rom curves looks. The authors mention this as future work in the SAVSM article in GPU Gems 3. For anyone interested, a description of implementing higher order filtering can be found in Chapter 20 of GPU Gems 2, which is available online.

It would also be very interesting to see how higher order filtering using Bezier or Catmull-Rom curves looks. The authors mention this as future work in the SAVSM article in GPU Gems 3. For anyone interested, a description of implementing higher order filtering can be found in Chapter 20 of GPU Gems 2, which is available online.

GPU Gems 3 is also availible online...but not completly yet...they are working on it.

Hi,I try to use your shader in my scene, and it works fine, but it seems I have some problems using spotlight instead of point light: the shadows don't cross the limit between the split planes. I have something like this:

as you can see, the shadows break down suddently when they reach the first split plane.I also tried to change this line:mgr.sceneMgr->setShadowTextureCountPerLightType(Ogre::Light::LT_POINT, numShadowTextures);into this:mgr.sceneMgr->setShadowTextureCountPerLightType(Ogre::Light::LT_SPOTLIGHT, numShadowTextures);but I have the same problem...how can I fix that?

If i use manual split points, the default values are too distant so the scene is all in red (the first split-plane), and the shadows seem to be ok. If I decrease the distance between the points the previous problem rise up.If I use automatic split points, the problem remains.

petrocket wrote:so have you gotten it to work with a regular point light or directional light, or have shadows never appeared in the green and blue zones?

Hi, sorry for answering so late.Using automatic split points seems to work fine: thanks to your shader, now I removed all kind of light-bleeding artifacts in my scene. THANK YOU! Now I got this problem:

* Your shader is in GLSL, so it will run only in OGL mode, right? Now I want to add a technique to pssm_vsm_material that use shaders in CG language to add a compositor effect. I modify pssm_vsm_material in this way:

petrocket wrote:My guess is that CG might not allow declaring the parameter after shader compile like OpenGL is.Also, check out the original PSSM material script & shader in the Ogre Playpen folder/project. It was written in CG if I recall.

Hi,thank you for your hint: I'm currently working on the porting of your shader in CG using the PSSM shader in the Ogre Playpen folder as you suggest: it is almost ready, when I'll finish it I'll post the CG version in the forum.

A few month ago, when I tried for the first time your shader, I had a problem with the split planes. Lately, when I begin to study your shader code, I found again that problem, and that problem is also in the CG porting that I'm working on. It rises up if the light is created when the green or the red split planes (the 2 planes nearest to the observer) are displayed in the viewport.

This is the problem:When the observer is distant from the objects of the scene so that all the objects are in the blue split plane (the farther one) and a light is created in the observer position (1a), then the shadows are ok (2a/3a/4a), as you can see in this image:

But.. if the observer is near the objects of the scene so that the green and the red split planes are visible, the shadows seems to "live" in the split plane they are created. I mean: if we create a light in the observer position in (1b), the shadow of the nearest box in the scene (that is in the red split plane) will be visible only in the red split plane: we can see it if we move forward so that the red split plane cover the shadow area (2b/3b). In the same way, the spheres that are in the green split plane in 2b will cast their shadows on the walls only if we move forward so that the green split plane cover the walls.

I use the same shadow setup that is in the first post of this thread.I tried both with spot/point light - manual/automatic split points configurations, but the problem remains the same.

My guess is that somehow when you draw a shadow depth buffer - say the depth buffer for the green zone - and there is an object that is entirely in the red zone, the shadow depth buffer for the green zone does not include the object's that are not inside it because of some kind of bounding box culling. It is as if every time a depth buffer is rendered for a shadow zone it is culling objects that are outside the zone and there might be some way to disable this.

One thing you can try to determine if this is the issue is double the size of the bounding box for one of the objects (say the cube) so that the bounding box gets included in 2 zones even though the geometry only fits inside one zone.

Of course, this is just for determining if that is the issue. If it is the issue then somehow you need to figure out how to include the objects between the light and the zone.

I haven't looked at Ogre's pssm shadow / lipsm code in a while but maybe one of the ogre guru's on this forum know how the object/scene graph culling works when generating PSSM shadow depth maps.

petrocket wrote:My guess is that somehow when you draw a shadow depth buffer - say the depth buffer for the green zone - and there is an object that is entirely in the red zone, the shadow depth buffer for the green zone does not include the object's that are not inside it because of some kind of bounding box culling. It is as if every time a depth buffer is rendered for a shadow zone it is culling objects that are outside the zone and there might be some way to disable this.

I still can't solve this problem I'm trying to study how PSSM works in this thread:viewtopic.php?f=5&t=52013maybe someone can help me to understand if I'm wrong in what I wrote? I guess it would be very useful also to the other people that are still a bit confused about PSSM.

I am trying to implement PSVSM with cg, but i am using directional light instead of point light.I have problem when comparing depth stored in shadow texture with fragment depth from light in Shadow Receiver fragment program.When i compare both value, the fragment depth from light always smaller than depth stored in shadow texture (the chebysev inequality), thus my surface is always lit.What i want to ask is:1. how to get right fragment depth from light in shadow receiver? I assume that i could use post projection z value, but i dont know if its right2. how to know whether the depth value stored in my texture shadow is right? It seems right from the debug overlay.