View more

View more

View more

### Image of the Day Submit

IOTD | Top Screenshots

### The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

# How to draw the heightmap properly?

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

7 replies to this topic

### #1Aliii  Members

Posted 25 September 2013 - 10:06 AM

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!

### #2WarAmp  Members

Posted 25 September 2013 - 01:40 PM

Geo-mipmapping (http://en.wikipedia.org/wiki/Geomipmapping) and

Geo-Clipmapping (http://research.microsoft.com/en-us/um/people/hoppe/gpugcm.pdf)

Are the most common ways of doing this.

Waramp.Before you insult a man, walk a mile in his shoes.That way, when you do insult him, you'll be a mile away, and you'll have his shoes.

### #3MaxDZ8  Members

Posted 26 September 2013 - 01:09 AM

Im wondering whats the professional way of doing this.
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".

Divide your chunks so you have enough workload per-drawcall. How much? I'd say at least 4k vertices.

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.

For extreme closeups however you'll need some noise-based procedural synthesizing technique and that's another whole problem in itself.

I'll stop there for the time being.

Previously "Krohm"

### #4Aliii  Members

Posted 26 September 2013 - 01:40 AM

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.

### #5MaxDZ8  Members

Posted 26 September 2013 - 07:28 AM

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.

Previously "Krohm"

### #6Aliii  Members

Posted 26 September 2013 - 08:53 AM

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

...

...at bottom left by splitting in half a LOD1 superchunk

How do I do that? I cant split up and join buffer objects on the fly in every frame. Actually, Im still too much of a beginner, Im not sure Im ready to understand this, let alone implement it:)

### #7MaxDZ8  Members

Posted 26 September 2013 - 12:16 PM

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.

Previously "Krohm"

### #8Aliii  Members

Posted 26 September 2013 - 02:46 PM

Yep, I will choose a simpler solution. Thanks for the info!

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.