OK made a little bit more testings :
Made shadows render in the lighting pass and, the result was not as great as I expected. Roughtly the same as the filter pass perfs a little bit lower.
This is probably due to the fact the shadow params are set on each material on every pass also there is something with the define that may imply that the shader is recompiled slowing things down…so basically I was a bit disappointed…
Then i realized that I was still feeding all the materials with the shadow params, even for the Filter pass… But ofc this is useless…Only the filter material needs them.
Removing this made the filter pass just stunning…
here is the graph
and the google spread sheet
https://docs.google.com/spreadsheet/ccc?key=0AsE_ydpoOkOhdF9MRjh4cUo1T3gwby1kaU1lcDhIX1E#gid=1
As you can see, as long as you have around 10 objects in the scene it’s faster like before, but around 50 shadowed objects the speed is doubled compared to current system.
I have to think of a workaround for being unable to disable shadow receive, but this thing definitely is a lead to follow.
I appreciate all the great work you are doing on the shadowing system, exciting times ahead 
What kwando said, I’m really looking forward to see the experiments with temporal reprojection. Currently I develop without shadows since the PSSM and basic shadows aren’t suited to my use case, open terrain and slopes really show off the temporal aliasing
Yes, i really like to see progress in this, especially since a good shadowing system is one of the last few basic things for a gameengine that jme still misses.
@nehon
Can you not post the code for this, and let the rest of us have at it? Maybe do some grunt work. This looks very interesting.
Rendering shadows and geometry in the same pass, then doing the post processing filter would be awesome for vegetation. I’m gonna do some experimentation.
@androlo it’s already in core.
You now have a PssmShadowFilter that you can use like any other filter.
Technically it wraps the PssmShadowRenderer and render the post pas as a fullscreen pass instead of a geometry pass.
usage is
[java]
//initialization of the filter is like the PssmRenderer
PssmShadowFilter pssmFilter = new PssmShadowFilter(assetManager, 1024, 3);
pssmFilter.setDirection(new Vector3f(-1, -1, -1).normalizeLocal());
pssmFilter.setLambda(0.55f);
pssmFilter.setShadowIntensity(0.6f);
pssmFilter.setCompareMode(CompareMode.Software);
pssmFilter.setFilterMode(FilterMode.Dither);
//add the filter to the fpp
FilterPostProcessor fpp = new FilterPostProcessor(assetManager);
fpp.addFilter(pssmFilter);
viewPort.addProcessor(fpp);
[/java]
You don’t have to, it’s in RC2.
What’s the advantages and disadvantages of this approach? (i.e. why would you ever want to do it as a geometry pass rather than a fullscreen pass?)
- If the hardware does not supports the post pass approach
- if you have less than 20 objects in your scene that’ receive shadows.
Ahh, unless they turn shadows to maximum (and cards start self shadowing) I rarely have more than 4 or 5 objects receiving shadows so this is one less thing to think about for now .