Right
I'd handle the gun case separately in practice as it isn't really a part of "scene" per se.
But if you are using a deferred renderer, doing the gun on a separate pass is not that elegant. You basically have to forward render it, and to be sure that the deferred rendering & lighting is not applied to those pixels (render the gun first to stencil buffer for example, or a lot of performance is wasted). You really want that the gun also receives the shadows, since it would look really weird if the gun shines fully bright, when the surrounding geometry is shadowed (you enter a small building in the terrain for example -- in our case the roofs also have some cracks letting the sun light in, but only partially).
Judging from your image, the best additional thing you could do is apply a warping to each shadow partition (log PSMs ideal of course, but liPSM or something is more practical). Of course warping the partitions complicates consistent edge softening assuming that you are prefiltering your shadow maps.
I was thinking about some kind of trapezoid warp, but unforunately it's not a linear transform (cannot be simply put in the light matrix & inverse of it), so it requires some extra math in both sides of the equation, and like you said causes other issues as well.
So curiously are there not cases where someone gets near large/semi-large objects (relative to the size of the player)? These cases are usually the ones that cause standard cascades to exhibit artifacts but indeed the ones that SDSM can take good advantage of by tightening up both the z-range and partitions.
Yes, there's some blocker geometry, but unfortunately in the most common case you see pretty far, since forest and trees are the most common view blockers, and their leaves always leave some gaps that allow you to see really far. In most games, you have linear paths though the levels, allowing the developer to put lots of huge view/movement blockers along the path. In our case, we have a world that allows you to move everywhere, as we have an in game level editor that allows you to fly over any geometry. Unfortunately for us technology guys, our artists tend to like levels that a located on top of some big (but thin) structures (a nice vertigo feel), and this kind of setting gives a huge visible view distance... but at the same time, the real game play happens very near the camera (so the near plane cannot be moved that far).
The terrain itself is of course a good view blocker, but it rarely cuts the z-max that much, since the horizon is often visible in the camera view. However it cuts the light space cascade z-max considerably, and that should improve the EVSM quality nicely.
The last nice advantage of SDSMs is of course avoiding tweaking of partition ranges/PSSM lambdas/etc. This is nice as it frees up some artist time and avoids problems late in production when cameras/scenes change after partition ranges have been set up.
I agree this is one of the key advantages in SDSM.
In any case sounds like it might not be a good fit for your scene, but the positive way to look at that is that your scene is already well-fit by standard CSMs
SDSM will help a lot in some scenes, but for the worst case scenes it only helps a bit (we unfortunately have a lot of worst case scenes - and have no control over it, since the player created content). SDSM is still a very good technique. It saves some artist work, and improves the quality and performance a bit even in the worst case scenarios. And naturally we develop our technology in a long run, so there will be future games that gain more from SDSM than our current one. I am pretty sure we will use the z-min / z-max system (it's really fast to generate on GPU, and the tight near plane alone improves the quality nicely), but the per cascade bounds do not seem that useful for us right now (but I'd really like to have the tighter z-bound for the EVSM). But let's see how it goes.
