# 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.

## Recommended Posts

##### 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 on other sites
my terrain uses splines... bi cubic surfaces to tesselate.

Pros:
- 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.

Cons:
- 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.

1. 1
Rutin
36
2. 2
3. 3
4. 4
5. 5

• 12
• 14
• 9
• 9
• 14
• ### Forum Statistics

• Total Topics
633344
• Total Posts
3011438
• ### Who's Online (See full list)

There are no registered users currently online

×