Gadget Request: Heightmap via Bitmap

[Argh]

OK folks. I'd like some help, if anybody's willing.

Here's what's up:

That's "stage one"- for the next stage, I'd really like some help.

Basically, what I'd like to do is to build a mesh of hills, and use the same grayscale that was used to generate the hills to generate the heightmap result. This, along with some engine changes I've requested, should make it possible to do the full gamut here- floating-world stuff, cliffs with overhangs that are actually functional, giant buildings that are things Units can drive over freely (if there's a ramp, dropped by a transport, etc.) that aren't constrained by resolution/projection issues and can use a full shader treatment, etc.

I was thinking that I could use OpenGL to read the pixel values of the grayscale, and then use some sort of scaling function, rotating it by reading the pixels in a different row-order, and translate that into height. It would be slow, but there just isn't any way to avoid that, and it'd be occurring during GameStart().

This means that we could use a very similar process to the SME "prefab" approach to build 3D geometry that was a close match for the resulting heightmaps, and drawing stuff like a ramp would result in a ramp of height- an essential requirement if we're going to connect sky-cities to ground on a regular basis.

I need an algorithm that will:

1. Validate all Units and determine what uses a height mesh.
2. Get the height-texture via customParam.
3. Performs the terrain manipulation by reading the bitmaps, based on the rotation of the object (i.e., if facing == 0, read bitmap from x1,y1 to x2,y2, if 1, then y1,x1, y2,x2, etc. This is pretty minor OpenGL. It should use a base height, with all values higher than that being raised- right now, 400 is the height I'm using. Later on, it may make more sense to do a height survey across the area and do an average, for more flex, but for now it's just fiat.

IOW, I pretty much know what it needs to do here, but I'm really short on time. I didn't think this tech would arrive in time, and didn't really plan for it, tbh. If nobody is interested, it's cool, I may get to it after I release 1.3. Any takers?

[lurker]

1. Don't use the term smoothMesh when what you want won't be 'smooth' at all.
2. Camera using smoothMesh makes sense, good idea if nobody has already done it.
3. Why use opengl to add a couple bitmaps together?
4. You want an algorithm? For what? I don't see what you need that has any complexity. Is this it or? Seriously what do you want that takes ANY thought?
for i=1,mapx do map={} for j=1,mapz do map[j]=400 end end
for node in flahlist do
local tex=ltex(UnitDefNames[node.u].customParams.foo)
--I'm not writing out this couple lines of if
for UnitDefNames[node.u].customParams.foox
for UnitDefNames[node.u].customParams.fooz
map[j] = map[j] + tex[m][n]
end
end
end
loadtex(name)
io .open, .read name
for i, size {} for j, size
read byte * 256 + read byte
end

[imbaczek]

2. Camera using smoothMesh makes sense, good idea if nobody has already done it.

i plan to expose smooth mesh to lua.

BTW, i was inspired by DOW2's camera mesh when implementing smooth mesh, so the idea is already working elsewhere, albeit a little bit differently (smooth mesh is calculated on map compilation time there, and it looks nicer).