I''ve been using 8bit grayscale heightmaps for a while, and notice (as many people have) that their... precision isn''t too great. The suggestion is usually to move to a more precise data medium (like using 16 bits, or floating point.) My question is, that''s all good and fine, but then I can''t just pop it into Paint Shop Pro if I feel like editing (or creating one in the first place) the image. How do you generally get around this? Are there any well known, good programs out there that can edit 16 bit heightmaps? (Does the HDRI toolkit or whatever do this? I''ve never used it.) Or do you write your own editor and call it good. (My only problem with this route is the involved time to write a good heightmap/image editor) Does anyone just load the 8bit values into floats and smooth the thing, or is this wasteful and useless if you wanted that gentle slope (like 1/10 slope, it''s not going to smooth all that well.) Just wondering ''cause I''m working on some terrain/heightmap tools and want to know what formats are good ones, and what people use to edit them. Thanks, -Michael

I use an 8-bit heightmap, and then smooth it a couple of times when converted to floats. You can still have steep hills and all, a light smoothing only gets rid of the ugly blockiness, not your grand scale terrain.

An option which might be suitable would be to just stick to the large height range beign represented in your 256 grey image... then have a second 1-bit mask (to mask off bits you don''t want altered)... then move your 8-bit values into floats, and (using the mask) add some fractal noise, to give a smoother. Another point to consider, is if the heightmap has such a large height range within it.. how much flexibility do you have in terms of controlling the local gradient. Possibly working with a larger heightmap might be preferable. Another possibility, is to break the heightmap up into blocks... then for each block, you store a height offset. in this way, unless you needed a greater than 255 unit height gain accross a block... you could simply stick them all together. This would require a lot more control over the regions they join up at (unless you made the triangulation system, auto patch the discontinuity for you)... The option I would say is best, would be to switch paint packages to one supporting 16-bit grayscales (eg photoshop). This way, you keep the same degree of flexibility, and get the extra accuracy you need (plus for image editting, photoshop in my opinion is FAR superior to PSP though some functions seem a bit counterintuitive). Anyway, good luck.

Ah, thanks dmounty. I wasn''t aware photoshot supported 16bit grayscale (well, I think I''ve seen it, just never remembered.)

Sounds like the easiest solution right now. Later I hope to make an editor for the beasts so you can perform area erosion, add lakes + rivers, etc. to the heightmap.

Fractal noise - hadn''t thought of doing that, sounds like a good idea (only thing is... hmm, you''d still see the small slope offsets unless your fractal noise added (a range of) at least up to 2 steps worth to the final value.)

Thanks for the ideas, guys,
-Michael


Btw, how come it seems hardly anyone ever replies to my posts - do I format the question wrong, is it titled wrongly, or is it something about the question itself?

Here''s an idea, instead of making it greyscale make it colored. So you could have, say, 65536 with a 16 bit image. To boot, you''d have nice "bands" of colors every couple height units when the red and green components roll back to 0. When it comes to loading, just read the actual color at that position and instead of dissociating into RGB values, just read it as an integer value. Or float, if you want to do it that way...

The only problem I see with this is editing...

It should be pretty easy to use an image of any precision to generate a heightmap, just get the image depth and multiply each byte by it''s position and add to the vertex, ie:

for ( uint8 byte = 0; byte != data.depth; ++byte )	vertices[ vertex ] += static_cast< uint8* >( data.buffer )[ offset++ ] * pow( 256.0f, byte );

That way you can work with heightmaps of any depth and are completely flexible in how you handle the data. You''ll probably also want to scale that vertex appropriately.

Wow, the thread came back to life, nice.

Thanks for the link Coincoin, I''ll try to check it out.
RuneLancer (what are you doing here?! (ahem) I mean....) thanks, but like you said, unfortunately it''s kind of a pain to edit (you can just use 24 bit raws, and only tweak with the green and blue - red is just minute detail then.) I''ve done it, but it doesn''t lend itself well to editing.

I''m thinking I''ll just mainly load 2 formats - the hand edited (bmp or raw or whatever.) and the engine''s propriatary format, which will either have info about fractal detail (CGameProgrammer''s suggestion) along with the original (lower res) heightmap. Or might just store the actual float height values (full res.)
Internally, I''d like to just work with a set size heightmap (so I can easily calculate normals, shadows, etc.) so I might just go with the 2nd route, as it would be easier to shift from disk->memory then.

Thanks everyone,
(plug) Now go check out my thread on shadow calculations (/plug)

-Michael