In-pass shadows (WIP)

[shadowislord]

This is the PR implementing in-pass shadows as shown in the April 2016 screenshot thread: https://hub.jmonkeyengine.org/t/april-2016-monthly-wip-screenshot-thread/35512/128

How it works: PreShadowArrayRenderer is responsible for generating a texture array containing shadow maps for every light that should be shadowed. Directional lights use PSSM with 1-4 slices, spot lights use 1 slice, and point lights will use 6 slices (not implemented yet). The information of which texture array to use and the slices is represented in the ShadowMap interface. This is then associated with the light so that later it can be retrieved. When the scene is rendered, ShadowStaticPassLightingLogic is the TechniqueDefLogic implementation that is capable of rendering in-pass shadows. The light types are statically known which allows the shader to avoid control flow. It works similarly to SinglePass, except that the lights are first sorted by type and then their counts are known statically, so instead of this loop:

for each light do ...

It becomes

for each directional light do ...
for each point light do ...
for each spot light do ...

This then allows using different logic depending on the light type. The way shadow maps are fetched varies depending on the type of light, which is why this is required.

Theoretically, if we have control flow in the shader then we don't need to know the light type in advance and we can calculate the slice to fetch per each light. This is probably how in-pass shadows will be integrated with the rest of the lighting shaders.

TODO:

• [x] Point light support
• [x] Remove / fix the hacks from ShadowUtil
• [x] Remove all the static lighting crap

Optional:

• [ ] Port the old shadow renderers to the new system
• [ ] Implement and test PSSM-only in-pass shadows
• [ ] Test on OpenGL ES 2.0

[shadowislord]

1. Yes I have it... It kinda crappy though so I am going to clean it a bit and commit later
2. So the challenge is supporting any light type in the shader without knowing its type statically. Unfortunately this is more complicated so I took the easier route initially where all types are known ahead of time. Theoretically the shader is faster but due to the large number of shader permutations it causes micro-stuttering when the shader variants are compiled. Supporting arbitrary light types requires several passes where first the shadow slices to fetch are determined (based on NB_LIGHTS) and then fetching them. The next part is using those results in the lighting loop.
3. Not sure what you mean by renderer. Generating the shadow maps is handled by PreShadowArrayRenderer and then later they are used by ShadowStaticPassLightingLogic.
4. I will update the description ...

[empirephoenix]

What is the state of this one btw? is this still alive?

[shadowislord]

@empirephoenix It breaks backwards compatibility, mainly with custom lighting shaders. Also there are some significant core changes that require user testing. Might make sense to include in jME 3.3