PDA

View Full Version : What shadowmapping technique for Large outdoor areas?



Mars_999
09-27-2006, 09:19 PM
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.

k_szczech
09-27-2006, 09:32 PM
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.

Mars_999
09-27-2006, 09:39 PM
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

k_szczech
09-27-2006, 11:23 PM
I need to render 4 passes?4 passes into shadowmaps and one pass when using this shadowmap.

each pass move the shadowmaps eye posActually 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.

Komat
09-28-2006, 02:28 AM
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 (http://appsrv.cse.cuhk.edu.hk/~fzhang/pssm_vrcia/) shadowmaps.

Mars_999
09-28-2006, 04:36 AM
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 (http://appsrv.cse.cuhk.edu.hk/~fzhang/pssm_vrcia/) 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...

zed
09-28-2006, 02:13 PM
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)

Mars_999
09-28-2006, 02:21 PM
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?

Korval
09-28-2006, 02:26 PM
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 ;)

zed
09-28-2006, 07:46 PM
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

Korval
09-29-2006, 09:20 AM
2048x2048x16/24/32 == 8/12/16MB per shadowmap
times that by 4 + for a 128mb card its a huge hunk of memory just for shadowsIn 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.

zed
09-29-2006, 11:41 AM
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

Korval
09-29-2006, 02:05 PM
but my comparrision is with
4 textures of 2048x2048 vs (1 texture 2048x2048) used 4 times
thus visually they are exactly the sameHave 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.

Mars_999
09-30-2006, 02:56 PM
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...

zed
09-30-2006, 08:03 PM
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/zzeek/?action=view&current=landscape.jpg&refPage=&imgAnch=imgAnch1)
http://s24.photobucket.com/albums/c26/zz...gAnch=imgAnch26 (http://s24.photobucket.com/albums/c26/zzeek/?action=view&current=friemel_screenshot.jpg&refPage=20&imgAnch=imgAnch26)
http://s24.photobucket.com/albums/c26/zz...gAnch=imgAnch27 (http://s24.photobucket.com/albums/c26/zzeek/?action=view&current=screenshot.jpg&refPage=20&imgAnch=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 (http://s24.photobucket.com/albums/c26/zzeek/?action=view&current=frustums.jpg&refPage=20&imgAnch=imgAnch34)

Korval
09-30-2006, 09:02 PM
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.

zed
10-01-2006, 12:33 PM
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 differencefor the third time there is NO DIFFERNCE visually between what im doing + PSSM
the diference is WRT memory / performance

Mars_999
10-01-2006, 03:24 PM
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

Korval
10-01-2006, 07:35 PM
for the third time there is NO DIFFERNCE visually between what im doing + PSSM
the diference is WRT memory / performanceWell, 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 (http://appsrv.cse.cuhk.edu.hk/~fzhang/pssm_vrcia/comp_knights.htm) , 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.

Komat
10-01-2006, 11:39 PM
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.

Korval
10-02-2006, 10:33 AM
They show that there is difference aginst other shadowmapping algorithms however Zed is also doing the PSSM so there should be no difference.Wait. So, when Zed's saying "there is no difference", he's talking about his particular implementation of PSSM (1 texture with multiple passes) vs. the "stock" PSSM case? I thought he was talking about non-PSSM cases.

Hmm. Looking back, it seems I misunderstood a couple of statements from him. My appologies for the mixup.

zed
10-02-2006, 02:09 PM
Originally posted by Mars_9999:
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 that image was a quick drawing of the general idea, viewed from top down the blue lines are view area
u will want to position the frustums depending on the sun direction etc
yes each cube is a frustum (containing a SM)

personally if youre doing a RTS which seem to be viewed from a topdown 2.5D viewpoint i wouldnt worry about using CSM, its more suitable for something where the camera is level with the ground eg a FPS

btw wolfgang engel is meant to be writing a paper on the subject (dont know when its due), he asked me to check it, which aint a good idea as apparent by the confusion on this thread due to my lack of explaining capabilities :)

Mars_999
10-02-2006, 02:23 PM
Yeah its a RTS but the viewing is not always top down, and IMO the quality of the shadows is poor even with 1024x1024 due to I have to cover such a large area with one shadowmap...

Mars_999
10-03-2006, 01:58 PM
So what would you suggest Zed if not CSM? For a RTS games...

Korval
10-03-2006, 02:15 PM
IMO the quality of the shadows is poor even with 1024x1024 due to I have to cover such a large area with one shadowmap...What resolution are you trying to render at that a 1024x1024 looks "poor"?

You could try a CSM/PSSM system, using 2x512x512\'s (http://appsrv.cse.cuhk.edu.hk/~fzhang/pssm_vrcia/comp_knights.htm) . Those look pretty decent, compared to 1x1024x1024.

Though for an RTS, it's probably not a good idea, considering the number of units and so forth you're probably trying to render. You'll probably kill the GPU on vertex transfer and/or vertex T&L.

Personally, though, if your RTS doesn't involve getting close to units/terrain, I wouldn't bother with shadows at all. And if it does, I'd probably consider reconsidering whether the gameplay works adequately from such a perspective.

Komat
10-03-2006, 03:39 PM
Originally posted by Korval:

Though for an RTS, it's probably not a good idea, considering the number of units and so forth you're probably trying to render. You'll probably kill the GPU on vertex transfer and/or vertex T&L.
The units in RTS are likely to have significantly less polygons than say the FPS characters and much of the details can be done with normal maps, especially when the camera is designed to display a big area from top down view. Additionally for rendering of the shadowmaps, position only vertices and simple vertex shaders are sufficient so vertex transfer bandwith and vertex processing power used to render several shadowmaps might be lower than bandwith&power used to render the resulting shaded view.

Imho the PSSM/CSM is not that usefull for the top down camera because it tries to distribute the camera frustum into the shadowmaps based on distance from the camera and in the top down view there is ussualy nothing near the camera and most of the things are in similiar distance from the camera. For that case it might be better to split the ground plane within the camera view to several areas and cover each of them with one shadowmap.

Mars_999
10-04-2006, 03:13 AM
1600x1200

Number of units shouldn't be out of control when used with culling?

Why not use shadows? Most RTS games these days have them...

Komat, what would a normal map do for me when it comes to shadows on the terrain? Never heard of this before.

Komat
10-04-2006, 06:59 AM
Originally posted by Mars_9999:
Komat, what would a normal map do for me when it comes to shadows on the terrain? Never heard of this before. Directly nothing. It only allows to use lower number of small triangles on the objects and thus it can decrease the cost of rendering of the shadowmap, if the same geometry is used for both shadowmap rendering and scene rendering.

zeoverlord
10-04-2006, 07:34 AM
Originally posted by Komat:

Originally posted by Mars_9999:
Komat, what would a normal map do for me when it comes to shadows on the terrain? Never heard of this before. Directly nothing. It only allows to use lower number of small triangles on the objects and thus it can decrease the cost of rendering of the shadowmap, if the same geometry is used for both shadowmap rendering and scene rendering. Like Komat said, it does nothing, except for one tiny thing, a normal map creates a multitude of tiny shadows due to variations in the diffuse lighting, these shadows should be at most as dark as the shadowmap shadows, it's not a big issue, but you have to keep that in mind.

zed
10-04-2006, 11:53 AM
keep in mind with this
http://appsrv.cse.cuhk.edu.hk/~fzhang/pssm_vrcia/comp_knights.htm
is the limited draw distance compareed to a more typical scene
http://s24.photobucket.com/albums/c26/zz...mgAnch=imgAnch1 (http://s24.photobucket.com/albums/c26/zzeek/?action=view&current=landscape.jpg&refPage=&imgAnch=imgAnch1)

im guessing the difference is 50meters vs 1km ie 20:1

eg take the PSSM(4; 512x512) photo it looks ok in the above screenshot but thats cause its shrunk down to 8x6cm onscreen blow that image up to fullscreen + each of those pixels will be a huge blocky ugly thing (and this is with a limited view distance) expand the view distance out to 1km + u see for decent results i believe (multiple maps) 2048x2048 is minimum (or 1024x1024 with blurring)

Korval
10-04-2006, 12:01 PM
im guessing the difference is 50meters vs 1km ie 20:1I'm not seeing a kilometer in that screen shot. I'm seeing maybe a 4:1, and that's being generous.

Your point on screen resolution vs. shadowmap resolution is valid. But, then again, I've never been one to feel that high resolutions are a necessary construct. I'd rather use strong antialiasing and anisotropic filtering than raise the resolution much past maybe 720p or so.

zed
10-05-2006, 12:44 AM
i admit youre right u vulcan bastard, the landarea was 1km not the view dist, though that is more than 200m (the grass blades are extra high due to the fact i had to 'sex them up' as at 20cm high u could hardly see them unless there were 20billion of the f'ers in the 1m^2 region before the the camera)
comeon man AA is a poor mans high res aka supersampling, aka have the cake + eat it too

in a sense youre right look at tv its at what in the US640x480 or PAL like here 720x576 hardly hires but why does it look so good?
is it possible to grad looks? it must be
i have the follwoing

area on screen / draw distance 10
physics 8
resolution 10
framerate 5
AA 3
lighting / shading 40
texture quality / variety 6
mesh quality / polygon size 6
animation quality 4
particle effects quality 4
post processing 3
..

environment interactivity
num interactive characters onscreen

is this a fair rating?

ze moo
10-06-2006, 01:10 AM
like other's said, using CSM/PSSMs in an almost top-down RTS is pretty useless

you might want to have a look at variance shadow maps though
those are pretty good at hiding aliasing artifacts at lower
shadow map resolutions