Not sure whether there already is a way to do this or it would need to be added, but: I’m trying to customise the shadows cast onto my material. In my concrete example that would mean clamping the darkest a color can get. From what I understood, the only way to get even remotely close to this is overriding the whole PostShadow pass for my material and calculate all the object colors in there again for each pixel, then calculate shadow, blend and apply the clamping. That’s an awful lot of calculating what has already been calculated.
Now imagine your main material shader would already get the per fragment shadow information as a global uniform (something like g_LightColor or the others) and could use it to calculate the final lighting. That way a shader writer could have all the control over how the shadows are blended and how they end up looking. This would probably move the whole shadowing process from being a post frame to a pre main frame process. Is all of this a good idea? Why (not)? How would one go around to implementing it?
The only problem is that you are going to need the scene depth for the shadows, so you will end up having a pass that renders the depth for the shadows, then you are going to render the shadows and then the actual materials.
It’s much more flexible than what is done now, but you are going to waste some resources rendering the initial depth pass. (i think it’s worth it, expecially since you can use that depth for other things ((eg if you were to implement occlusion queries)) and you can render both depth and shadows using a lod level to reduce the number of vertices in those passes)
I’m not sure I follow what you are trying to do but there may be a misunderstanding about what is happening.
The per object camera rendering pass for shadows is essentially just marking what is/isn’t in shadow from the camera’s point of view.
From there, you can either lay shadows per-object/per-camera (which I think is what the post pass is doing) or somehow collect all of the shadows together and render them in one pass. And note that the shadow filter I think just does this all in screen space as one big pass per light.
So from what I think you are suggesting, the above implies a list of values unless you are thinking about multipass lighting… in which case you are going to have other issues trying to clamp, I think.
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
Aside from backward compatibility breaking, my implication is that it’s already in a working state and needs testing. But as said I might be wrong.