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.

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

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

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.

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