• Advertisement

Some questions about cascaded variance shadow mapping

This topic is 700 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have been trying to implement variance shadow mapping, mainly based on various articles found around the net as well as Lauritzen's paper on it.

I have furthermore based this on previous code of my own doing "normal"/plain cascaded shadow mapping. The goal is to eventually move over to EVSM, but for not I'm trying to make the VSM part work properlt first. All in all, my implementation does work, though I've found a couple of questionmarks that I wanted to throw out there in case anybody would like to explain them.

 

First out is a visual artifact between cascade splits. This is described in the MSDN article on cascaded shadow maps under the heading "VSMs with CSMs: Gradients with CMSs": https://msdn.microsoft.com/en-us/library/windows/desktop/ee416307(v=vs.85).aspx

That article outlines the cause and a solution, both of which I think I understand conceptually at least. However I'm at a bit of a loss as to how to incorporate their solution into my implementation - my shadowing system calculates different light view matrices for each cascade so as to provide a tight fit around the scene camera's partitioned (cascade split) frustum. The MSDN approach seems to assume that all cascades use the same view matrix and just use further and further placed far planes for each split however. Is this a correct interpretation?

If so, I would rather not do this as it would waste a lot of shadow map space (the closer areas will never map to a further cascade after all). Could anybody perhaps point me in the right direction on how to adapt this to different view matrices per cascade? Of course my view matrices are all essentially the same, save for some floating point discrepancies in the 10^-8 range, except for the translation part. Maybe something can be made from that fact? But it still feels like the whole point is to use the same view matrix for all cascades such that the calculated positions will be continuous at all times?

 

 

Second is a question about using mip mapping with the shadow maps.

I do understand how this helps improve the shadow quality, but when coupled with cascades... won't the end result be that nothing but the first cascade will ever use the highest resolution mip? This seems quite wasteful. Is this supposed to be, and if so, wouldn't it be better to just render the further CSMs to smaller textures, which in turn would almost nullify the whole point of mip mapping (save for interpolation between the various mip levels of course) to begin with? Or are you supposed to provide some bias value for selecting higher LOD mips at greater distance for the further cascades, and if so, what would be a good way to figuring the proper bias values out?

 

 

Thankful for any advice.

Share this post


Link to post
Share on other sites
Advertisement

Thanks a lot for the very thorough explanations and code examples!

That all seems to make sense now and I'm looking forward to having a go at it when next I get some time off.  :)

Share this post


Link to post
Share on other sites

Got it working, thanks again MJP!

 

However I noticed one small issue that I'm unsure if it's "supposed to be" (ie. a result of the algorithm itself or something I've messed up).

For example, lets take a scene with some palm tree meshes; these have a relatively thin trunk. Using a smaller depth map size (1024x1024) to help further illustrate my point, these trunks will render as ~1 - 2 pixels wide at their thinnest to cascade #2. Obviously I'm not expecting stellar-looking shadows from this but still... So I build an EVSM from the depth buffer data; all fine so far. But then the weird thing happens when I apply a blur to the (RGBA32_FLOAT) variance map. In this example a simple 3x3 box blur is used.

What I expect to happen: the trunks will be blurred with their neighbouring (empty/infinitely far away) depth moments. This should reasonably result in the trunk still casting a (thicker) shadow that is more bright what with the mix with the adjacent pixels.

What actually happens: the map is blurred as intended (see the below picture) but the result when using this to sample shadows is that the trunk doesn't cast any visible shadow at all.

 

Now I wonder, is this how blurring an exponential variance shadow map is supposed to work? From what I've understood it isn't, but then again there isn't that much information about this that I've been able to find. If it isn't, any ideas what may be at fault? Or if it indeed is supposed to work like this, is there anything I may tweak to achieve more desirable results (besides simply increasing the shadow map resolution; the problem is that blurring essentially seems to reduce the shadow-affected areas (rather than increase them) regardless of map resolution)?

I'm imagining it may have something to do with the blurred moments resulting in a smaller variance than is recognized as being indicative of a shadow?

 

evsm_pre_post_blur.png

The exponential variance shadow map in question; the topmost is before and the bottom after applying blurring. The background colour has been manually set to yellow pre-blur and turqoise post-blur to illustrate the alpha component; these colours aren't in the actual shadow map.

Note that the blurred version doesn't translate too well since the source "colours" are outside the 0..1 range.

Edited by Husbjörn

Share this post


Link to post
Share on other sites

  • Advertisement