It’s still on my TODO list i just didn’t have a lot of time lately.
I think i did the changes to set a texture array but couldn’t figure out how to render depth to a specific slice of the depth buffer (only found something involving geometry shaders).
Also i was having an issue with instanced meshes only casting shadows if the original mesh was visible to the shadow camera.
@methusalah
Well the code is on github and should work, but only with a single shadow casting light.
My google skills found this: https://www.opengl.org/wiki/GLAPI/glFramebufferTextureLayer
I made the changes in the core and with this i can render the depth buffer into the specified layer in a texture array.
Already got it working again with a single light.
Now it’s time to figure out how to make this stable, easy to use and fast.
My current thoughts are: a properly sorted list of lights and three texture arrays because point, spot and directional shadows use, in my experience, very different resolutions.
I’ll have to figure out how to do light culling (easiest would be to always render the shadow casting lights, for all spatials receiving shadows, but i really want a proper solution). The problem here is that i can’t really change the shadow array so if a light is missing for a spatial i would have to skip the shadowmaps for that light, not really difficult but it might be faster to just render the light anyway instead of skipping it.
The other thing I have to do is document my changes to the jMonkey core for glFrameBufferTextureLayer and make a pull request (but I don’t see a problem there, it’s just a few things added and no existing code changed)
I think i have most things working in a reasonable way now.
In this screenshot is one directional, three point and four (yes four) spot lights with shadows and four more point lights without shadows. (if too many shadow casters are declared the shader won’t compile at some point)
Here are the changes i had to make in the engine:
One part are array textures as render targets and the other part was fixing a bug with shader generation.
The multiplicity for array variables was ignored in some cases, so i fixed that.
If there are no objections i will make a pull request.
The Shadow renderer can still be found here:
I created a new shadow renderer which handles all light types, a maximum number and resolution for each light type needs to be specified.
I would like to change the need of a special shadow material, currently i’m using it to set the number of lights already rendered, which is used in the shader to evaluate the correct shadow map for each light.
I’m also using a special light filter which will sort the shadow casting lights to the front in a specific order, but i don’t see a way around that.
Currently there are no special shadow filters available. (Filtering is somehow broken for spot and point lights anyway, but i didn’t look into that yet.)
Then i have a bunch of material parameters which are used by the shadow renderer and it would be nice if the user using the shader node would only have to connect the parts which actually interact with the rest of the shader,
maybe declaring material parameters as part of the shader node or something.
If someone wants to try it i hope i was succesfull in using gradle, it should be only necessary to perform a gradlew install with my engine changes and then the shadow project should work. (I’m using a nvidia 670m card with windows, so I’m fully expecting this to not work at all with AMD and/or OSX )
Is anything happening with this? It looks like a really nice improvement. I see the engine changes pull request went through, but the PreFrameShadowRenderer project has a few errors that suggest the implementation has since drifted.
The PR only contained the core modification to be able to implement the renderer
The renderer is in another repo.
Kirill is working on a renderer that is in the experimental branch of the engine I think