Jump to content
  • Advertisement
Sign in to follow this  
Ivo Leitao

terrain lighting

This topic is 4883 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

What is the best way to light a terrain using geomipmapping ? I'm currently calculating the normals, but i have read somewhere that the changes in detail can cause strange effects. So what is the best way to do it. I have read something about lightmaps but i'm not sure if i have understand it correctly...

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by Supernat02
It depends. Do you want static lighting or dynamic lighting?


In a real engine what is the most used method ? For example if i want to have a dynamic change in the terrain can i use static lighting ?

Well the main problem here is that i don't know the implications of that methods in the features of a terrain engine...

Share this post


Link to post
Share on other sites
Well static lighting is generally using light maps, places that the light won't change. For instance, inside a building, the light from the center of the room will get dimmer on the far walls. On outdoor scenes, I suppose dynamic lighting would be more popular, because you have a sun and moon (if you support such things). It can be a lot more complex though. If you use static light maps on your terrain, I don't think you'd see the changes in detail (other than the popping associated with geomipmapping). If your normals were changing, I'd expect to see the light intensity change occassionally. You may want to consider other methods of terrain generation.

I've heard that a lot of people are just going to a more brute force approach since video cards are becoming so powerful. Not purely brute force of course, but closer. There's other methods also. However, if you want to keep geomipmapping, I wouldn't recommend using DX lighting, just because I do think it will show up worse. Light maps may be the way to go.

Share this post


Link to post
Share on other sites
Quote:
Original post by Supernat02
Well static lighting is generally using light maps, places that the light won't change. For instance, inside a building, the light from the center of the room will get dimmer on the far walls. On outdoor scenes, I suppose dynamic lighting would be more popular, because you have a sun and moon (if you support such things). It can be a lot more complex though. If you use static light maps on your terrain, I don't think you'd see the changes in detail (other than the popping associated with geomipmapping). If your normals were changing, I'd expect to see the light intensity change occassionally. You may want to consider other methods of terrain generation.

I've heard that a lot of people are just going to a more brute force approach since video cards are becoming so powerful. Not purely brute force of course, but closer. There's other methods also. However, if you want to keep geomipmapping, I wouldn't recommend using DX lighting, just because I do think it will show up worse. Light maps may be the way to go.


Tnks a lot for your answer, i see that in our opinion the geomipmapping algorithm is not the best one in face of today's hardware. Could you recomend me a better terrain algorithm ? I'm not very experienced in terrain algorithms and i have chosen the geomipmapping because i think it's the easiast one...

Share this post


Link to post
Share on other sites
Well there are several others to choose from. In my opinion, one of the best I've seen lately is clipmapping. Clip map levels are rather easy to implement, but kinda hard to describe. I am looking at doing a tutorial on them for gamedev, if only I had the time. Consider a flat terrain, 256x256 vertices. Consider a smaller subset inside that terrain, 128x128 vertices. Then one that is 64x64, etc. If you, as the player, are exactly in the center of that terrain, you want a lot of detail immediately around you (the 8x8 vertex area for instance), and then the further you get out, you don't need as much detail. That's kind of the basis for the algorithm.

As your view moves across the terrain, you continually update the levels. The coolest thing about this method is that it can be done almost completely in the GPU using only a handful of vertex and index buffers, and can display a terrain limited only by the size of your system memory!! You'll have to have vertex shader and pixel shaders though. I think only version 3.0 vs supports getting a value from a texture map (which is required), so you may be further limited by that.

I used really small numbers too. Each level may be 255x255 vertices (I can't explain right now why 255 instead of 256, but if you read about it, it will make sense). I would recommend the only source I've found so far on it, a book called GPU Gems 2. It's chapter 2. You may also be able to locate sources on the web.

Share this post


Link to post
Share on other sites
Quote:
Original post by Supernat02
Well there are several others to choose from. In my opinion, one of the best I've seen lately is clipmapping. Clip map levels are rather easy to implement, but kinda hard to describe. I am looking at doing a tutorial on them for gamedev, if only I had the time. Consider a flat terrain, 256x256 vertices. Consider a smaller subset inside that terrain, 128x128 vertices. Then one that is 64x64, etc. If you, as the player, are exactly in the center of that terrain, you want a lot of detail immediately around you (the 8x8 vertex area for instance), and then the further you get out, you don't need as much detail. That's kind of the basis for the algorithm.

As your view moves across the terrain, you continually update the levels. The coolest thing about this method is that it can be done almost completely in the GPU using only a handful of vertex and index buffers, and can display a terrain limited only by the size of your system memory!! You'll have to have vertex shader and pixel shaders though. I think only version 3.0 vs supports getting a value from a texture map (which is required), so you may be further limited by that.

I used really small numbers too. Each level may be 255x255 vertices (I can't explain right now why 255 instead of 256, but if you read about it, it will make sense). I would recommend the only source I've found so far on it, a book called GPU Gems 2. It's chapter 2. You may also be able to locate sources on the web.


I'm also looking at that method, but i have not found any implementation yet, the only reference is on the site of huges hoppe (http://research.microsoft.com/~hoppe/) and on the already mencioned game programming gems 2. Also there is a stripped down version which i think (can anyone confirm this ?) does not need to version 3.0. The big question here is, if that method is appropriate for games, or if it's ony useful for terrain rendering (anyone ?)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!