What is the point of heightmaps?

I've been pond开发者_如何学运维ering this question awhile now... many 3d engines support advanced terrain rendering using quadtrees, LOD... all the features you expect. But every engine I've seen loads height data from heightmaps... grayscale bitmaps. I just can't understand how this is useful - each point in a heightmap can have one of 256 values. But what if you wanted to model Mt. Everest? with detail of 1 meter, or even greater? That's far outside the range of 256. Of course I understand that you can implement your own terrain format to achieve this, but I just can't see why heightmaps are so widely used despite their great limitations.

Heightmaps are very lightweight, very fast to load, and can be generated procedurally fairly easily. They also use quite a small footprint for memory.

They're used a lot because they're easy and fast, and handle many scenarios well. That being said, they're not useful for every scenario, and not a fully generalized terrain format.

From a viewpoint of displaying graphics, the greatest precision that normally matters is (in simple terms) a single pixel in the final display¹. Given the resolution of a typical current monitor, having another couple or three bits for the height map would be nice -- but for most geometry, it's not really necessary. In particular, even though a single pixel pretty much defines the greatest precision for which you have a lot of use, drawing Mt. Everest so its height is actually wrong by two or three pixels isn't really a major problem for most people most of the time.

It comes down to this: the idea that you'd want to use a precision of one meter for a height map of Mt. Everest is simply a mistake -- a need (or even use) for that level of precision is right on the border between rare and nonexistent. At the same time, using a relatively dense format like one byte per pixel generally means quite a bit -- less storage and less bandwidth leading to faster displays.

1. Technically with anti-aliasing, sub-pixel resolution can and does mean something -- but while it matters a lot for things like smoothing lines that would otherwise look quite jagged, for something like getting the height of a mountain correct, it doesn't mean nearly so much. In fact, as far as most people care most of the time, it's completely meaningless.

Heightmap Pros:

1. Look like real terrain from a distance.
2. Very easy to compute height at any x, y assuming z is up. This is useful for moving players, collision detection, and physics.
3. Easy to edit in a paint program.

Heightmap Cons:

1. Use memory inefficiently when there are large flat areas (constant height).
2. Use rendering hardware inefficiently when there are large flat areas.
3. Can't represent steep or overhanging terrains.
4. Can only represent square areas.

But what if you wanted to model Mt. Everest?

You'd use something else. Clearly, if every engine you've encountered uses heightmaps, it works just fine for them. No need to overcomplicate things if the simple solution works for you.

Another plus with heightmaps is that in general it avoids the overhang issue which makes aspects of physics and movement harder. But even with a hightmap, you can have other geometry that could create overhangs.

Also, texturing can be simpler as long as the height doesn't vary too much causing stretching.

Heightmaps have the advantage that has direct hardware support (texturing), and it can be draw using existing painting tools (even specialized).

Of course, depending on the format of the information stored in the heightmap, some rendering doesn't looks like it should be, but because heightmaps are actually used in the wrong situation.

As enhancement, heightmap pixels could be stored in a 16 bit floating number (half float) or a 32 bit float, allowing to have higher ranges and precision allowed with an 8 bit pixel with fixed precision.