Jump to content
  • Advertisement
Sign in to follow this  

Terrain: Large Scale, LoD, Dynamic Streaming, and Quick Implementation

This topic is 4414 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

I have seen a lot of heightmap bashing, however, i want some feedback on people's opinions to make my decision. I am leaning on Geometry clipmapping as it has the following advantages: Rapid implementation - My server can easily be configured to generate heightmaps (i believe) and with some work i think i can dynamically stream them to the client in low bandwidth with management. Content Creation - Time is the most valuable thing i can consider. I have only one graphics artist so i will be responsible for terrain period. Parametric Terrain looks like the problem will be generating it. A team of 50 has the resources but my task is to GET R DUN.... Level of Detail - Already in the microsoft algorithm. I know its gonna run comfortably in my system. As SM 4.0 rolls out this will get even more integrated. Mainly LoD is already implemented. Flora - Ive already started to integrate some of the flora i have been designing. In the shader i can probably lod my flora with the clipmap. I think i could render an incredibly large outdoor scene via this lod-ing. Oddly enough the LoD just bleads over to other objects. Disadvantages(not that bad for this project): No overhangs - Not really an issue to me as it will not have much of an effect on the player. Stairstep - *resolved*Im sure this will be resolved by upsampling. I am not even counting this because its going to be resolved most definitely. *Upsampling fixed the problem* Textures - are stretched this takes away from the detail of the scene. Not quite as much a factor if i get the flora where i want it as the flora covers up some of this. Although the more ability i give the terrain to bend the more i notice this even coming into my flora. I think its not just Heightmaps that have this problem but i think it can be resolved in SM 4.0. Memory footprint - i really dont think the memory footprint is that bad. FS X compresses a decent looking heightmap of the US to 355 mb of memory with a 100:1 compression ratio. so your looking at the us in 35gb uncompressed thats nice =) Some people mentioned this is a disadvantage versus splnes. This is what applies to this project and how the decision is leaning. I would rather have bleeding edge flora than overhangs. [Edited by - yoshscout on October 15, 2006 10:12:25 PM]

Share this post

Link to post
Share on other sites
Any of the veterans able to run down the pros-cons of other systems out there? Im particularly interested in parametric surfaces. I understand splines well and kinda have some ideas and am interested in what a geoclipmap would look like if u did it via bezier splines. I think the amount of texture reads would kill you but im just curious.

Share this post

Link to post
Share on other sites
my terrain uses splines... bi cubic surfaces to tesselate.

- Inherently dynamic LOD, but you need to do something about fixing T-junctions
- Smooth rolling hills regardless of distance between control points
- Smooth lighting regardless of tesselation
- 16 control points effectively form a bounding box for the interpolated surface, use for occlusion culling and frustum culling
- Take first derivative (slope) of surface equation to find the interpolated normal, I do this for both lighting and smooth collision detection with the surface (walking along surface is independent of tesselation)
- Take the second derivative (concavity) to find how relatively flat or curvy different parts of the terrain are (I do this to influence my max/min LOD for a particular patch)
- You can change the look and feel of your terrain by simply altering the basis equation. Lets say you want to use Catmull-Rom to interpolate the points instead of approximate... well it's easy, just change your basis matrix.

- Terrain is always smooth, I would recommend implementing several ways to procedurally subdivide... bicubic surfaces for smooth areas, fractals for rocky, mountainous areas, etc.
- You NEED a caching system. Realtime calculation of interpolated points can be optimized to a degree using pre-concatenated matrices, but it is still expensive. Framerate can be jerky when calculating the points of a new patch.
- It is a pain to keep your batches low and batch sizes large when rendering, since crossing patches

My engine's combination of caching the patches using a "super frustum" and very fast frustum culling (using 2d scan conversion of the frustum planes onto the terrain patch grid) and dynamic occlusion culling using a technique I have called "edge buffers" produces excellent frame rates. My rendering bottleneck is no longer the terrain, but how intense I make the shaders, the way it should be I think.

I could post up some screenshots and possibly a demo of the engine if I had somewhere to host it. Any recommendations for that?

I think Geo Clipmapping and Geo Mipmapping are both viable solutions. If you can implement a pixel shader that will render-to-texture for each terrain patch, the interpolation/fractal work will be removed from the CPU. Then you can use the texture in the vertex shader to displace a static vertex buffer.

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!