Hey, or how about this...

Usually the height map data all point "up". Why not have a height map where, instead of always assuming they are pointing up, you use a normal that can point into any direction.

Let''s say your terrain is divided into smaller grids (or patches) of sub-height maps. Each sub-grid has one additional normal. For most cases, the normal would point up, and you simply calculate the vertex position by multiplying the current height entry with the normal. This would give the same result as simply not having the normal, like in a regular height map.

Now, you can point the normal for any grid into any direction. It can point sideways, so that you can create an overhanging cliff, for instance, or even a cave.

Now if you do this, you will need to make sure the edges of the grids line up with the other grids. Maybe you can do this with specifying the 3D location of each of the four corners of the grid. This way you can even have an upside-down height map.

Imagine a large hill with overhanging cliffs, where many smaller patches are "wrapped" around the terrain. Each patch knows it''s four corners, which join up with other patches around it. Some patches are sideways, with normals pointing to the side, while others are even upside-down, with normals pointing down.

Maybe you can have grids of varying size, and with a flag to turn off the calculation with the direction normal. This way, you can have large patches for open areas that do not use overhanging cliffs, and therefore do not waste time on the additional calculation. So this would result in about the same performance as any other algorithm. But some patches will have the flag turned on, in which case the additional normal is also taken into consideration to rotate the patch.

You get the idea...

But how does one create such a height map? Bitmaps with height data would not work too well. Maybe in the level editor you can "stretch" the patches into new orientations?

Or use some form of simple model editor where each rectangular polygon represents one patch. Scale the model up to your terrain size and overlay this then with the regular bitmap that stores the usual height detail, and use each rectangular polygon for the four corners of the patch (auto-create the patches). The normal of each polygon becomes the normal stored in each patch. This implies the points in the patches are not equally spaced, but that’s easy to deal with (you have the four corners).

Hmm, I can go on... I''m going to update my height map now...

SS

not exactley a robust solution (sticking to using image editors to create terrain)

but you could use primitives to cut holes into the terrain, or make slices, or whatever you want... subtracting and permanently changing that part of the terrain...

you''d have a heightmap, that filled up all spaced that will ever need to be filled, then define primitives that will go in and cut out parts, slice parts, cut, dig, or hollow, whatever you want, and its up to you to decide how to save that data

then just write your routines to load the heightmap as regular, make all the cuts saved, then render

you wouldnt be able to use the easly-to-code brute force method of rendering anymore though, and that would suck (in my opinion)

im currently looking at defining additive heightmaps, which just hook onto the heightmap that you already have, which define caves and mountains and things that your regular heightmap wont let you do (without tons of technology involved)..

im also thinking of this concept i came up with called "natural land geometry generation"... its based off of heightmaps, except it uses colors, and allows you to define over hanging cliffs, caves or caverns, and other types of geometry, defined in regular 2 dimensional images along with an xml file which clarifies how to draw the colors in real time.. ill get back to you when i get it done, cuz its probably going to be a long time, lol

just a thought, don''t normal maps store the normal data in colors? So why couldn''t you do the same?

so you have a RGBA (or ARGB) image.
Use the alpha for the height and each of the R,G and B for it''s own dimension. like XYZ. there you go, you can store the normal that way.

Though I have no idea how to make a good lanscape out of those, just wanted to point out that the image part isn''t your problem.