Pssm Shadows broke after update

Hi, I just updated the sdk and engine, and pssm shadows broke. Basic shadows which didnt work earlier now works somehow. The problem is that in the pre shadow pass, the geometry is rendered in wireframe mode. The debug displays shows shadow maps with wireframe geometry. Whats weird is that this doesnt happen with basicshadowrenderer, and from what I can tell they both use the same pre shadow material.

How do you set up your materials?

In that example, I dont set it up in code at all, all materials are set up in the j3o file. That exact example is a basic game with this in simpleinitapp to setup shadows:



Spatial scene = assetManager.load("Models/cg_inn.j3o");

Vector3f lightDir = new Vector3f(-1, -1, .5f).normalizeLocal();

DirectionalLight dl = new DirectionalLight();


dl.setColor(new ColorRGBA(1, 1, 1, 1));

dl2 = new DirectionalLight();

dl2.setDirection(new Vector3f(1, 0, -1).normalizeLocal());

dl.setColor(new ColorRGBA(.6f, .6f, .6f, 1));

PssmShadowRenderer shadowRenderer = new PssmShadowRenderer(assetManager, 1024, 3);

shadowRenderer.setDirection(new Vector3f(1,1,1).normalizeLocal());



shadowRenderer.setCompareMode(CompareMode.Software); // Using hardware here produces weird results too






Also, any reason why jme3 uses depth textures? These are known to be a bad idea for compatability in shaders, since the gl specification does not require a implementation to be able to support depth textures in shaders. The single component R32F texture format is preferred over depth textures when you need single component precision in the programmable pipeline, as its required to be supported if its available

Because you need to know the depth for many effects like fog, light scattering etc etc

The OpenGL specification required depth textures in version 1.4. They can be read directly by shaders. So I don’t see what the issue is.

@fredrikaxk do you use the built in lighting material?

also your shadows direction is pointing up, don’t know if that’s intended.


shadowRenderer.setDirection(new Vector3f(1,1,1).normalizeLocal());


@fredrikaxk said:
The single component R32F texture format is preferred over depth textures when you need single component precision in the programmable pipeline, as its required to be supported if its available

Preferred by who, when, in what case?
That may be fine in a deferred rendering process, but JME has a forward rendering process and we take advantage of the rendering pass to grab the hardware depth buffer.
The hardware depth buffer cannot be directly rendered to R32F, so it would need a buffer copy, and that's not preferred.

Yeah, the builtin lighting material is used. And yeah the direction is wrong, but in this case it doesnt matter. And reading up on it, using depth textures arent as bad as it once was. I remember it was a big issue on my old ati card way back. You couldnt use them for neither depth comparisons nor texture sampling in shaders, meaning they were tricky to use properly for shadow mapping with glsl. The best solution was to do the shadow mapping pass in the fixed func pipeline.

that’s strange…

Do you have some Alpha blending enabled on the model or something fancy in the additional render state?

Nothing at all. That example does nothing besides load the model, and use the predefined materials. Checking the materials in jmonkeyplatform, nothing that should result in this. It was all fine, then I upgraded the sdk, and it didnt work anymore.

could you upload the model somewhere so i can test?

Got exactly the same behaviour. The issue was on a custom mesh, CastAndRecceive; I too got only the wireframe outline of the mesh in the debug windows, and weird results (holes in the shadows, shadows on the lit side…).

However, as was mentionned in another post, this was actually due to hardware. I could compare the two following configurations with exactly the same code:

  • Not working:

  • Intel Core I7

  • Windows 8 x64

  • ATI Radeon HD4890

  • Drivers: Catalyst 11.6 (due to ATI having dropped support for HD4xxx -_-, I could not get the latest drivers)


  • Working fine:

  • Intel Core I5

  • Windows 7 x64

  • Intel HD Graphics Family

  • Drivers: Last version

Hope this helps!

Yeah i noticed the same issue when using the HARDWARE compare mode…

This issue remains to be fix.

If someone could guide me on what to check, I could provide more details in both the working and non-working case.

Did you try to set the Shadow mode to SOFTWARE?