Height Maps, One Per Quad, or One Big One ?

Started by
1 comment, last by PhillipHamlyn 11 years, 2 months ago

Hi,

I'm trying to work out the best implementation for a terrain height map. I currently have a choice between "one big" height map or "one per tile quad". Advantages/Disadvantages as I see it are;

"One Big" => consistent height sampling irrespective of quad scale. Single state switch covering all terrain quads (assuming the Scale World matrix neccessary to map the individual quads UV sample coords doesn't in itself cause a state switch). Disadvantages; cannot increase height resolution for more detailed quads without introducing an extra "noise" heightmap. Limited world size based on max texture size for heightmap.

"One Per Tile Quad" => can scale height map based on tile resolution - more detailed heights for more detailed quads. Lots of state switching (at least one per tile rendered as they have a unique heightmap per tile). Inconsistent height sampling where detail levels change at skirts - neccessitates "welding" height values from the parent tile to the child quads at heighmap writing time to prevent ripping. World detail and size unlimited by texture sizes.

What approach is generally favoured for large landscapes ? I'm just trying to prevent going off down the wrong rabbit hole.

Thanks

Phillip

Advertisement

At an high-level, let's say at DCC tool / artist / authoring level each terrain chunk has a single heightmap. If you slice it internally, nobody cares. The problems you note in the "one per tile quad" section are typical issues with tiled algorithms, I suggest you google more. Each algorithm has its own way of dealing with this.

For unlimited world, Geometry Clipmaps are the only thing that buy me.

Previously "Krohm"

Krohm

Thanks for the pointer. I'll follow up on the Clipmaps idea - its far superior to my current design.

This topic is closed to new replies.

Advertisement