I have been using shadow mapping for my RTS game I am making and with large outdoor areas this become somewhat unacceptable IMO. The resolution isn’t there. So what is everyone here using or doing to get around this problem that seems to be everyone’s bane… Thanks for any suggestions.
What kind of light sources are we talking about?
What kind of view are wt talking about?
I assume it’s only outdoor sunlight and camera always look (more less) down.
In this case the solution is quite simple - use shadowmap with size comparable to screen resolution, and dynamically adjust area covered by your shadowmap depending on zoom.
If you need something like first person view, then ou can use let’s say 4 shadowmaps with the same texture size but different scale, so you would have, for example:
-1024x1024 at 128x128m area
-1024x1024 at 256x256m area
-1024x1024 at 512x512m area
-1024x1024 at 1024x1024m area
Shader would simply choose the best available shadowmap. You could actually have all 4 shadowmaps in one 2048x2048 texture.
directional light
sunlight
the view moves from fps to top down almost probably 60degrees looking down
Now this 4 texture maps you say, I need to render 4 passes? and each pass move the shadowmaps eye pos to the 128 area and next 256 area and move onto the last two areas?
Thanks
I need to render 4 passes?
4 passes into shadowmaps and one pass when using this shadowmap.
each pass move the shadowmaps eye pos
Actually not move, but change the left, right, top and bottom in glOrtho - all 4 shadowmaps have the same center.
Also, consider combining shadowmaps with stencil shadows or with lightmaps. You can also separate static objects from dynamic objects and keep them in separate shadowmaps.
For directional light on big areas in fps like view you should look at this paper about Parallel-Split Shadow Maps sometimes called as Cascading shadow maps shadowmaps.
Originally posted by Komat:
For directional light on big areas in fps like view you should look at this paper about Parallel-Split Shadow Maps sometimes called as Cascading shadow maps shadowmaps.
Yeah I looked at that, but no one has converted it to GL yet that I know of? Shouldn’t be to hard, but still would be nice to look at an example to get my head around what is happening vs. aiming in the dark…
for CSM u generally reuse the same shadowmap ie dont create 4 shadowmaps (which is gonna require heaps of mem since SMs are usually big eg 2048x2048)
Originally posted by zed:
for CSM u generally reuse the same shadowmap ie dont create 4 shadowmaps (which is gonna require heaps of mem since SMs are usually big eg 2048x2048)
So how would you go about doing that? You need to copy that data to somewhere? Because wouldn’t using one involve copying over the old data which you haven’t used yet in the current frame?
for CSM u generally reuse the same shadowmap ie dont create 4 shadowmaps (which is gonna require heaps of mem since SMs are usually big eg 2048x2048)
Memory? Not using all the shadow maps at once has costs too. Like losing performance; you have to re-render objects that cross multiple regions. Plus, you can’t effectively sort by shader/material because you have to render everything in one region and then everything in another.
I’d rather sacrifice memory or use smaller shadow maps (1024x1024 or perhaps 2048x1024) than drop that kind of performance. Indeed, as evidenced by the site, you can use smaller maps when you’re doing this kind of splitting and get better quality. It’s a win/win 
So how would you go about doing that?
u create the shadow for the nearest shadowmap frustum + then draw that area to screen, then move onto the next further frustum + repeat
the performance difference is not so great as u make out
A/ true the multiple material sorts are an issue (but minor WRT performance)
B/ border crossing ( from my testing ~20% of meshes cross the border, remember the further u get away from the camera, the greater the odds against a mesh straddling a border ), but granted there is a performance cost for rendering some meshes twice (note they will only get shaded once cause u have early out with the stencil test)
ok granted those are two performance costs but on the other side it should be quicker (i havent looked at the paper) but i assume in the shader u have to do some calcs to choose from which shadowmap to shade from (this isnt free) standard shadowmapping doesnt have these extra calcs
so all in all i would say they perform very close
another thing using smaller shadowmaps for areas further away from the camera sounds good in theory but in practice looks crap.
perhaps memory considerations aint as important as they once were but even still
2048x2048x16/24/32 == 8/12/16MB per shadowmap
times that by 4 + for a 128mb card its a huge hunk of memory just for shadows (throw in the framebuffer AA VBOs + u have bugger all memory left for textures)
personally i like the look of multiple textures, basically cause its simplier, but in the end of the day I had to reuse the same SM cause of the memory issues
2048x2048x16/24/32 == 8/12/16MB per shadowmap
times that by 4 + for a 128mb card its a huge hunk of memory just for shadows
In the paper, they clearly demonstrate that 3x512512 textures are superior with PSSM to any 1x1024x1024 shadow mapping technique. In the dualing frustrum case, it is vastly superior. And a memory savings.
So, you don’t get 4 2048’s; you just use 4 1024’s instead.
yes i agree with what youre saying
but my comparrision is with
4 textures of 2048x2048 vs (1 texture 2048x2048) used 4 times
thus visually they are exactly the same
the difference is memory + speed
i was thinking a bit more the single texture reused multiple times could be even quicker cause
A/ the extra shader overhead with the ‘which SM to use’ choice
B/ I assume with todays hardware (at least my gffx) since the SM access can be either one of the 4 textures the shader will access all 4 + discard 3 based on A/
so instead of a win/win senerio i believe its more likely a lose/lose senerio
though it does have the benifit of being simpler + and perhaps faster in the future
but my comparrision is with
4 textures of 2048x2048 vs (1 texture 2048x2048) used 4 times
thus visually they are exactly the same
Have you tested a hard case (dueling frustrums, for example)? Up close and detailed?
i was thinking a bit more the single texture reused multiple times could be even quicker cause
A/ the extra shader overhead with the ‘which SM to use’ choice
B/ I assume with todays hardware (at least my gffx) since the SM access can be either one of the 4 textures the shader will access all 4 + discard 3 based on A/
Why use 4 separate texture images at all? I imagine that, in practical implementations, you will use a single 2048x2048 image that you render 4 separate depth maps to. Then, in your shader, you will simply pick out the appropriate texture coordinate based on the value of some uniforms or something. So the “shader overhead” is really just applying an appropriate offset to your texture coordinate.
So Zed, with the wash rinse repeat idea for shadowmapping, I am assuming with 4 textures I need to do 4 passes? Break the frustum into 4 chunks and render each chunk into a texture…
Have you tested a hard case (dueling frustrums, for example)? Up close and detailed?
visually of course there is no difference
im using CSM here
http://s24.photobucket.com/albums/c26/zz…mgAnch=imgAnch1
http://s24.photobucket.com/albums/c26/zz…gAnch=imgAnch26
http://s24.photobucket.com/albums/c26/zz…gAnch=imgAnch27
i forget how many frustums, 3 i think.
note in my game im not using CSM (its to expensive), im settling for lower quality shadows
Why use 4 separate texture images at all? I imagine that, in practical implementations, you will use a single 2048x2048 image that you render 4 separate depth maps to. Then, in your shader, you will simply pick out the appropriate texture coordinate based on the value of some uniforms or something. So the “shader overhead” is really just applying an appropriate offset to your texture coordinate.
true i didnt think about combining the 4 textures into one texture, but u cant use uniforms as the value will be diferent on a per pixel basis, think of a mesh straddling a frustum
mars - u split the view up into various frustums
- render whats inside a frustum to a texture
http://s24.photobucket.com/albums/c26/zz…gAnch=imgAnch34
i forget how many frustums, 3 i think.
You misunderstood what I meant by “dueling frustums”. You really should read the PDF at the end of that link; it explains the situation.
In any case, the “dueling frustums” case for shadowmapping is the case where shadowmapping fails most aggregiously: when the light frustum and the view frustum are directly facing one another. This case is almost always notoriously bad, no matter the shadowmapping technique or resolution. This is because too little of the shadow maps resolution is being properly used compared to the view frustum.
The pictures at the end of the PSSM paper show that a 4x1024 PSSM shadowmap is basically tolerable in this case, compared to even the best 1x2048 shadow mapping technique.
Granted, if you can design this case out of your product (ie: top-down RTS in 3D), then perhaps you don’t gain much from PSSM. But if you’re doing a mroe camera-free game, perhaps in a large open area with a moving sun that can sit on the horizon, then it’s a really good idea.
im well aware of “dueling frustums”
i dont know how i can make myself clearer
thus visually they are exactly the same
visually of course there is no difference
for the third time there is NO DIFFERNCE visually between what im doing + PSSM
the diference is WRT memory / performance
Hey Zed, with the image you posted for me to look at each cube there is a shadowmap? So you have 5 shadowmaps if I am seeing correctly? The first 4 are from the origin but only allowed out small amounts and get larger when you get to 4 and the 5th starts where the 3rd ends? BTW could I email you my SM code to see if it will work with your idea? Thanks
for the third time there is NO DIFFERNCE visually between what im doing + PSSM
the diference is WRT memory / performance
Well, let’s see.
The actual PDF that the people suggesting the PSSM show a difference. You claim there is none, yet your images don’t show the specific worst-case scenario I’m looking for.
So, who am I supposed to believe? Photographic evidence , or someone making a verbal claim with nothing more than words to support it?
BTW, before you get upset, I’m not accusing you of intensionally misleading everyone. However, it is entirely possible that your implementation of PSSM may simply be incorrect, and I would like to verify this vs a guarenteed correct one (ie: the one they use when presenting the idea). PSSM seems like a viable, accurate, and useful shadow mapping technique, and I’d rather not see it slandered/libeled based on a potentially erroronous implementation.
Originally posted by Korval:
The actual PDF that the people suggesting the PSSM show a difference. You claim there is none, yet your images don’t show the specific worst-case scenario I’m looking for.
They show that there is difference aginst other shadowmapping algorithms however Zed is also doing the PSSM so there should be no difference. The only difference from what is suggested on that site is that he reuses one texture for all parts of the frustum instead of having textures for all parts at once. Actually that is exactly what demo presented at that site does.