Archived

This topic is now archived and is closed to further replies.

Igilima

Practical to use greater than (8) bit depth (256 grayscale) heightmap for terrain?

Recommended Posts

From most of what I have read, I have gotten the impression that alot of people use 256bit grayscale images for their heightmaps. Is this really the case? If this is so, is there some reason people don't go with one that allows for more than 256? I'd like to get more than 256 heights to my terrain. I'm wanting to know if this is impractical and why before I go off and try it. [edited by - igilima on July 29, 2003 11:40:26 AM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
heightmaps are generally hand drawn... so theres no reason to use more than 8bits. a 256bit grayscale is very detailed... 8bits = 0-255

Share this post


Link to post
Share on other sites
Well, I''d like to have a little more range than 256. I might generate some of it by hand but I think for the scale I am looking for, I would go with a random procedural generation.

Share this post


Link to post
Share on other sites
I think the problem is that if you''re building a huge landscape.. the difference between a 1-byte value and a 4-byte value is the same as 64MB landscape against a 256MB landscape. If it''s small, it''s fine.. and you could just as easily use shorts.. though, that would double the size..

Share this post


Link to post
Share on other sites
Yeah the shorts will make the life A LOT easier.For example the low byte can be the height value and the hight byte can be some sort of a flag that tells something important for the segment.

"You losers better learn...NOONE CONTROLS OUR GOD DAMN LIFE!!!" - MANOWAR

Share this post


Link to post
Share on other sites
I think the reason 8bit values are used is because if you''re getting a heightmap from a paint program you only have the option to save greyscale as 16 or 256 levels of gray.

I''ve always held 256 height levels is very limited. In a big map you could easily have a difference of 100s of metres between highest and lowest points which implies your vertical resolution is only ~1m which sucks. Using 32bit ints or floats is memory hungry and almost certainly overkill so the easiest acceptable option is to use 16bit ints.

However I''ve found a better system in my engine. My landscape is broken into sections (if you use a quadtree this is forced on you anyway) and each section has a base height which can be as high precision as you want. Then the height values for vertices are given by adding the base height with an 8bit value from a local heightmap for that section. This gives great height resolution as well as good memory use. Using chunks of terrain like this with individual heightmaps also lets you optimise your map - the chunks don''t all have to be at the same detail level - one might be 32x32 vertices and another 4x4 which saves a lot of memory. Or you can even have sections of the map missing if you''re not going to go there - very handy for non-rectangular maps!

Share this post


Link to post
Share on other sites
quote:
Original post by d000hg
I think the reason 8bit values are used is because if you''re getting a heightmap from a paint program you only have the option to save greyscale as 16 or 256 levels of gray.



You''re wrong my friend.The paint programs are capable of saving the so called "grayscale-alpha" images.Which is exactly 16 bits per pixel.


"You losers better learn...NOONE CONTROLS OUR GOD DAMN LIFE!!!" - MANOWAR

Share this post


Link to post
Share on other sites
quote:
Original post by Mihail121
You''re wrong my friend.The paint programs are capable of saving the so called "grayscale-alpha" images.Which is exactly 16 bits per pixel.



true, but most paint program have each channel limited to 8 bits per channel, so even if you can save 16-bits per pixel, you cannot paint to it intuitively as you could to a single grayscale value. it isn''t about storing 16 bpp, its about painting it.

photoshop can do 16 bits/channel, but I would recommend using cinepaint (a gimp fork) which can handle a variety of bitdepths).

but painting heigthmap is akward imo, so I prefer to be able to alter the heightmaps interactively in 3D.

Share this post


Link to post
Share on other sites
I use 16 bit heightmaps, since 8 bit values simply do not give high enough resolution to represent more extreme real world altitude differances. But then, I usually don''t draw my heightmaps by hand, but instead use modified USGS data, which is provided in 32 bit float format.

Share this post


Link to post
Share on other sites
quote:


Original post by vember

but painting heigthmap is akward imo, so I prefer to be able to alter the heightmaps interactively in 3D.




The best decision possible!


"You losers better learn...NOONE CONTROLS OUR GOD DAMN LIFE!!!" - MANOWAR

Share this post


Link to post
Share on other sites
The base height idea sounds interesting but you might have problems with keeping the edge transitions smooth.

Does it really save you that much memory?

Yeah, painting a terrain with a paint tool is not what I had in mind. I''d much rather generate my terrain procedurally or use existing data (like the maps mentioned above) and then tweak it if needed.

Share this post


Link to post
Share on other sites
would it not be possible to store it such that each signed byte represents the offset from its neighbor? This restricts you to not having drops of more than 128 meters between vertices, but it should work fine otherwise...just a thought..



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."

Share this post


Link to post
Share on other sites
There are many ways to compress, and they all depend on how your terrain works. Offsetting is one pretty simple and effective method, but again, it depends on how big your terrain is, what it looks like, how it''s stored etc...
Doing heightmaps is pretty awkward, and that''s the reason I started working on an editor. It updates a rendered display of the terrain as the user paints on a heightmap, so you see every single stroke clearly. Still, it''s a bit awkward and I''ll let the artists make the heightmap

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
you could use 9bits to store each height, where the 9th bit tell if the height is minus or plus. That way you could have any height from -255-255 or 0-512

Share this post


Link to post
Share on other sites
quote:
Original post by Igilima
The base height idea sounds interesting but you might have problems with keeping the edge transitions smooth.

Does it really save you that much memory?

There are consideration in joining sections but it''s quite simple to fix this. It definitely saves me a lot of memory - I''m effectively on 8bit heightmaps (an extra 4 bytes per 32x32 chunk is nothing), on a 1024x1024 map thats a saving of either 1 or 3Mb compared to 16/32bit values. And since I''m currently only using 5bytes/vertex thats a 20-30% saving which is very significant!
My precision is also very good - I have 256 levels but also a scaling factor for each section so that the 256 levels are totally used. So on a flattish section my resolution is as good as 1mm wheras on a bumpy section maybe 100mm - still very accurate I think.
quote:
would it not be possible to store it such that each signed byte represents the offset from its neighbor? This restricts you to not having drops of more than 128 meters between vertices, but it should work fine otherwise...just a thought..
Maybe but I think not. Or not easily. A vertex in a heightmap has 8 neighbours so which do you use - there''d be many ways to get from (0,0) to (x,y) giving different heights I think.
quote:
you could use 9bits to store each height, where the 9th bit tell if the height is minus or plus. That way you could have any height from -255-255 or 0-512
But one thing we really want to do is stay close to the macinery which means no native 9bit types. Anything other than 8,16,32 bits is troublesome and memory inefficient. A 9bit type would be padded to 16bits anyway.

Share this post


Link to post
Share on other sites
8-bit is not enough for any serious use. 16-bit takes more space, but data compression can be done easily, in numerous way. Some quick hints for you to think about it :
- you''re not limited to 8-bit, 16-bit and 32-bit, you could just use 12-bit or just any value
- a big difference in height doesn''t happen all the time in a "normal" terrain, you can use that property to optimize the heightmap and break it into different "zones", each of them having a particular height precision and a base level
- displacement maps usually have a 16-bit depths
- ok I''m too lazy to type more

Share this post


Link to post
Share on other sites
I almost choked when he said "256 bit grayscale"... "God Damn, dude, how much ****in'' detail do you need?"

Anyways, yeah, I''ve yet to see a practical heightmap which needed more than 12 bits (0-4095) of detail to look damn good.

Share this post


Link to post
Share on other sites