Cascaded Shadow Mapping & Poisson Disk filtering

A place to show off your latest screenshots and for people to comment on them. Only start a new thread here if you have some nice images to show off!
lygyue
Greenskin
Posts: 122
Joined: Wed Nov 29, 2006 4:07 pm

Re: Cascaded Shadow Mapping & Poisson Disk filtering

Post by lygyue » Sat Aug 18, 2012 7:03 am

Thanks for your reply, i am trying use the poisson filtering shader code on point light, and if i did, i'll upload the screenshots. :)
0 x

User avatar
duststorm
Minaton
Posts: 921
Joined: Sat Jul 31, 2010 6:29 pm
Location: Belgium
Contact:

Re: Cascaded Shadow Mapping & Poisson Disk filtering

Post by duststorm » Sat Aug 18, 2012 9:28 am

Mind Calamity wrote:Without the colorful lights it'd look pretty realistic :)
And with a better ground texture ;) I'm using a badly scaled asphalt texture on the terrain at the moment. The reason for that is that it contains a white specular map (completely specular), which makes it good for light testing.
foxbat wrote:Nice work Duststorm. Feel free to make all the improvements you want.
When I produce something decent I'll issue a pull request to your repo. (and you'll find out about it here)
0 x
Developer @ MakeHuman.org

User avatar
duststorm
Minaton
Posts: 921
Joined: Sat Jul 31, 2010 6:29 pm
Location: Belgium
Contact:

Re: Cascaded Shadow Mapping & Poisson Disk filtering

Post by duststorm » Tue Aug 21, 2012 11:51 am

Upon investigating a bit more why my cascades with terrain didn't always seem right I think I have found the issue.

If you look at this screenshot you can see that there is something wrong with how cascades are chosen. Namely that it depends heavily on the incoming light direction where the center of the cascades will end up.
screenshot08212012_103039989_small.jpg
With a directional light low on the horizon the "near" cascade very evidently moves far away from the camera.
screenshot08212012_103039989_small.jpg (114.92 KiB) Viewed 10478 times
The red square contains the shadows rendered in the highest resolution shadow texture. But it is very far from the camera. Instead the highest resolution shadows should be rendered on nearby objects.

Realizing this I tried the original demo again, and it exhibits the same problem:
screenshot08212012_122215200_small.jpg
Original Stable CSM demo: Close to the ground it's less noticeable that the cascade center (red) is offset with light direction. (top picture) When placing the camera higher it becomes noticeable that the near cascade is off (bottom picture).
screenshot08212012_122215200_small.jpg (196.24 KiB) Viewed 10478 times
The problem is less apparent here because the light direction is much more vertical (the light is higher in the sky), although when backing off the camera you can notice that the red cascade is not really where you would expect it.
This causes the most detailed shadow texture to be used for an area that is far from the near view plane, which is not the purpose of CSM.

In most cases it does work when the camera is close to the ground (barring issues with too horizontal light directions), but that makes the possible applications limited, of course.

This video shows better what it should look like:
[youtube]fGWHigI_1dY[/youtube]
0 x
Developer @ MakeHuman.org

foxbat
Greenskin
Posts: 131
Joined: Sun Sep 25, 2005 2:44 am
Location: Melbourne, Australia

Re: Cascaded Shadow Mapping & Poisson Disk filtering

Post by foxbat » Wed Aug 22, 2012 11:23 am

I believe this is a limitation of the algorithm. Cascades are positioned based only on knowledge of the camera frustum and light direction.

When the camera is parallel with the light, the cascades will be projected along the camera frustum centreline. This is because the concept of what's near and far is undefined without knowing about the scene geometry. For example, as you correctly point out, a more efficient cascade placement in the bottom picture would be near where the bottom edge of the camera frustum intersects the ground plane. However if the camera were below the plane and looking up it would need to be the reverse. This may be easy to calculate for some scenes, but to apply this generally would be non trivial. You would need to calculate the intersection of the camera frustum and the scene geometry and figure out which part is closest, then position the cascade to project onto the closest part.

A potential improvement could be to add a bias parameter to offset the cascades (perpendicular to the camera direction) toward the camera along an assumed ground plane. This could work in scenes which have fairly flat terrain and where the camera is far away from the terrain (eg this would work pretty well for an RTS style game).

Edit:
Something else to keep in mind: this limitation is most apparent when the camera and the light are parallel, but fortunately shadow aliasing is minimal in this situation because the shadow map will closely match the screen size.
0 x

User avatar
scrawl
OGRE Expert User
OGRE Expert User
Posts: 1119
Joined: Sat Jan 01, 2011 7:57 pm
Location: Germany
x 2

Re: Cascaded Shadow Mapping & Poisson Disk filtering

Post by scrawl » Wed Aug 22, 2012 11:40 am

I guess thats one of the reasons why PSSM is usually preferred (or at least the more universal solution). Not sure how hard it is to get the "stable in world space" feature in combination with PSSM - the standard PSSM shadows that come with Ogre are flickering when the camera moves/rotates. But it seems to be possible: http://www.youtube.com/watch?feature=pl ... g42jcHpC2U
0 x

User avatar
duststorm
Minaton
Posts: 921
Joined: Sat Jul 31, 2010 6:29 pm
Location: Belgium
Contact:

Re: Cascaded Shadow Mapping & Poisson Disk filtering

Post by duststorm » Wed Aug 22, 2012 11:58 am

Yes it should be possible. I believe this technique can be applied.

Reading this paper on CSM I was under the impression that with this technique cascades are always clipped relative to the view frustum, not the light frustum.

But I did have been wondering what the actual difference is between PSSM and CSM.

Anyway if I can't get it to work properly in camera frustum space I don't think it will be that well-fit for terrain shadowing after all, as low sun positions and shots from higher up are really a must.

From how I understood it the stable approach consists of making the shadow frustum orientation fixed in world space. And that the panning of the shadow texture always happens at texel-sized increments to eliminate shimmering, and that this can be combined with a PSSM-like approach. But I think I will need to do some more reading to understand the differences exactly.
0 x
Developer @ MakeHuman.org

foxbat
Greenskin
Posts: 131
Joined: Sun Sep 25, 2005 2:44 am
Location: Melbourne, Australia

Re: Cascaded Shadow Mapping & Poisson Disk filtering

Post by foxbat » Fri Aug 24, 2012 12:08 pm

scrawl wrote:I guess thats one of the reasons why PSSM is usually preferred (or at least the more universal solution). Not sure how hard it is to get the "stable in world space" feature in combination with PSSM - the standard PSSM shadows that come with Ogre are flickering when the camera moves/rotates.
In Scene Independent PSSM the light frustum is usually tightly bound to the split frustum. This may give you more resolution in some cases, but will generally be pretty similar to Stable CSM where the camera and light are parallel. This also holds true when combining PSSM with light frustum warping techniques like LiSPSM, as used in Ogre's PSSM implementation. The benefit of frustum warping goes to zero as the camera becomes parallel with the light.

Scene Dependent PSSM will give you more resolution in the camera-light parallel case, but is quite tricky to implement.

Section 10.2.2 of this page explains the difference between scene dependent and scene independent implementations of PSSM.

duststorm wrote:Reading this paper on CSM I was under the impression that with this technique cascades are always clipped relative to the view frustum, not the light frustum.
You're correct, cascades are clipped relative to the view frustum (or the split frustum to be precise). The technique in that paper looks to be the same as Scene Independent PSSM as mentioned in the link in this post. My Stable CSM implementation is slightly different to general CSM/PSSM in that the light frustum is bound to the minimum enclosing sphere of the split frustum, rather than being tightly bound to the split frustum itself. This makes the shadow projection independent of camera orientation (i.e so that the shadows don't jitter when the camera rotates).
0 x

User avatar
lunkhound
Gremlin
Posts: 169
Joined: Sun Apr 29, 2012 1:03 am
Location: Santa Monica, California

Re: Cascaded Shadow Mapping & Poisson Disk filtering

Post by lunkhound » Sat Aug 25, 2012 7:36 am

I have been looking into shadow mapping for a little while now and as far as I can tell CSM and PSSM are basically the same thing. I haven't found any defining characteristic that separates the two concepts.
Now the PSSM implementation in Ogre is more than just PSSM, it is really PSSM+LiSPSM. Because of the LiSPSM part, I don't think there is any way to make it "stable".
LiSPSM warps the light space with a perspective transform so that there is more shadow detail closer to the camera, in other words, shadow texels close to the camera position are smaller in world space than further away ones. Since the shadow texels are all differently sized in world space, there is no way to move the light frustum in texel-sized increments. The only way to make LiSPSM appear visually stable, is to increase the shadow texture resolution to the point that shadow texels are sub-pixel sized on screen.

@duststorm: The overlapping cascades that you are seeing on your terrain is normal when the camera is nearly parallel to the light direction. However, it looks like you aren't selecting which cascade to use based on view-depth at all. That far away red area looks to be well outside the frustum it was intended for. Because your camera in that example is floating well above the terrain, there isn't any geometry inside your smallest "cascade frustum" to cast or receive shadows. That red shadow texture shouldn't be used at all in that case.
0 x

scratchyrice
Gnome
Posts: 324
Joined: Thu Apr 27, 2006 9:14 pm
Location: United Kingdom - England

Re: Cascaded Shadow Mapping & Poisson Disk filtering

Post by scratchyrice » Sat Aug 25, 2012 8:06 pm

Hi,

I have implemented this technique into my engine and am testing it out. So far it looks great but I can't seem to get it to work with a world scaled to 1 ogre unit = 1 meter. What settings should I be adjusting to make the needed changes?

Cheers

Scratchyrice
0 x
Intel I5 750 OC'd to 4.2Ghz per core, Geforce 580GTX 1.5Gb GPU, 280GTX for PhysX, 8Gb DDR 3 ram

scratchyrice
Gnome
Posts: 324
Joined: Thu Apr 27, 2006 9:14 pm
Location: United Kingdom - England

Re: Cascaded Shadow Mapping & Poisson Disk filtering

Post by scratchyrice » Sat Aug 25, 2012 9:53 pm

Hi All,

Ive got a bit further with it. It now works flawlessly when I am looking at an object with the light source directly behind the camera. If its not behind it goes gradually more fuzzy and peaks when the camera is facing the light source. Does anyone know what this could be?

Thanks a lot

Scratchy
0 x
Intel I5 750 OC'd to 4.2Ghz per core, Geforce 580GTX 1.5Gb GPU, 280GTX for PhysX, 8Gb DDR 3 ram

foxbat
Greenskin
Posts: 131
Joined: Sun Sep 25, 2005 2:44 am
Location: Melbourne, Australia

Re: Cascaded Shadow Mapping & Poisson Disk filtering

Post by foxbat » Sun Aug 26, 2012 1:51 pm

lunkhound wrote:... it looks like you aren't selecting which cascade to use based on view-depth at all. That far away red area looks to be well outside the frustum it was intended for. Because your camera in that example is floating well above the terrain, there isn't any geometry inside your smallest "cascade frustum" to cast or receive shadows. That red shadow texture shouldn't be used at all in that case.
My implementation always uses the smallest available cascade regardless of distance. This ensures no shadow map space is wasted as it would be with selecting a cascade based solely on view distance. You raise a good point; optimisations could be used in the case where the camera is far above all geometry since the extra detail from the smallest cascade is redundant. In this case smaller cascades could be disabled, or alternately all the split points could be moved further back.
scratchyrice wrote:Ive got a bit further with it. It now works flawlessly when I am looking at an object with the light source directly behind the camera. If its not behind it goes gradually more fuzzy and peaks when the camera is facing the light source. Does anyone know what this could be?
The smallest cascade is always used when the camera is directly behind the light, so this case will look sharpest. It sounds like you may need to tweak the split points to give you better cascade sizes for your scene.
0 x

User avatar
lunkhound
Gremlin
Posts: 169
Joined: Sun Apr 29, 2012 1:03 am
Location: Santa Monica, California

Re: Cascaded Shadow Mapping & Poisson Disk filtering

Post by lunkhound » Sun Aug 26, 2012 7:56 pm

foxbat wrote:
lunkhound wrote:... it looks like you aren't selecting which cascade to use based on view-depth at all. That far away red area looks to be well outside the frustum it was intended for. Because your camera in that example is floating well above the terrain, there isn't any geometry inside your smallest "cascade frustum" to cast or receive shadows. That red shadow texture shouldn't be used at all in that case.
My implementation always uses the smallest available cascade regardless of distance. This ensures no shadow map space is wasted as it would be with selecting a cascade based solely on view distance. You raise a good point; optimisations could be used in the case where the camera is far above all geometry since the extra detail from the smallest cascade is redundant. In this case smaller cascades could be disabled, or alternately all the split points could be moved further back.
Its true that selecting the cascade solely on camera depth would frequently waste shadow map detail. However, using the smallest cascade regardless of distance can have issues too, like aliasing due to texture undersampling. Ideally you'd want shadow texels to be slightly smaller than pixel sized, and then do some filtering to keep aliasing at bay. So if the pixel's camera depth is beyond the z-partition by a certain amount, its advantageous to use the smallest cascade possible (because texture oversampling--the pixelated look is the more likely problem). But if the pixel's z-depth is way beyond the z-partition to the point where undersampling is a risk, then its better to go with a larger cascade. Then again, the undersampling artifacts may not appear often enough or be objectionable enough to warrant fixing.

However, if you want to use 16-bit shadow buffers (saves memory, reduces memory bandwidth, compatible with more hardware) you'll want to set up proper near and far clip planes for your shadow cameras, clip planes that bound your partitioned frustums at tightly as possible. And you obviously can't be using a cascade for pixels that fall beyond the far clip plane of your shadow camera (all such pixels would be in shadow because the shadow buffer maxes out at the far clip plane).
Having tight near and far clip planes for shadow cameras can also cut down on the geometry that will be rendered into the shadow textures. Another boon to performance.
0 x

foxbat
Greenskin
Posts: 131
Joined: Sun Sep 25, 2005 2:44 am
Location: Melbourne, Australia

Re: Cascaded Shadow Mapping & Poisson Disk filtering

Post by foxbat » Mon Aug 27, 2012 11:08 am

However, if you want to use 16-bit shadow buffers (saves memory, reduces memory bandwidth, compatible with more hardware) you'll want to set up proper near and far clip planes for your shadow cameras, clip planes that bound your partitioned frustums at tightly as possible. And you obviously can't be using a cascade for pixels that fall beyond the far clip plane of your shadow camera (all such pixels would be in shadow because the shadow buffer maxes out at the far clip plane).
Having tight near and far clip planes for shadow cameras can also cut down on the geometry that will be rendered into the shadow textures. Another boon to performance.
You make a good point. As an addition to the current cascade selection criteria, each cascade could have a maximum display distance set slightly beyond the split distance. This would solve the issues you describe while still offering good texture utilisation.
0 x

User avatar
lunkhound
Gremlin
Posts: 169
Joined: Sun Apr 29, 2012 1:03 am
Location: Santa Monica, California

Re: Cascaded Shadow Mapping & Poisson Disk filtering

Post by lunkhound » Mon Aug 27, 2012 6:46 pm

foxbat wrote:
However, if you want to use 16-bit shadow buffers (saves memory, reduces memory bandwidth, compatible with more hardware) you'll want to set up proper near and far clip planes for your shadow cameras, clip planes that bound your partitioned frustums at tightly as possible. And you obviously can't be using a cascade for pixels that fall beyond the far clip plane of your shadow camera (all such pixels would be in shadow because the shadow buffer maxes out at the far clip plane).
Having tight near and far clip planes for shadow cameras can also cut down on the geometry that will be rendered into the shadow textures. Another boon to performance.
You make a good point. As an addition to the current cascade selection criteria, each cascade could have a maximum display distance set slightly beyond the split distance. This would solve the issues you describe while still offering good texture utilisation.
What I'm doing in my shader is I just check that the pixel coordinates in the shadow/cascade space are all in the range (0, 1), that's for x, y, AND z. Actually, it may need to be a little tighter, more like (0+epsilon, 1-epsilon), especially in the x and y if you are filtering. Starting with the smallest cascade, and selecting the first one where the coordinates are all in range.
0 x

mail2ameen
Gnoblar
Posts: 12
Joined: Fri Jun 03, 2011 8:32 pm

Re: Cascaded Shadow Mapping & Poisson Disk filtering

Post by mail2ameen » Wed Aug 29, 2012 10:17 pm

Hi,
I ran the demo app, it looks awesome.!.
But when I built the source code and run the app., I am getting shader compilation error.
It looks like "shadow_caster_fragment_program_ref" is not available in "Cthugha" version.
Is there any workaround for this?
Thanks.
0 x

User avatar
duststorm
Minaton
Posts: 921
Joined: Sat Jul 31, 2010 6:29 pm
Location: Belgium
Contact:

Re: Cascaded Shadow Mapping & Poisson Disk filtering

Post by duststorm » Thu Aug 30, 2012 1:12 am

mail2ameen wrote:It looks like "shadow_caster_fragment_program_ref" is not available in "Cthugha" version.
It should be. Looks like that material statement has been around for quite some time already.
It should work with both 1.7 and 1.8
mail2ameen wrote:Is there any workaround for this?
I'm not sure what's causing it, but you could always create a shadow caster material, reference the VP and FP programs from there, and then reference to the shadow caster program using the "shadow_caster" option.
By creating a shadow caster material you can also simply set it on the scene manager for all entities (in code, using SceneManager::setShadowCasterMaterial()).
Last edited by duststorm on Thu Aug 30, 2012 2:52 pm, edited 1 time in total.
0 x
Developer @ MakeHuman.org

mail2ameen
Gnoblar
Posts: 12
Joined: Fri Jun 03, 2011 8:32 pm

Re: Cascaded Shadow Mapping & Poisson Disk filtering

Post by mail2ameen » Thu Aug 30, 2012 2:46 pm

Hi,
Thanks.
I am using Ogre 1.7 which does not have 'shadow_caster_fragment_program_ref' statement. but it has only
'shadow_caster_vertex_program_ref'.
Anyway, I will try other option by defining shadow caster material.
--
0 x

mail2ameen
Gnoblar
Posts: 12
Joined: Fri Jun 03, 2011 8:32 pm

Re: Cascaded Shadow Mapping & Poisson Disk filtering

Post by mail2ameen » Thu Aug 30, 2012 3:24 pm

I'm not sure what's causing it, but you could always create a shadow caster material, reference the VP and FP programs from there, and then reference to the shadow caster program using the "shadow_caster" option.
By creating a shadow caster material you can also simply set it on the scene manager for all entities (in code, using SceneManager::setShadowCasterMaterial()).
This works.!
Thanks.
0 x

mail2ameen
Gnoblar
Posts: 12
Joined: Fri Jun 03, 2011 8:32 pm

Re: Cascaded Shadow Mapping & Poisson Disk filtering

Post by mail2ameen » Tue Sep 11, 2012 2:56 pm

foxbat wrote:Thanks for the fixes. I've pulled them into the repo :)
Hi,
How can I extend this sample to support "multiple" directional lights and mix of point, spot lights?
When I added more than one directional light, the shadow jumps and hides other shadow.
Thanks.
0 x

User avatar
duststorm
Minaton
Posts: 921
Joined: Sat Jul 31, 2010 6:29 pm
Location: Belgium
Contact:

Re: Cascaded Shadow Mapping & Poisson Disk filtering

Post by duststorm » Tue Sep 11, 2012 4:03 pm

mail2ameen wrote:How can I extend this sample to support "multiple" directional lights and mix of point, spot lights?
You can either sample multiple shadow textures in one shadow receiver shader, or you can blend multiple shadow receiver passes together.
0 x
Developer @ MakeHuman.org

noorus
Halfling
Posts: 75
Joined: Wed Apr 20, 2011 9:55 pm
Location: Helsinki, Finland

Re: Cascaded Shadow Mapping & Poisson Disk filtering

Post by noorus » Sat Oct 27, 2012 1:26 pm

Hey duststorm, how far did you get with CSM on terrain? What are the major problems left with it?
If you shared your tests somewhere, I'd be interested in trying to advance it.
0 x
Creator of Nice Input Library, for your advanced input needs.
Image

User avatar
duststorm
Minaton
Posts: 921
Joined: Sat Jul 31, 2010 6:29 pm
Location: Belgium
Contact:

Re: Cascaded Shadow Mapping & Poisson Disk filtering

Post by duststorm » Wed Oct 31, 2012 6:08 pm

noorus wrote:Hey duststorm, how far did you get with CSM on terrain? What are the major problems left with it?
If you shared your tests somewhere, I'd be interested in trying to advance it.
Hi noorus,

I haven't worked on it much since due to having limited time (and a lot of other projects).
I was planning on releasing the source of this application to the community as an example at some point, but the license on some of the art assets is limiting me from making it public (I think). I'll have to take a look at this.
Anyway, if you contact me on bitbucket (duststorm01) I guess I could grant you access to the private repo for now.
0 x
Developer @ MakeHuman.org

mail2ameen
Gnoblar
Posts: 12
Joined: Fri Jun 03, 2011 8:32 pm

Re: Cascaded Shadow Mapping & Poisson Disk filtering

Post by mail2ameen » Fri Dec 07, 2012 6:34 pm

Hi,
I have implemented this technique for directional in my tool. Thanks for the stable CSMCameraSetup() function.
When I am dealing with more than one directional light, I am having issue with using textureMat0 for other lights. (both lights use same texture matrix hence same output!)
Question: how can I identify which texture matrix for which Dir light in Shader? I couldn't find any light index parameter for shader.
Or, is there any callback/listener before rendering receiver material for each light? (I'm using iterate per light in receiver pass!)
Thanks.
0 x

khalladay
Gnoblar
Posts: 1
Joined: Sun Dec 09, 2012 10:00 pm

Re: Cascaded Shadow Mapping & Poisson Disk filtering

Post by khalladay » Mon Dec 10, 2012 5:07 am

Hey, sorry for the bump.

I'm trying to implement what you have here but I'm getting an unacceptable amount of noise on the edges of my shadows. The OP says that it would be easy to increase the number of samples used to reduce the noise further, but (and I'm a tad embarassed to admit this), I'm not entirely sure how I should go about this.

Currently, my shadows look as follows, and exhibit a lot of "buzzing" in the noisy regions as the camera moves. I'd appreciate any help that anyone wants to throw my way, I'm just starting to dabble with Ogre, and getting some decent looking soft shadows is proving to be extremely difficult.

Image
0 x

Nodrev
Gremlin
Posts: 193
Joined: Fri Jan 25, 2008 6:55 pm
Location: Nantes / France

Re: Cascaded Shadow Mapping & Poisson Disk filtering

Post by Nodrev » Fri Mar 29, 2013 3:39 pm

Hi,

If I understand your description correctly, your implementation renders 4 * 1 pass, sending all the geometry of the "larger" view possible?
So, the first optimization that come to my mind was to render the four textures to a mrt in one pass (which saves lots of draw calls), what do you think about this idea (obviously it far more complicated as we have to bybass Ogre's default shadow rendering system to allow MRT rendering and render the shadow map "manually")?
0 x

Post Reply