Best Terrain Heightmap File Format
Author
Hi,
I have a terrain heightmap internally as an array of floats. What is the best way to represent this as a file? Is there a standard that is used by other programs?
Thanks
Raeldor,
Often times heightmaps are stored in standard image formats such as bitmap or tga. The reason for this is relatively simple, both heightmaps and images are 2d representations of data that varies over x and y.
As well, storing it as an image allows you to view the image in "gray-scale" so you can see what your heightmap looks like in any standard paint program. In addition, if you write a reverse import back into your engine from a gray-scale image, users can actually manipulate the heightmap using standard spray tools in photoshop, etc...
Finally, there are a number of well respected, lossless compression algorithms that work on images. This enables you to compress your "heightmap" until you load them - which can be favorable if you've got levels 512x512 or higher.
Cheers, mate! Hope this helps!
Often times heightmaps are stored in standard image formats such as bitmap or tga. The reason for this is relatively simple, both heightmaps and images are 2d representations of data that varies over x and y.
As well, storing it as an image allows you to view the image in "gray-scale" so you can see what your heightmap looks like in any standard paint program. In addition, if you write a reverse import back into your engine from a gray-scale image, users can actually manipulate the heightmap using standard spray tools in photoshop, etc...
Finally, there are a number of well respected, lossless compression algorithms that work on images. This enables you to compress your "heightmap" until you load them - which can be favorable if you've got levels 512x512 or higher.
Cheers, mate! Hope this helps!
Author
Quote:Original post by jwalsh
Raeldor,
Often times heightmaps are stored in standard image formats such as bitmap or tga. The reason for this is relatively simple, both heightmaps and images are 2d representations of data that varies over x and y.
As well, storing it as an image allows you to view the image in "gray-scale" so you can see what your heightmap looks like in any standard paint program. In addition, if you write a reverse import back into your engine from a gray-scale image, users can actually manipulate the heightmap using standard spray tools in photoshop, etc...
Finally, there are a number of well respected, lossless compression algorithms that work on images. This enables you to compress your "heightmap" until you load them - which can be favorable if you've got levels 512x512 or higher.
Cheers, mate! Hope this helps!
Thanks for the info. Wouldn't I lose a resolution of detail though, going from float to a grayscale value? Are there grayscale formats that can use more than 8-bits per pixel?
Thanks
Raeldor,
You are absolutely correct. If you're simply using gray scale you have height steps in the range of 0 to 255. You then multiply the values by a floating-point scale value which helps to spread or normalize the heights over a smaller or larger range. Whether or not you can use a grayscale depends on the terrain. If your terrain is very expansive, with large peeks and deep chasms, you'll likely be unable to represent the terrain with only 8 pits per pixel. On the other hand, if your terrain is made up of mostly values, with your difference in height being 64 or 128 meters in difference, you can easily multiply the height value with a scale of 0.25 or 0.5 and get a relaively smooth terrain.
Additionally, you could use a logarithmic scale function as your scale factor. In this way, terrain near the 0 plane will be very high resolution and extremely accurate, while talk peeks and deep chasms tend to be less accurate.
Finally, if none of this allows you the resolution you need, you can always store your 32 bit float values in a 32 bit pixel format, such as RGBA or ARGB. In this way, the terrain can often look strange in an image editing tool unless you swizzle some of the terms. Hope this helps!
You are absolutely correct. If you're simply using gray scale you have height steps in the range of 0 to 255. You then multiply the values by a floating-point scale value which helps to spread or normalize the heights over a smaller or larger range. Whether or not you can use a grayscale depends on the terrain. If your terrain is very expansive, with large peeks and deep chasms, you'll likely be unable to represent the terrain with only 8 pits per pixel. On the other hand, if your terrain is made up of mostly values, with your difference in height being 64 or 128 meters in difference, you can easily multiply the height value with a scale of 0.25 or 0.5 and get a relaively smooth terrain.
Additionally, you could use a logarithmic scale function as your scale factor. In this way, terrain near the 0 plane will be very high resolution and extremely accurate, while talk peeks and deep chasms tend to be less accurate.
Finally, if none of this allows you the resolution you need, you can always store your 32 bit float values in a 32 bit pixel format, such as RGBA or ARGB. In this way, the terrain can often look strange in an image editing tool unless you swizzle some of the terms. Hope this helps!
Author
Quote:Original post by jwalsh
Raeldor,
You are absolutely correct. If you're simply using gray scale you have height steps in the range of 0 to 255. You then multiply the values by a floating-point scale value which helps to spread or normalize the heights over a smaller or larger range. Whether or not you can use a grayscale depends on the terrain. If your terrain is very expansive, with large peeks and deep chasms, you'll likely be unable to represent the terrain with only 8 pits per pixel. On the other hand, if your terrain is made up of mostly values, with your difference in height being 64 or 128 meters in difference, you can easily multiply the height value with a scale of 0.25 or 0.5 and get a relaively smooth terrain.
Additionally, you could use a logarithmic scale function as your scale factor. In this way, terrain near the 0 plane will be very high resolution and extremely accurate, while talk peeks and deep chasms tend to be less accurate.
Finally, if none of this allows you the resolution you need, you can always store your 32 bit float values in a 32 bit pixel format, such as RGBA or ARGB. In this way, the terrain can often look strange in an image editing tool unless you swizzle some of the terms. Hope this helps!
Thanks for clarifying. Which route to most games take? Do most try and stay within the 8-bit limit, or does the editing tool have import/export to/from these formats and then allows more detail via a binary export into the engine itself?
I would just store your heightmap as a 16bit or 32bit RAW file format. FarCry uses the 16bit RAW format, but again, you can only get height values from 0-65000. By using 32bit, you have as much freedom as possible.
I hear a lot of people saying, "Well you'll never need that much precision!!"
Well, use a terrain editor to make a heightmap, export it to 8bit and 16bit. Then reload it back in, and you'll know a HUGE difference in precision.
I hear a lot of people saying, "Well you'll never need that much precision!!"
Well, use a terrain editor to make a heightmap, export it to 8bit and 16bit. Then reload it back in, and you'll know a HUGE difference in precision.
Author
Quote:Original post by oconnellseanm
I would just store your heightmap as a 16bit or 32bit RAW file format. FarCry uses the 16bit RAW format, but again, you can only get height values from 0-65000. By using 32bit, you have as much freedom as possible.
I hear a lot of people saying, "Well you'll never need that much precision!!"
Well, use a terrain editor to make a heightmap, export it to 8bit and 16bit. Then reload it back in, and you'll know a HUGE difference in precision.
Thanks. So you store as integer values not floating point numbers? Do you ever use a scaling factor to get more accurate precision than 1 unit? What is the standard measurement of the 3D unit? Does it usually represent 1ft or 1 meter?
Regards
If you use a 32bit RAW file format, then you can simply store the actual floating point value. Since a float takes up 4 bytes, so a 32bit image.
If you use a 16bit RAW format, then when you're done editing the terrain, you simply scale the largest height value to 2^16, then scale every other pixel by that scale value. When you reload it, you simply divide each value by that scale value and store the result in a floating point value.
If you use a 16bit RAW format, then when you're done editing the terrain, you simply scale the largest height value to 2^16, then scale every other pixel by that scale value. When you reload it, you simply divide each value by that scale value and store the result in a floating point value.
Author
Quote:Original post by oconnellseanm
If you use a 32bit RAW file format, then you can simply store the actual floating point value. Since a float takes up 4 bytes, so a 32bit image.
If you use a 16bit RAW format, then when you're done editing the terrain, you simply scale the largest height value to 2^16, then scale every other pixel by that scale value. When you reload it, you simply divide each value by that scale value and store the result in a floating point value.
Cool, thank you. Is there any standard format that people use for this kind of thing? Ie, 16-bit raw... what is the unit of measurement? Feet? What about ground below 0 (ie below sea level), does sea level start at a specified value?
I guess if people do their own thing, that's cool, but I am finishing off my terrain editor and would like to have options to import and export that would be useful to people.
Thanks
If you want it easy to view/edit the height data, an 8-bit greyscale image is the easiest but has severe limitations as discussed already. I beleive there may be some image editors which can cope with a 16bit greyscale image but I really don't know about that...
I'd agree that 8 or even 16 bit is not enough for detailed terrains. However 32bit is very memory hungry when you want to download it!
My Level Editor stores heightmaps in 32bit floating point format for maximum precision and ease of use. However when I want to use a map in the game, I 'export' the .map file to a .lev file. In the .lev file, heightmap data is 8bit. HOWEVER, the level is split into chunks (normally 32x32, also used as leaves in my quadtree). Each chunk has a base height value and a scaling factor (both floating point).
ie: Height(x,y) = GetChunk(x,y).GetBaseHeight() + GetChunk(x,y).Scaling * GetChunk(x,y).GetHeight(x,y)
Over a 32x32 chunk of the terrain, height isn't likely to vary a huge amount, so your 8bits is very good. I had a routing which told me what the height accuracy was for each chunk when generating it. It varied from 1mm for flattish sections to 5-10cm for steep slopes.
I find this to be an excellent solution.
I'd agree that 8 or even 16 bit is not enough for detailed terrains. However 32bit is very memory hungry when you want to download it!
My Level Editor stores heightmaps in 32bit floating point format for maximum precision and ease of use. However when I want to use a map in the game, I 'export' the .map file to a .lev file. In the .lev file, heightmap data is 8bit. HOWEVER, the level is split into chunks (normally 32x32, also used as leaves in my quadtree). Each chunk has a base height value and a scaling factor (both floating point).
ie: Height(x,y) = GetChunk(x,y).GetBaseHeight() + GetChunk(x,y).Scaling * GetChunk(x,y).GetHeight(x,y)
Over a 32x32 chunk of the terrain, height isn't likely to vary a huge amount, so your 8bits is very good. I had a routing which told me what the height accuracy was for each chunk when generating it. It varied from 1mm for flattish sections to 5-10cm for steep slopes.
I find this to be an excellent solution.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
