Issues with DirectionalLightShadowRenderer rendering shadows

I’m running the test program, TestDirectionalLightShadow, and I seem to be having issues with the shadows that are appearing on my models in the scene. I’m not sure if this is typical behavior or not but on all of the backsides of the spheres there are strange shadow artifacts (you can see it in the top right corner of the sphere in the picture below). In addition, moving the camera close to a sphere will reveal horribly shaded seams in the model.

Again, I’m not sure if this is default behavior or not but if anyone could confirm whether this is a bug or not that would be great.

Hi there!

I just tested it, looks the same to me. You can improve it a little bit by changing:




But this result could also be gained by pressing “f” to change the RenderMode.

EDIT: In my case it’s an Nvidia-Card… a 560GTX with the newest driver. Just to have it compete.

By the way, my artifacts look a little bit like there were hairs, not like in the picture above, where they seem to be square :smile:


I had artifacts in this Test demo with my old ATI card (it’s from 2009).
The OpenGL driver did obviously not work well with jME.
My new computer with an NVIDIA card from 2013 doesn’t have shadow artifacts.

So the consensus is that this artifacts are driver-related issues…? Is there anyway to go about handling this through software?

I don’t know if it is driver-based. I think these artifacts could also be software-related. Maybe it is a “optimizing-issue” :smile: I will explain: As far as I know, (our, not all!) shadows are generated by casting a ray from the light source through the object to collide somewhere, where the shadow should appear (Not the complete shadow, only one point of it). This is made a few times per object (depends on the size). To gain higher resolution shadows, you would have to send more rays… and that’s what I mentioned above. Maybe in the demo there is only a basic-setup and to improve it, you have to go into it and optimize it for your needs. For me, the PCF8-solution is good enough, but I’m not a professional.

PCF 8 gives very bad results indeed on your card…
I have this

Note that the pattern will always be worst on solid colored geometries than on textured ones.

you can aleviate those patterns to some extend by playing with the number of shadow maps (default is 3 in the test)
and by reducing the lambda values (default is 0.55 in the test)

Here in this shot, there is 4 x 1024 shadow maps and lambda is 0.3 (still PCF8).
You can see that the transition is a lot smoother.
I recommand to use PCFPOISSON as it’s a lot faster and gives result almost as smooth as PCF8.

In case you wonder, and just to expalin what Lambda does :
It defines how the shadow map are distributed in the camera frustum. Labda goes from 0 to 1. With a low value, you’ll have more definition on the first split (the shadow map clostest to the camera) but lower definition on farthest splits.
That’s because the first shadow map will cover a smaller area than the others.
The draw back is that the lower lambda is, the more obvious will be the transition between the splits.
You can try to play with it to see the difference.

Sorry but that’s not at all how it’s done.
Our dirrectional shadows are standard Parallel Split Shadow Maps (PSSM). You can probably read on it on google.
The idea is to split the frustum in several area and use one shadow map per area.
Each split is using standard shadow mapping that is : rendering a depth map from the Light point of view, then using this depth map in a shadow pass from the main view and test depth to know if the pixel is shadowed or not.

1 Like

It wasn’t meant as a complete solution! I just wanted to clear up, what I meant by “optimizing-issue”. To cover all aspects of shadows, it would have taken to long to write it down :wink: I wanted to keep it short.

Thanks for the interesting post! As I said above, I started with the PCF8 and it was enough for my needs. I haven’t tested much more by now. But sounds interesting, I really have to google for these PSSMs.

Is there a reasonable solution that transcends the issues of driver-related issues? Should I write my own shader?