• Advertisement
Sign in to follow this  

Make shadows smooth by bluring - problem?

This topic is 3624 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 written some code for generating shadows, but shadow volumes and shadow mapping. However, I want to blur the shadows to make them look smooth (and to eliminate some aliasing from the shadow mapping). A gaussian blur-filter seems nice, but I have one question. How can make sure that the bluring doesnt exeed the polygon-edges (i.e. that triangles that are not in shadow at all get's a little darker because they are next to shadow on the scren)? I thought that maybe I could use e normal-buffer and the depth-buffer or something like that. What is the best techique?

Share this post


Link to post
Share on other sites
Advertisement
Honestly you really don't want to blur in screen-space for the reasons that you mentioned. No matter what you do you'll run into problems, not to mention that what you want to be doing is anti-aliasing, not blurring. To that end, look up shadow map filtering techniques like percentage closer filtering (PCF), variance shadow maps (VSM), convolution shadow maps (CSM) and exponential shadow maps (ESM). For shadow volumes, you're unfortunately kind of stuck unless you want to super-sample in screen space.

Share this post


Link to post
Share on other sites
Thanks. Which one is to prefer? I dont really understand how they make shadow mapping look good in games and so on, I think it's so much tweaking and artifacts. But still it's the most used method right?

Share this post


Link to post
Share on other sites
Well I'm naturally a bit partial to variance shadow maps and exponential shadow maps ;) That said what you want to do to get good shadows is to combine a good filtering scheme (like VSM or ESM) together with a good frustum partitioning/warping scheme. I've had a lot of success with Parallel Split Shadow Maps (aka Cascading Shadow Maps) together with Variance Shadow Maps, but feel free to mix and match to suit your application.

Share this post


Link to post
Share on other sites
I think screen space blurs can look fine if done carefully. All soft shadow methods that are fast have some drawbacks, inclusing VSM. It just depends, do you rather buggy-looking VSM (i've never seen it not look buggy, sorry) or somewhat incorrect screen space blur..?

Screen space blurs can be dont nicely and are very simple and straight forward to implement. If you have access to the depth buffer in your final pass you can control edge bleeding a bit by not blurring at places with high depth discontinuities.

If you use a high enough resolution shadow maps with some kind of warping, just standard hardware PCF can almost look good enough...If you do a subtle screen space blur it can be all you need. Remember you cant use VSM with hardware shadow maps.

Share this post


Link to post
Share on other sites
Quote:
Original post by Matt Aufderheide
All soft shadow methods that are fast have some drawbacks, inclusing VSM. It just depends, do you rather buggy-looking VSM (i've never seen it not look buggy, sorry) or somewhat incorrect screen space blur..?

If you're referring to light bleeding, that's certainly a big problem for many scenes. In addition to the light bleeding reduction stuff in GPU Gems 3, however, we now have Exponential Shadow Maps (check out ShaderX6), Layered Variance Shadow Maps and Exponential Variance Shadow Maps (paper that covers these two to be online in a few days - published at GI 2008) that all address light bleeding. In fact with the recent explosion of work in the area I'm fairly confident in saying that an adaptive techniques based on the linear/probabilistic shadow map filtering approaches (VSM/CSM/ESM/EVSM/etc.) are the most promising direction moving forward.

Quote:
Original post by Matt Aufderheide
Screen space blurs can be dont nicely and are very simple and straight forward to implement. If you have access to the depth buffer in your final pass you can control edge bleeding a bit by not blurring at places with high depth discontinuities.

Sure but it's not just the halos that are a problem. You're also blurring in entirely the wrong dimensions. While this isn't necessarily crippling if you're using tiny blurs, you can't use it to get any significant edge softening. In fact I believe World in Conflict uses a similar approach and if you actually zoom in and check out how their shadows behave it's a mess. I mean no offense to the game (it looks quite beautiful in most ways), but the shadows do some really strange and ugly things.

Quote:
Original post by Matt Aufderheide
Remember you cant use VSM with hardware shadow maps.

Sure, but there's no such thing as "hardware shadow maps" anymore. The concept of "lookup with compare" is properly a shader instruction now, and may well be implemented using four lookups/compares. The underlying hardware isn't doing anything magic here, so don't get the impression that you "should be using hardware shadow maps" for some kind of mythical speed gain anymore.

Share this post


Link to post
Share on other sites
Myself, I use standard variance shadow maps. In fact, I had great success with them - no light bleeding, very attractive. I did a demo for Ogre, demonstrating "real-time soft self shadowing shadows" ([lol]) because Ogre had a bit of a crippled shadow demo in terms of shaders (though it did demonstrate stencil/projective shadows well): http://www.ogre3d.org/phpBB2/viewtopic.php?t=39809. It's open source, check it out if you wish.

Share this post


Link to post
Share on other sites
I would say you've not done yourself justice on a few of those screenshots, I would try creating a more light scene which is more open so you can truely see the quality of your shadowing. Its a slight criticism, I think you could demonstrate those a lot better, and lets be right about this, the shadowing looks fantastic!

Share this post


Link to post
Share on other sites
Quote:
Original post by AndyTX
Sure, but there's no such thing as "hardware shadow maps" anymore. The concept of "lookup with compare" is properly a shader instruction now, and may well be implemented using four lookups/compares. The underlying hardware isn't doing anything magic here, so don't get the impression that you "should be using hardware shadow maps" for some kind of mythical speed gain anymore.


This is not accurate in my experience. First, using hardware shadow maps allows you to render to a depth texture, rather than a floating point buffer. In DirectX 9 there is no other way to do it. Depth texture are significantly faster than floating point buffers.

Plus doing the 4 lookups and the filtering in one call is simply faster and easier. So the hardware IS doing something "magical". From the Nvidia GPU programming guide:"Because dedicated transistors exist for hardware shadow mapping, you will lose performance and quality if you try to emulate our shadow mapping algorithm with ps_2_0 of higher."

Maybe you can argue this is marketing hype, but the curcuits are there and they work. Crysis uses hardware shadow maps for eveything but the terrain shadows which opt for VSM as I said. The terain shadows are large and blurry. I imagine under Dx10 the situation may be different, but in Dx9 hardware shadow maps are a clear win. Also, you can do extended PCF by doing more than one hardware fetch which is still fast.

The point of screen-space blurring is not to get proper penumbras but to reduce aliasing. Just because it's physically incorrect doent mattter..shadow mapping is also physically incorrect--light is not a discrete array of photon-pixels. I appreciate your work on VSM, dont get me wrong, and that new stuff you mentioned sounds interesting.

Share this post


Link to post
Share on other sites
Quote:
Original post by Matt Aufderheide
This is not accurate in my experience. First, using hardware shadow maps allows you to render to a depth texture, rather than a floating point buffer.

You can use 32-bit float depth buffers to get all of the same advantages.

Quote:
Original post by Matt Aufderheide
Plus doing the 4 lookups and the filtering in one call is simply faster and easier. So the hardware IS doing something "magical".

Certainly bilinear lookups w/ compare are useful for PCF, but my point is that they don't need to be used with "shadow textures" anymore. They work with any one-component texture format. In fact, there are no special shadow texture types anymore since they don't really do anything "special" as I mentioned. All of the special functions are really just different ways to render and lookup into textures, which are properly generalized now.

Indeed your original point was that "you can't use hardware shadow maps with VSM" and my response is basically "yeah, but that's because you don't need to..." You can use standard bilinear filtering (and mipmapping, etc. etc.) with variance shadow maps which will be at least as fast or faster than SampleCmpLevelZero or similar. Once you consider that achieving similar shadow quality to VSM w/ hardware MSAA would require more than 4x the shadow resolution and at least 4x the PCF samples, VSM starts to look like the more efficient technique, albeit with trade-offs of its own.

Regarding hardware, I suspect NVIDIA still has hardware to do bilinear PCF as you note (so do use SampleCmpLevelZero for PCF, of course!), although AMD cards almost certainly implement it in terms of Fetch4, which is a more general concept.

Quote:
Original post by Matt Aufderheide
The point of screen-space blurring is not to get proper penumbras but to reduce aliasing. Just because it's physically incorrect doent mattter..shadow mapping is also physically incorrect--light is not a discrete array of photon-pixels.

Oh it has nothing to do with physical correctness... as you note none of this is physically correct. My point is actually that blurring - particularly in screen space - is not anti-aliasing and thus doesn't address the problem at all. Indeed if you have something like foliage casting high-frequency shadows on the road in front of you, you get a big aliased mess without filtering, and blurring actually just exacerbates that by giving you a big, flickery, halo-y mess. Check out Crysis actually - since they're not doing any "proper" filtering on their normal shadows, they degenerate badly in these cases. I can get a few shots if necessary but it's very easy to see yourself.

Quote:
Original post by Matt Aufderheide
I appreciate your work on VSM, dont get me wrong, and that new stuff you mentioned sounds interesting.

I'll try to get the new paper online today if possible. It covers Layered VSM and Exponential VSM, the latter being more interesting and practical moving forward I suspect, although the former is quite interesting for quality scaling of VSM.

Share this post


Link to post
Share on other sites
Quote:
Original post by AndyTXYou can use 32-bit float depth buffers to get all of the same advantages.


What do you mean by 32-bit float depth buffers? Just regular depth stencil buffers? The only way to read those in Dx9 is to use hardware shadow mapping, unless i'm mistaken..

Obviously i can use R32F but these are slower, plus doesnt VSM require writing to more than one channel..unless you've changed the basic algorithm since i last implemented it...Maybe I'm missing somehting here...

Also, one of the chief advantages of VSM is that you can blur the shadow buffer before you do the comparison, I assume you've tried this..blurring a large floating point texture is slow on even my Geforce 8800.

Thanks for the help ...





Share this post


Link to post
Share on other sites
Quote:
Original post by Matt Aufderheide
What do you mean by 32-bit float depth buffers?

I mean that DXGI_FORMAT_D32_FLOAT is a valid resource format for which to create a DepthStencilView. Not sure how this works in DX9, but the hardware certainly can use true 32-bit float depth buffers (rather than 24-bit fixed+stencil).

Quote:
Original post by Matt Aufderheide
Obviously i can use R32F but these are slower, plus doesnt VSM require writing to more than one channel..

I'm not sure that R32F is significantly slower than 24-bit fixed-point on newer hardware (DX10 class). Regarding multiple channels, yes you do need two channels for variance shadow maps, but the second channel can be generated in image-space if it's critical to get the double-speed depth-only rendering during the shadow map generation pass.

Quote:
Original post by Matt Aufderheide
Also, one of the chief advantages of VSM is that you can blur the shadow buffer before you do the comparison, I assume you've tried this..blurring a large floating point texture is slow on even my Geforce 8800.

That's slow for you? Hell I can use ridiculously large and impractical blurs (of the order of 50x50!) and still get good performance. Certainly the performance is significantly better than PCF (for which blur filters grow with n^2) as even NVIDIA's SDK Variance Shadow Maps demo demonstrates quite conclusively.

I'm surprised you're having *any* performance problems with an 8800... I have an 8800GTX and I get literally hundreds and hundreds of frames per second with large shadow, cascaded shadow maps using full 2 or 4-component 32-bit float buffers, 4x shadow MSAA, blurring and on-the-fly mipmap generation, trilinear and 16x aniso filtering. The situation is similar and often even more pronounced on my sister's 8800GTS 512MB. VSMs even run well on my laptop (8600M GT)! It's worth noting that similar quality shadows implement with PCF are in the single-digit frame-rates, and even the more commonly-implemented but lower-quality "neighbourhood PCF" is slower almost universally, but particularly as filter sizes increase.

Perhaps we should take this offline to avoid clogging this thread any further, but I can guarantee that VSMs are extremely efficient on modern hardware.

Share this post


Link to post
Share on other sites
Actually I'm quite interested by your discussion Andy, please don't take it offline! :) Its quite an interesting point, floating point buffers are typically slow on anything other than the newest hardware.

Also I've been recently using screen-space blur to improve planar projected shadows for a university project and the results are quite pleasable I think. With Shadow Maps that can be improved further because you can decide which space to perform the blur in.

Again I can't say I'm an expert on these matters, but providing that only the Shadows and more specifically the edges are blurred, the results can provide an anti-aliasing effect. Admittedly it would be better if there was some distinction for the blurring such as further away from the light source gets blurred further (i.e the magnitude of the vector V-L, where V is a Vertex of an object and L is the Light source). Though I'm not sure how successful or easy an implementation of that would be. It's something I might look at further.

Neutrinohunter

Share this post


Link to post
Share on other sites
Quote:
I'm surprised you're having *any* performance problems with an 8800.


Well this is on top of an already extremely intensive terrain renderer with many other effects. Shader complexity is frankly rather beyond Crysis-level.

Here's another wierd problem with VSM i have had that makes it appear unusable for me...

I render my object shadows(vegetation, rocks, etc) into a seperate shadow buffer from my terrain shadows which have a much wider field of view...

So the object shadow buffer has no real depth values beyond that of the actual objects..(ie, the terrain isnt writing to the object shadow buffer so depth at terrain is always max depth or whatever I may lay down as a base value.

The upshot is with VSM I always get improper filtering on the terrain.. does this make sense? This obviously doesnt happen using standard shadow mapping. I am using your reference implementation of VSM form the FX composer file btw..

So in other words, VSM is neither faster nor higher quality than a combination of multiple hardware shadow map lookups and a subtle screen-space blur. VSM in at least my case, with large depth discontinuities and large areas is not nearly as robust as my other method. I wonder why Crytec and others dont opt for VSM for objects shadows either...

Obviously screen blurs are not a panacea and must be used with some other form of filtering...adding some noise to the shadow map lookup and then blurring is probably even a better idea.

Share this post


Link to post
Share on other sites
Alright, I'll talk about shadows a bit more even though I swore off them in the deferred rendering thread ;)

Quote:
Original post by Neutrinohunter
With Shadow Maps that can be improved further because you can decide which space to perform the blur in.

Not sure what you mean by this... you can't blur a standard shadow map - that's exactly what these new linear techniques allow. This is the more usual sort of "blurring" that you want to do, while doing it in screen space is just weird.

Quote:
Original post by Neutrinohunter
the results can provide an anti-aliasing effect

They only provide an anti-aliasing "effect" in the same way as blurring a texture when not using mipmapping provides an anti-aliasing "effect". i.e. it doesn't, it just removes some of the higher frequencies so it pushes the problem a bit further away. Unfortunately due to projection mismatches, filter kernels - and thus aliasing - in shadow maps can be arbitrarily bad and thus you really have to treat the problem not the symptoms.

Quote:
Original post by Neutrinohunter
Admittedly it would be better if there was some distinction for the blurring such as further away from the light source gets blurred further

That's the idea behind Percentage Closer Soft Shadows and the similar applications to Summed-Area Variance Shadow Maps, etc. See GPU Gems 3 or more recently the GDC 2008 presentation up on NVIDIA's page for a more thorough treatment of this topic. It, again, is unrelated to screen-space blurring.

Quote:
Original post by Matt Aufderheide
Well this is on top of an already extremely intensive terrain renderer with many other effects. Shader complexity is frankly rather beyond Crysis-level.

Sure but blurring the shadow map is an image-space process that should incur a constant cost regardless of the rest of your scene. Indeed PCF will be more negatively affected by more complex scenes and shaders than VSM.

Quote:
Original post by Matt Aufderheide
I render my object shadows(vegetation, rocks, etc) into a seperate shadow buffer from my terrain shadows which have a much wider field of view...

Yeah, you need to render both castors and receivers into the variance shadow map (I mention this in the GPU Gems 3 chapter). That's true of all of the probabilistic shadow mapping techniques - you need information about the receiver over the filter region to avoid self-occlusions, etc. PCF attempts to address this with biasing, but indeed in more complex scenes biasing cannot provide a fully satisfactory solution (as I also show in the Gems 3 chapter).

There's not really a way "around" this requirement, but ideally you want everything to be shadowing everything else anyways. This is usually only a problem for games/scenes that have been designed around explicit castor/receiver sets, but admittadly in those cases it can be hard to "bolt on" VSM without at least editing parts of the scene to accommodate universal shadowing.

Quote:
Original post by Matt Aufderheide
I wonder why Crytec and others dont opt for VSM for objects shadows either...

Crysis doesn't use it simply for light bleeding reasons as stated in their presentation from last year's GDC. Some other games/scenes don't have as severe problems with light bleeding and thus use it everywhere (I know of at least a half dozen games using it exclusively). Admittadly if light bleeding is a problem for your scene, you'll have to look at something more like Layered or Exponential VSM (or simply Exponential Shadow Maps), but if your scene doesn't have a lot of light bleeding, and you have hardware that supports 32-bit float texture filtering VSM is a clear win.

Quote:
Original post by Matt Aufderheide
adding some noise to the shadow map lookup and then blurring is probably even a better idea.

Well really what you'd have to do is super-sample in screen-space. This isn't an efficient method in the long run though as we've seen by the vast gains of texture pre-filtering.

Share this post


Link to post
Share on other sites
Just an idea on how to create penumbras

For stencil shadow volumes you can extract the silhouette in the geometry shader


I think about a 2 pass algorithm

1. Render the shadow map as usual
2. Render the faked penumbras
a) detect silhouette edges in geometry shader
b) create silhouette polygon
c) project far vertices of the silhouette polygon onto the plane of the current triangle( this needs some tweaking since it influences the size of the penumbra a lot)
d) apply an shadow intensity gradient to the extruded polygon [1.0-0.0]
e) emit polygon
f) emit original polygon with intensity 1.0

(use blending and disable zwrite to blend extruded polygons with gradient over original geometry)

Now you have an intensity map that can be used to apply shadow to the scene
(Image) red being the outer penumbra, blue the faked outer penumbra



Maybe if you are a smart guy you can combine this into a single pass
With DX10 hardware it should be possible to bind the depth target as texture source simultaneously as far as I know, at least in CUDA 1.1 its possible.

In a nurbs ray tracing paper they did this successfully.

Share this post


Link to post
Share on other sites
This sounds sort of like the penumbra wedge algorithm. Might want to take a look at that. Read this PhD thesis: http://graphics.cs.lth.se/research/shadows/ulf_thesis_lores.pdf

Share this post


Link to post
Share on other sites
Quote:
Original post by AndyTX
Alright, I'll talk about shadows a bit more even though I swore off them in the deferred rendering thread ;)


Is anybody else reminded of The Godfather Part III? :P

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement