Shadows from terrain hills

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.

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

Osc- Yeah, I''ve seen a few pictures of that technique. I might want a little higher quality for large terrain- thanks though!

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.

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:

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]

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.

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

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!

quote:

---

Correct me if I''m wrong, but an ortho view is easily achieved with matrix translations

---

Once you setup an ortho projection matrix, you can simply slide around by translating the matrix, yes.

quote:

---

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.

---

It''s slightly easier, esp. in the final rendering pass. You still need to reproject your depth texture back onto your scene, but the math is simpler, since there is no perspective projection involved. Same thing goes for the computation of the r coordinate. And there are no perspective alias problems, that''s a great advantage for the quality.

The paper that Yann was talking about (I think) can be found at:
http://www-sop.inria.fr/reves/publications/data/2002/SD02/PerspectiveShadowMaps.pdf

__________________________________________________________________________________
The wind shear alone from a pink golfball can take the head off a 90-pound midget from 300 yards.
-Six String Samurai




[edited by - Mordoch Bob on July 31, 2002 1:20:54 AM]

Thats a pretty good paper, thanks for that.

I''ve found another paper on my PC ( I have rather a few, I download them, read them, then forget I have them ), which is about projective shadows, you may want to take a look at that ( it''s an nvidia presentation, so it''ll be on the nvidia developers page )...

Death of one is a tragedy, death of a million is just a statistic.

I found this article on GameDev. Try it, it''s good (I didn''t use the source code, only the idea...)

http://nervus.go.ro/common/fctsm.htm

Yeah, I saw that article before, but I was thinking something along the lines of raycasting (I''m calling that a method along the lines of raycasting, but it''s not really) would be too slow for dynamic lighting, updated every frame. I''m having some troubles using the shadow mapping techniques though, I have to go back and learn exactly what a depth buffer is and how to capture it as an image. For now I may try that technique, and I suppose the sun moves really slowly, I guess I don''t have to update it every frame
Thanks for reminding me of that article..

Why does it have to be every frame? Why can''t you have an second buffer that you update slowly ( over many many many frames ), and then swap that one with the shadow map that you use for rendering... If you get what I mean...

Death of one is a tragedy, death of a million is just a statistic.

Yes, that's what I'll end up doing for sure. My initial response was that the user might see the shadows quickly change when it switches to the updated one, but I guess I could do some kind of morphing to ease the transition between 2 shadow maps. The sun does move very slowly.

I implemented something earlier today that expanded on the concepts in that last article (not shadow mapping). It's a very crude form of shadow casting, and it's not very dynamic, but the sun doesn't move fast and it produced actually really decent results. The screenshot below shows what happened when I used the technique in the article filisoft showed (the green areas are the added areas of shading due to shadow casting. the dark areas are the fixed T&L pipeline shading). I may stick with this, it was so easy. I'll still learn shadow mapping for other uses though.
Sorry for the size of the image. This is a new computer and I don't have any imaging programs to resize it.



Edit: crappy jpeg...

Actually, I just thought of a way to make it much more dynamic. It's slow because it uses noise to produce the land. I could EASILY use lookup tables and it would take less than a second to recalculate the diffuse component of each vertex when you move a lighted object (that's how I darkened.. heh, the diffuse, it worked..... -_- ) but when there won't be very many vertices, so it shouldn't be slow.

[edited by - okonomiyaki on August 5, 2002 1:02:18 AM]