Rendering Large Terrain

Hello all!

I am trying to render a large terrain in OpenGL. My terrain consists of multiple terrain blocks of size 1000x1000 meters (1001x1001 vertices).
Each block consist of multiple driangle strips drawn by means of the glMultiDrawElements(GL_TRIANGLE_STRIP, …) function.
But when I for example create a terrain of size 6x6 kilometers (6x6 blocks) I get a poor performance (only about 2fps).

How could I improve It? Can I use triangle strips or should I use another primitive type if I want to use a LOD technique?
Is there a simple terrain LOD tutorial for beginers with a simple code samples which explains it step by step?
All tutorials I have found were too much theoretical or were very complex and complicated for learning.

Could you please help me?

Thanks so much :slight_smile:

-Martin

What OpenGL version and graphic card are you using?
Could you show us how are you drawing that meshes?

Edit: Triangle strips are (usually) one of the fastest modes so there’s no problem with that.

I am using Nvidia GeForce gt555m (notebook) with OpenGL 4x, but I like to preserve compatibility with OpenGL 3x.
The terrain meshes are drawn by means of the glMultiDrawElements function, i. e. terrain of the size for example 1x1 km consists of 1000 triangle strips of width 1m and length of 1 km.
The vertices are stored in an float array of size 1000x1000x3. The first triangle strip has indices 0, 1000, 1, 1001… The second strip has indices 1000, 2000, 1001, 2001… etc…

I would like to use a LOD technique because I think that drawing a large terrain without LOD is too clumsy. But I don’t know where to start…

[ul][li]Save your height vertices in a height map[/li][li]Save a terrain block (chunk) as a VBO (preferrably much smaller than yours, 32x32 has proven to be good)[/li][li]Write a drawing function: Define what to draw and how detailed to draw it based on the distance to the camera[/li][li]Draw it instanced (all the necessary information for each chunk can be stored in 4 floats)[/ul][/li]
An old image of mine displaying the precision of the chunks can be found here.

Okay, so I should learn instanced rendering first. I have never did it…

Not necessarily. Most terrain rendering algorithms don’t use instancing. I prefer clipmaps.
Take a look at vterrain.

If you’re able to leverage tessellation, this approach is also noteworthy. Or this.

Tessellation shader approach is not superior to vertex shader approach because of at least two reasons: VS has wider support and there is no limitation on the size of the blocks.

Aleksandar: I didn’t say it was superior or the only way - I just proposed it as another contemporary alternative. It’s definitely better than ROAMing. :wink:

Sorry, I didn’t want to offend you.
Definitely better! ROAM is a prehistoric algorithm.

Sorry, I didn’t want to offend you.

None taken! Afterall, this isn’t StackOverflow. :wink:

ROAM is a prehistoric algorithm.

Yeah, implemented that years ago, pretty neat in theory though. I wonder how far one can push it with current GL features …

I mean even with tessallation it’s basically a progressive mesh approach - not too different from ROAM. The biggest issue with classical ROAM is that except for the final rendering, it’s purely CPU based.

ROAM appeared in a time when GPUs could render very few triangles. So, it was important to decrease their number. ROAM is very CPU intensive.
On the other hand, nowadays GPUs can render immense number of triangles, especially if the “pattern” is good. So, regular grid approach is the best choice in the last decade.
Now it is more important to efficiently feed GPU than to optimize the number of triangles. That’s why I prefer clipmaps. I have finished “my version” of clipmaps and I hope I’ll make it public soon.
Ups, I didn’t mean to advertise! :wink:

I have finished “my version” of clipmaps and I hope I’ll make it public soon.
!

Giev! Need! :wink: Looking forward to it!

Thank you folks :slight_smile:

So I will now focus on geoclipmaping.
I have found this site: http://malideveloper.arm.com/develop-for-mali/sample-code/terrain-rendering-with-geometry-clipmaps/.
May it be?

To Alexandar: …I am also looking forward to your version of clipmaps :slight_smile:

If some one follow my questions on the forum maybe could assume what I’m working on. Just to make a short announcement (sorry for hijacking the thread) I have succeeded to make clipmaps applicable to real ellipsoid (in my case WGS84, since I’ve applied it to Earth visualization). Ellipsoid is subpixel exact using just single precision on the GPU for all distances, from several millions of km to several micrometers from the surface. Another benefit is 1:1 vertex to source data mapping. Something that Spherical clipmaps could’t have (that’s the main reason that algorithm didn’t succeed to be popular).

I’ll also suggest reading an original paper (or to be more precise, a book chapter). And for the start, I’ll recommend to make levels of just a single block. Also, don’t bother with compression/decompression at the start. Use shorts for hight values (a single channel 16-bit texture) and DXT1 for texture-overlay.

Yes, thank you for that paper, I am studying it right now. It looks that it is written for DirectX but I think it will help me anyway :slight_smile:

It looks that it is written for DirectX but I think it will help me anyway

This cannot be surprising, Hugues Hoppe being a principal researcher at Microsoft Reasearch. :wink:

However, from my experience, mapping the algorithm to OpenGL is straightforward.

Yes, I have found that some things are similar to DirectX :slight_smile: …That paper helped me very much, but there is just one thing I don’t understand: do I need just one height texture for whole terrain? Won’t it be too big?
…And in the paper there is written : “During the update step, we modify regions of these textures by rendering to them using a pixel shader.” Is it possible to render to texture using a GLSL shader? I have never heard about it… Thanks for help

Is it possible to render to texture using a GLSL shader?

At least two, the usual render-to-texture approach using framebuffer objects and image load/store - however, the most recent GPU clipmaps paper is from 2005 and the latter was only introduced in GL 4.2 and I think D3D11 (or 10.1). I’d have to read through the paper again because I really don’t remember that part.

do I need just one height texture for whole terrain? Won’t it be too big?

I can’t think of any other approach than the obvious two: either you have the whole terrain in memory or you only have chunks and stream the chunks you need (also, with sparse textures this can get very efficient).

IIRC, the clipmaps paper proposes a decompression stage on the GPU (and a compression stage on the CPU) so they can get their complete height-map down to 400 something MBs in VRAM.

That said, you don’t need compression/decompression at all for implementing the rest of the paper.