@jendrikillner Hey dunno if this passes the threshold for Graphics Programming Weekly as I don't have time to build an implementation but I wrote about an idea I had for improving virtual shadow mapping by moving into screen space - https://ratusapp.wordpress.com/2024/09/08/screen-space-shadows/
Screen Space Shadows

I recently had the misfortune of having to investigate a virtual shadow map corruption bug in Unreal and in the course of that investigation an idea struck me and I feel compelled to write it down.…

Ratus Apparatus

@1st_C_Lord
> You also have to emit a volume for each triangle in the geometry shader.

Isn't that just what shadow volumes (or stencil shadows) are?

https://en.wikipedia.org/wiki/Shadow_volume

The only new idea is that you would cull triangles using the HZB.

Unfortunately this technique is quite fillrate intensive, doesn't scale well to many lights, cannot cache the result of the shadowing, and cannot be filtered.

Shadow volume - Wikipedia

@fclem you're right, it's partly inspired by stencil shadows but it's a very different approach to generating the volumes which eliminates the problems you mention

@1st_C_Lord I don't see how that solves the lack of caching and filtering.

Since you do the raster from the camera view, I guess you would have to use some screen space blurring of shadows.

@fclem by filtering I assume you mean a penumbra, texture filtering has always been a terrible way to generate a penumbra, I would like to generate it analytically with this approach since in the pixel shader we calculate the pixel prism intersect to determine if it's in shadow, we can also solve the penumbra analytically here.
@fclem Caching is definitely an interesting problem and it's a problem that virtual shadow maps share since they are also largely in screen space and solving caching is where they get much of their complexity. I believe this approach will scale a lot better than light space rasterisation and will be less dependant on caching.
@fclem However there are 2 places where a cache may make sense, firstly a prism cache would mean we could skip most of the calculations for static object/light pairs and a screen space depth cache would mean we could reuse final shadows anything where the history buffer can successfully be reprojected into the scene (i.e. on screen objects moving in world space would invalidate it).
@1st_C_Lord @fclem Do you intend to generate a HZB for each light? If so, won’t you have to rasterize from light view? + generating mips and extra storage for each HZB
@thisarray @fclem yep, that's the idea but an hzb is much smaller than a frame buffer