Implement an Sample-Distribution Shadow Mapping filter

[ScottPeterJohnson]

Sample-Distribution Shadow Mapping (SDSM) is a technique for dynamically fitting the shadow maps of a shadow filter to the depth samples that will be needed, resulting in improved shadow quality.

This commit adds the option to use a SdsmDirectionalLightShadowFilter in place of a regular DirectionalLightShadowFilter. Usage requires GL 4.3+ support.

I don't think this is 100% ready for merging immediately, but it does work. I've been told there might be code for compute shaders coming, in which case this can be adapted to use that instead of somewhat kludgily inventing its own wheel. There's a lot around handling specific GL 4.3+ APIs (for example this needs compute shaders) that I'm not sure how engine wants to do it.

Mentioned on the forums here:
https://hub.jmonkeyengine.org/t/reducing-shadow-motion-issues/49289/3

Included is a TestSdsmDirectionalLightShadow sample app. I was using a stripped down version of the Sponza model to test lighting, but it's still pretty big and it didn't seem like large test data gets included in PRs. It's available here, and goes in the jme3-examples directory alongside "town.zip": https://drive.google.com/file/d/18mmwRPe--gskuWjfBfv9nB-dCSzfa1eB/view?usp=sharing

Example with SDSM:

Example without SDSM:

(Note that some parts of the translation from Kotlin to Java I delegated to Claude Code, so if there are still some uselessly verbose parts I didn't catch those can be fixed.)

[codex128]

Sorry this took me so long.

[codex128]

Pulled this branch and ran the test. Worked flawlessly and looks absolutely amazing!

[codex128]

I've been told there might be code for compute shaders coming, in which case this can be adapted to use that instead of somewhat kludgily inventing its own wheel. There's a lot around handling specific GL 4.3+ APIs (for example this needs compute shaders) that I'm not sure how engine wants to do it.

Full engine compute shader support would require a setup similar to Material with proper uniforms, defines, versioning, etc. That is a lot of work and Material itself is pretty well baked into the vertex pipeline. Probably best to work with the limited support this PR offers until jme4 rolls around.

[codex128]

This all looks good to me.

The only thing that should be done now is to have ComputeShader, GLFence, and ShaderStorageBufferObject extend NativeObject.

[ScottPeterJohnson]

Should now be NativeObjects.
(The only slight complexity was in GlFence and SSBO; GlFences actually have long addresses not ints, and both can't be meaningfully "restarted" with the display, as NativeObjects seem to be designed for. Fine for our use case anyway.)

Possibility for future work: If you turn the camera fast enough in the demo, you get shadow flicker along the edges (as expected, the slightly old shadowmaps don't contain all the samples if they're a few frames behind and you're spinning like a madman.) Currently the setup for out-of-shadowmap sampling returns "unshadowed", but "assume shadowed" might actually be better for that case, since a momentarily dark part of the screen might be less jarring than a momentarily bright one.

[codex128]

@ScottPeterJohnson thank you for this contribution, this will be included in the next release.