Improving terrain lighting (pics!)

Started by
15 comments, last by OrangyTang 19 years, 7 months ago
The shadows are really too dark.
In shadowed areas it´s just black...
Can you post some pics with brighter shadows?

My engine use another realtime soft-shadow approach.
(I hope i will find enough time to write a paper about it ;) )





Advertisement
Here is a link to a previous discussion about a "sunrise map" concept :

http://www.gamedev.net/community/forums/topic.asp?topic_id=252447

It's a specialization of horizon mapping for sunlight and terrains. This might speed up the computation per fragment a lot and save memory. It's not much more that adding a lightmap blending pass. I also plan to use something equivalent for lighting in texture space thus no need for shaders and high end GPUs.
"Coding math tricks in asm is more fun than Java"
Quote:Original post by Etus
OrangyTang, can you try doing the terrain lighting using per-vertex lighting and using your form of horizon mapping and post the FPS results?

I could give it a go, but to crowbar it into my existing stuff might be a tad tricky. As you say terrains are typically well tessalated so it would probably be very similar in final output, but as the AP pointed out it'll cause problems with LOD.

One of the things I've been trying to keep up is a smooth LOD scheme without any popping or visual 'jumps'. So that includes geomorphing between LOD levels and keeping texture splats in an alpha texture rather than vertex alphas. While the horizon texture is pretty low res it can be used at all LOD levels regardless of tri count. I'm going to do the same thing with normals into a bumpmap texture so you can fake the high-tesselation details at low LOD levels (much how doom3 fakes much of its surface detail).
Quote:Original post by Trienco
now you make me think about wild methods like storing a texture with values like
r: time of begin shadowing
g: time of max shadowing
b: time of end shadowing
a: darkness of shadowing

where you just do shadowing depending on daytime and maybe abuse value clamping to further your goals and replace if instructions. hmmm.. nah, sounds like too much work just for shadows.

I don't follow why you'd need all this extra vars. Horizon mapping only needs a single angle - the angle at which the horizon is visible from the current point. If the suns above that, light it. Otherwise shadow it. When you've got a heightfield you simplify that down to two horizon angles (for sun set and sun rise) and use two different textures, then switch between them as appropriate.

This does leave the GB channels in the texture unused however. I was thinking of adding a distance-to-horizon and softening the shadow edges base on that, but that tends to happen naturally because of the more gradually chaning angles (at least, with an infinate-distance sun it doesn't require any extra work). The other possible idea was using all of them for packing the horizon angle for greater precision. However in practice that didn't have much noticable visual improvement but a definate large framerate hit.
Quote:This does leave the GB channels in the texture unused however


Who's forcing you to use an RGB texture? Why not just R?
Just the start and end 'time' of the shadow will do.
Quote:Original post by Cypher19
Quote:This does leave the GB channels in the texture unused however


Who's forcing you to use an RGB texture? Why not just R?

'Cos I havn't looked up how to create a single channel texture in OpenGL yet. So nothing really.

Oh, and as CV requested some with some ambient, a couple of shots with the same view but different sun angles:

This topic is closed to new replies.

Advertisement