Wrong shadows (PSSM)

Hi guys,

I’ve created a PSSM-ShadowRenderer to calculate the shadows of a custom mesh generated out of boxes. This is how it looks:

(I let the programm draw the wireframes, so you can see, that the mesh itself is ok ;))

http://img6.imagebanana.com/img/q3oj83ov/jME3ShadowsWrong.jpg

If I use single boxes instead of the merged mesh, the shadows are computed right:

http://img7.imagebanana.com/img/v8tft6nj/jME3ShadowsRight.jpg

This is the shadow renderer I’m using:

[java]PssmShadowRenderer shadowRenderer = new PssmShadowRenderer(assetManager, 1024, 3);

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

shadowRenderer.setLambda(0.55f);

shadowRenderer.setFilterMode(FilterMode.Nearest);

shadowRenderer.setCompareMode(CompareMode.Hardware);

viewPort.addProcessor(shadowRenderer);[/java]

The mesh itself is, as I already said, ok. Its ShadowMode is CastAndReceive.

Thanks for every answer and I hope, you can help me.

destro :slight_smile:

Not sure I can help with your issue but it seems hard to understand what we’re seeing in your screenshots, at first I thought the top one was the one rendering correctly.



I’m doing something similar (“generated single mesh” casting shadows onto itself) and while Pssm does have it’s quirks, it is working for me… but I have very different config. This is my latest:



[java]

pssmRenderer = new PssmShadowRenderer(app.getAssetManager(), 4096, 1);//4096 is probably too high for you, and 1 might be low…

pssmRenderer.setDirection(new Vector3f(-0.8f, -0.2f, 0.7f).normalizeLocal());

pssmRenderer.setEdgesThickness(6);

pssmRenderer.setShadowIntensity(0.125f);

pssmRenderer.setCompareMode(CompareMode.Software);

pssmRenderer.setFilterMode(FilterMode.PCF4);

app.getViewPort().addProcessor(pssmRenderer);

[/java]

Nope, the same problem with your configurations. :frowning:

(These shadow “rectangles” all over the mesh, which shouldn’t be there :smiley:)



Anyway, thanks for you help! :slight_smile:

Could you show the mesh without shadows and without wireframe? Also, is lighting enabled on the meshes?

maybe here is connection with my topic( http://hub.jmonkeyengine.org/groups/graphics/forum/topic/shadow-problem-1/ ) and this topic.

When i do castAndReceive on terrain i get:



http://img847.imageshack.us/img847/2743/terrainshadow.gif



This “white places” are not changing(i move camera and white(not shadow) places was still without shadow). sorry for english



Maybe this problem is becouse of hardware… im not specjalist in this :frowning:

maybe someone clever will tell the truth for us both



destroflyer: if you can do testcase for tabriel it would be great :wink: If it will work on his computer, then it means it is hardware/libraries yes?

I made some testings and pssm works fine with batched geometries, There must be something else in your code.

We would need a test case to go further.

Try using 4 instead of 3 planes for PssmRenderer (last parameter).



For me, if I use something else than 4, I can see a shadow ‘punchcard’ made of letters (probably from text node texture). I was wondering for some time, then gave up and decided 4 is good, round number.

Could you show the mesh without shadows and without wireframe?

This is the mesh without any shadows, filter effects (bloom, depth of field, fog, water, …) and all those nice looking stuff. :smiley:

http://img7.imagebanana.com/img/oohqan4m/jMEWithoutShadows.jpg





Also, is lighting enabled on the meshes?

No, it’s an Unshaded material - I’ve tried Lighting, but with the same problems… :confused:





destroflyer: if you can do testcase for tabriel it would be great :wink: If it will work on his computer, then it means it is hardware/libraries yes?

I made some testings and pssm works fine with batched geometries, There must be something else in your code.

We would need a test case to go further.


I’ll try it - The code is very complex at all (generation of the mesh, several classes for world objects derived from Node, data storage, …).

If I can make to simplify it to a smple test case, I’ll post it as fast as possible - I’ve created a few cms’s on my own and I know, that test cases are the best way to fix problems (instead of just a description, sorry for that :()





Try using 4 instead of 3 planes for PssmRenderer (last parameter).

Didn’t work, too…





I’m looking for the test case. Anyway, a big thanks for your many answers and helps! :slight_smile:

Not a testcase for me really, I think nehon’s the expert on this topic, I’m just a stooge. :stuck_out_tongue: But I can generally help test and troubleshoot here…

I have had issues in the past with PSSM and various combinations of other Post Processes, not sure why, having PSSM as the only Post fixed these issues (they eventually went away) - I say this because it looks like there is DOF (well some blur) in that screenshot, you said you turned it all off, I just wanted to see if you are actually turning all post effects off while testing PSSM and that none are left on by accident, it can happen.



Like @tebriel In my current project with working PSSM I have used compareMode.Software not Hardware (I think i may have tried that and failed).



The first couple of screen shots looks like a shadow map being applied to incorrect UV coords - @nehon do you think this could this have anything to do with it ?



You could try adding pssmRenderer.displayDebug(), it may help figure what the PSSM is thinking.

Make sure your PSSm renderer is added before the filterPostProcessor, just to be sure, i don’t think it’s the issue.


thetoucher said:
The first couple of screen shots looks like a shadow map being applied to incorrect UV coords - @nehon do you think this could this have anything to do with it ?

Shadows are not UV mapped, they are projected textures using the light matrix. In the case of PSSM there is one matrix per split. So no matter the UVs of underlying mesh it should work...that's a very strange issue
Make sure your PSSm renderer is added before the filterPostProcessor, just to be sure, i don’t think it’s the issue.

You just did my day! :D
This was the issue - I've been initialitzing the FilterPostProcessor before the ShadowRenderer. Therefore, the shadows were computed wrong..
Thanks for your hint. :)

EDIT: I think, it was the DepthOfField-Filter. (Just for your information, if you want to check the compatibility, when added before ;))
nehon said:
Make sure your PSSm renderer is added before the filterPostProcessor, just to be sure, i don't think it's the issue.

I was completely sure that was the issue!!! mhhh...that was just modesty..... :p

Actually it makes sense, the shadows were probably projected on the full screen quad instead of the geometries of the scene....

We should add some way to be sure the processors are correctly ordered....or maybe that just good practice that people has to know...