How do you draw the heightmap if you dont want the whole thing to be drawn. For example you have a 2km x 2km terrain, and the view distance is just 100m.

I guess I could call the DrawArrays function many times so lines of triangles are being drawn. But then if every square is 1m x 1m then I had to call that function 200 times(which is not much but I dont know how expensive is that function). ....or I could divide the heightmap to smaller squares, .....like 50m x 50m ones, ....and check which ones are within the view distance and draw only those.

Im wondering whats the professional way of doing this.

Also how is it done when you want to draw the terrain closer to you with better resolution(like 1m x 1m) and the terrain that is far away with lower resolution(like 10m x 10m)? Thanks!

The most up-to-date resources on terrain rendering come from the Frostbite 3 engine I think and I consider them state of the art". It's a quite involved system and I suggest to focus on your needs, not theirs.

Also how is it done when you want to draw the terrain closer to you with better resolution(like 1m x 1m) and the terrain that is far away with lower resolution(like 10m x 10m)?

You're not considering what currently matters: workload, not "space". Vertex density, not "position in world".

If you pay attention geomipmapping has a problem in that sense because the workload per-drawcall is progressively halved, implying that at a certain point you waste more effort in dispatching drawcalls than you save in vertex processing.

The solution is to apply a "hierarcical" approach. By laying down vertices in the correct order, you can draw 4 chunks in a single call. As the chunks get away from camera, they often converge to a common LOD level. This higher level "super-chunk" takes 4 times the world-space of a standard chunk at roughly the same vertex count.

Thanks! So first I have chunks like 1x1, 2x2, 4x4,.... every chunk containing 4 smaller ones. and then in every frame I decide which chunks should be drawn. But then if every chunk means a separate drawcall then thats a lot. Im not sure I understood it right though.

And how do I handle the "lines" between chunks of different sizes? .....if one has 2x the resolution than the other.

Thanks! So first I have chunks like 1x1, 2x2, 4x4,.... every chunk containing 4 smaller ones. and then in every frame I decide which chunks should be drawn. But then if every chunk means a separate drawcall then thats a lot. Im not sure I understood it right though.

It seems I somehow didn't convey the message.

You must use a "hierarchical" approach. The whole point is: as chunks move away from the observer, they require less detail --> less triangles. Also, nearby chunks will likely have similar (if not equal) LOD level.

So let's say we have a 64x64 vertices chunk (4k, it's still a bit conservative). Next LOD level will have 32x32 vertices. You still resolve their LOD levels separately{1} and find out your terrain is like:

+---+---+---+---+

| 2 | 1 | 1 | 1 |

+---+---+---+---+

| 1 | 2 | 1 | 1 |

+---+---+---+---+

| 2 | 1 | 0 | 0 |

+---+---+---+---+

| 1 | 1 | 0 | 0 |

+---+---+---+---+

See the four chunks at top right. In this case, instead of drawing four LOD1 chunk you might draw a single LOD1 "super chunk".

Similarly, you might be able to draw the two LOD1 chunks at bottom left by splitting in half a LOD1 superchunk (by just limiting draw call primitive count).

So what I'm trying to show is that you specifically don't need to do one call per chunk.

This is of course if you're using geomipmapping. Clipmapping doesn't work that way but I personally don't like it much for small terrains.

And how do I handle the "lines" between chunks of different sizes? .....if one has 2x the resolution than the other.

This is a well known problem. You must resolve possible combinations in advance and fill the gaps. Those "filling" triangles are often referred as "skirts".

Clipmapped terrains have an advantage here as the skirts are basically static.

There's another method having the term "contiguous" that does not need explicit skirting. A beginner told me that it perceived it as a definite advantage. It is basically a vertex-interpolated geomipmapping. By a signal analisys standpoint it is a bit too liberal in my opinion.

{1}: or not, if you want to be super efficient, but I don't suggest to do so.

My suggestion is to not worry about it. Implement pure geomipmapping (which I consider easier than geoclipmaps) with 1 drawcall per batch. Then eventually iterate. Doing superchunks is surely not trivial.

It doesn't need to split buffer objects on the fly. It's just a matter of playing with index values smartly and modifying drawcall data.

But again, I suggest to start simple and scratch your head after you are sure you got a problem with draw call count. I am serious about that.