Shadows from terrain hills
Author
Every single article I have found concerning shadows only deals with the shadows created by objects. That''s fine, but I want techniques on shadow casting on the terrain by the terrain. You know, if the sun is setting then the hills cast long shadows across the land. Is there an easy way to adopt object shadow casting to this or are there different methods? Or is there some raycasting method from the sun? I''ve thought of a few ways to do it, but it would be way to slow for realtime. I can''t just stretch a lightmap across my terrain. It needs to be dynamic and move according to the sun and time of day. Any ideas?
Horizon Mapping works for this stuff, but can look pretty cruddy up close. It''s normally reserved for small scale bump mapped shadowing, but could work for some terrain environments given enough softening.
You might want to reconsider if it really has to be in realtime - Does the sun really move so fast that you can''t optimize it by not updating all of it as often?
An optimization to the raytracing method could also be to make everything from the tile or lightmap texel you are currently checking right up to the mountain that is casting the shadow black. (or, well, shadow/ambient colour) This way, you don''t have to check those already inside the shadow. This is rather tricky to implement, but it is doable and I think you should receive a rather good performance boost. Of course, your light direction won''t be parallel to the terrain strips, but you should still be able to do it by checking areas.
I hope I didn''t formulate that in a too confusing way
Anyway, if you use that method, make sure that you are approximately looping through your tiles in the direction towards the light, or it won''t help you at all. (8 different directions should be ok, i.e. N, NE, E, SE, S, SW, W, NW or you''ll use up all the clock cycles for looping through the tiles...)
Note that I haven''t tried this myself - I just came up with the idea, so it''s probably not the best idea around, but try to figure something out along those lines. (it''s all about avoiding to check as much as possible)
Another possibility could be to compare maximum terrain slopes to the angle of the light to reduce the checks for when the sun is standing high and there are no big shadows that optimize the points inside the shadow away.
Hm, you''ve made me curious, I should try this.
- hillip@xenoage.de''>JQ
Full Speed Games. Period.
An optimization to the raytracing method could also be to make everything from the tile or lightmap texel you are currently checking right up to the mountain that is casting the shadow black. (or, well, shadow/ambient colour) This way, you don''t have to check those already inside the shadow. This is rather tricky to implement, but it is doable and I think you should receive a rather good performance boost. Of course, your light direction won''t be parallel to the terrain strips, but you should still be able to do it by checking areas.
I hope I didn''t formulate that in a too confusing way
Anyway, if you use that method, make sure that you are approximately looping through your tiles in the direction towards the light, or it won''t help you at all. (8 different directions should be ok, i.e. N, NE, E, SE, S, SW, W, NW or you''ll use up all the clock cycles for looping through the tiles...)
Note that I haven''t tried this myself - I just came up with the idea, so it''s probably not the best idea around, but try to figure something out along those lines. (it''s all about avoiding to check as much as possible)
Another possibility could be to compare maximum terrain slopes to the angle of the light to reduce the checks for when the sun is standing high and there are no big shadows that optimize the points inside the shadow away.
Hm, you''ve made me curious, I should try this.
- hillip@xenoage.de''>JQ
Full Speed Games. Period.
Storing the horizon (sampled at multiple directions) per tile, and comparing to the sun height/position in realtime is pretty fast. But quality is rather poor, and limits you to Gouraud shading the shadows at the heightmap resolution (or stretching a huge lightmap over the terrain).
For full realtime high quality shadows on a large and complex terrain, I would suggest using adaptive shadowmapping. If well adjusted, it can look awesome, the perceived shadow resolution is very high. However, you''ll need to render the terrain twice per frame, it needs multiple highres shadowmaps, and it requires a GF3 minimum.
/ Yann
For full realtime high quality shadows on a large and complex terrain, I would suggest using adaptive shadowmapping. If well adjusted, it can look awesome, the perceived shadow resolution is very high. However, you''ll need to render the terrain twice per frame, it needs multiple highres shadowmaps, and it requires a GF3 minimum.
/ Yann
Author
Osc- Yeah, I''ve seen a few pictures of that technique. I might want a little higher quality for large terrain- thanks though!
Haha Always glad to invoke new ideas. (doesn''t happen very much from me though ? >_> ) Anyway, if you do end up doing it, post some screenshots! It sounds like a very interesting idea, but yet again, I''m captivated by what Yann said. I looked up some papers on adaptive shadow mapping, and I''m very excited about what I found. This definitely looks like a usable method. It didn''t seem that hard to implement either, which is why I am so excited about it. I can''t believe I didn''t think of that earlier. It''s so simple! Just render from the light''s point of view, and use the light''s depth buffer as a texture.. very very intriguing!! It looks very high quality as well- ok I''ll stop babbling in my excitement- thanks again guys!
quote:Original post by JonnyQuest
Hm, you''ve made me curious, I should try this.
Haha
Always glad to invoke new ideas. (doesn''t happen very much from me though ? >_> ) Anyway, if you do end up doing it, post some screenshots! It sounds like a very interesting idea, but yet again, I''m captivated by what Yann said. I looked up some papers on adaptive shadow mapping, and I''m very excited about what I found. This definitely looks like a usable method. It didn''t seem that hard to implement either, which is why I am so excited about it. I can''t believe I didn''t think of that earlier. It''s so simple! Just render from the light''s point of view, and use the light''s depth buffer as a texture.. very very intriguing!! It looks very high quality as well- ok I''ll stop babbling in my excitement- thanks again guys!
Whats the difference between normal shadow mapping and "adaptive" shadow mapping then? Whats the link you looked at okonomiyaki?
If it''s anything like "normal" shadow mapping, I feel you might get rather alot of aliasing artifacts when you''re a long way from the light source. Infact, thats a point, the sun is a directional light source, so how are you going to render the scene from the lights point of view anyway?
Death of one is a tragedy, death of a million is just a statistic.
If it''s anything like "normal" shadow mapping, I feel you might get rather alot of aliasing artifacts when you''re a long way from the light source. Infact, thats a point, the sun is a directional light source, so how are you going to render the scene from the lights point of view anyway?
Death of one is a tragedy, death of a million is just a statistic.
Yep, shadowmapping is a very nice technique (and will IMO totally replace stencil shadowing in the near future), but there are some points to be careful about, it isn't as easy as it seems...
Perhaps the term 'adaptive' shadowmapping was not well chosen in my previous post. What is commonly refered to as 'adaptive shadowmaps' (ASM) in the CG field is a lazy evaluation technique that is unfortunately not (yet) doable on 3D hardware. Don't let that confuse you. What I meant is something slightly different, see below.
Another important point you will run into: standard shadowmapping systems will shadowmap the whole terrain with a single map. The resulting quality is total crap, especially on large terrains. That's why lots of people will tell you, that shadowmapping is low quality (it is not, if well implemented).
The key is to not only regenerate the shadowmap every frame, but also the light's projection matrix. That's what I meant by adaptive: Only shadowmap the parts of your terrain that are currently in the view frustum. This will most likely require multiple tiled shadowmaps (in my engine, it takes 4). That way, you don't waste precious shadowmap texels, and get maximum resolution for the visible part of your terrain (the invisible parts won't have a shadowmap applied).
You can go even further with adaptive projective shadowmaps , it will give you even higher resolution by using a non-standard projection matrix. But I'm rumbling around (again
), that's a bit too complex for the beginning. Standard tiled (better term than adaptive) shadowmaps will already give you a very good quality at reasonable speed.
python_regious:
That's the nice thing about the sun: it's directional. You render the shadowmap depthbuffer using an orthographic projection. That way, the distance of the lightsource won't negatively impact the quality of the shadowmap anymore: perspective aliasing (as encountered with pointlights) is completely avoided.
/ Yann
[edited by - Yann L on July 30, 2002 4:14:33 PM]
Perhaps the term 'adaptive' shadowmapping was not well chosen in my previous post. What is commonly refered to as 'adaptive shadowmaps' (ASM) in the CG field is a lazy evaluation technique that is unfortunately not (yet) doable on 3D hardware. Don't let that confuse you. What I meant is something slightly different, see below.
Another important point you will run into: standard shadowmapping systems will shadowmap the whole terrain with a single map. The resulting quality is total crap, especially on large terrains. That's why lots of people will tell you, that shadowmapping is low quality (it is not, if well implemented).
The key is to not only regenerate the shadowmap every frame, but also the light's projection matrix. That's what I meant by adaptive: Only shadowmap the parts of your terrain that are currently in the view frustum. This will most likely require multiple tiled shadowmaps (in my engine, it takes 4). That way, you don't waste precious shadowmap texels, and get maximum resolution for the visible part of your terrain (the invisible parts won't have a shadowmap applied).
You can go even further with adaptive projective shadowmaps , it will give you even higher resolution by using a non-standard projection matrix. But I'm rumbling around (again
), that's a bit too complex for the beginning. Standard tiled (better term than adaptive) shadowmaps will already give you a very good quality at reasonable speed.python_regious:
quote:
If it's anything like "normal" shadow mapping, I feel you might get rather alot of aliasing artifacts when you're a long way from the light source. Infact, thats a point, the sun is a directional light source, so how are you going to render the scene from the lights point of view anyway?
That's the nice thing about the sun: it's directional. You render the shadowmap depthbuffer using an orthographic projection. That way, the distance of the lightsource won't negatively impact the quality of the shadowmap anymore: perspective aliasing (as encountered with pointlights) is completely avoided.
/ Yann
[edited by - Yann L on July 30, 2002 4:14:33 PM]
Author
This was the pdf paper where I got really interested:
http://developer.nvidia.com/docs/IO/1830/ATT/shadow_mapping.pdf
Actually, now reading your clarification Yann, I don''t think that paper is exactly the same thing as you meant. But the overall idea is the same I suppose. I believe it covers most of the things you mentioned, although I started skimming it near the bottom. And don''t worry about correct terminology, I don''t take the terms too seriously anyway
BTW, that title of the article is "Hardware Shadow Mapping". I suppose it''s found a way to implement it with hardware acceleration? I haven''t taken a close look at it yet, but it seems to hold the key. My sky is taking so much longer than I expected, I think I have to finish that before I get into advanced terrain techniques.
http://developer.nvidia.com/docs/IO/1830/ATT/shadow_mapping.pdf
Actually, now reading your clarification Yann, I don''t think that paper is exactly the same thing as you meant. But the overall idea is the same I suppose. I believe it covers most of the things you mentioned, although I started skimming it near the bottom. And don''t worry about correct terminology, I don''t take the terms too seriously anyway
BTW, that title of the article is "Hardware Shadow Mapping". I suppose it''s found a way to implement it with hardware acceleration? I haven''t taken a close look at it yet, but it seems to hold the key. My sky is taking so much longer than I expected, I think I have to finish that before I get into advanced terrain techniques.
Well, stamdard shadowmapping (as well as my version of adpative, uh, ''tiled'' shadowmapping ) are both hardware accelerateable on GF3+. No problems with that. The only one not that can not be accelerated is the ''real'' ASM technique, it''s software only (but looks incredibly nice).
BTW, the paper you found is about standard shadowmapping. It''s the standard nVidia article about how to implement it, so it''s definitely a good start. It can easily be extended to become ''adaptive'', once you get the basic concept. Keep in mind though, that there is one major difference: that papers handles pointlights (and uses perspective projections on the shadowmap). You need orthographic light for you sun. This has the benefit, that some of the limitations presented from page 8 on, do not apply to your case.
/ Yann
) are both hardware accelerateable on GF3+. No problems with that. The only one not that can not be accelerated is the ''real'' ASM technique, it''s software only (but looks incredibly nice).BTW, the paper you found is about standard shadowmapping. It''s the standard nVidia article about how to implement it, so it''s definitely a good start. It can easily be extended to become ''adaptive'', once you get the basic concept. Keep in mind though, that there is one major difference: that papers handles pointlights (and uses perspective projections on the shadowmap). You need orthographic light for you sun. This has the benefit, that some of the limitations presented from page 8 on, do not apply to your case.
/ Yann
Author
Ah, great! Thanks for the clarification. Correct me if I''m wrong, but an ortho view is easily achieved with matrix translations. And then since I''m using directional, it should be even easier then the paper, no? Because they have to worry about the projection while I just can take the depth buffer as it is. I''m not saying it will be easy, but at least it''s not a paper where I feel like I''m reading Greek. I''ll probably work on implementing something like the paper, and then extending it with your "adaptive" ideas. Thanks a lot!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
