I posted this in MED-SED area but got no answers.
MED Terrain Import: Explain R*1 + G*1 + B*2

In MED the formula is said to calculate z-position.

I did a simple test by in MED importing a black 1024x1024 height map with one
white dot in it with following results when importing the produced .hm file into WED.
----------------------------
R*0 + G*0 + B*10 - terrain pos at z = 0, size 1024x1024x512
R*0 + G*10 + B*0 - terrain pos at z = 0, size 1024x1024x512
R*10 + G*0 + B*0 - terrain pos at z = 0, size 1024x1024x512
R*10 + G*10 + B*10 - terrain pos at z = 0, size 1024x1024x512

So apparently the formula does nothing for grayscale height maps
or have I totally missed the whole idea of how this works?

AFAIK the formula is for color images only, and gives the weight of the 3 color components.

Ok. That explains why my RGB manipulations had no effect
when importing grayscale heigthmaps.

But is it really correct to ignore the forumula completely
for grayscale images. As I see it this formula is the only
way to scale the import to a correct heigth when importing,
or is there any other way to do that?.

Here is an example:

Lets say we have designed a grayscale heightmap 1024x1024
with a max heigth (RGB=255,255,255) of 50 meters.

When I import this into MED i will get a terrain with the
dimension 1024x1024 quants and a heigth of 512 quants.

This means that I now have a terrain of 1024x1024 with
a height of 512 meters instead of the desired 50 (assuming
1 meter = 1 quant )

This would be easly solved by having the RGB formula active
for grayscale heigthmaps also. Lets say the formula would
scale the imported heigth by the R-factor. In this case we
would import with 'z-position' = R*(50/1024) + G*0 + B*0.

Then the imported terrain would become
1024x1024 quants but with a height of 50 quants
( same number of faces though)

Well .. this was just a thought.
Anyhow I now understand that the RGB formula has
no effect for grayscale images as those from Terragen and L3DT.

Thank's
~Roland

It depends on the number of vertices. One pixel of 1024 ^2 bitmap using 200 vertices, most likely won't average in...


...use a bigger dot

Ok. Here what I'm trying to do

In L3DT I create a terrain 1024x1024 meters, with some hills and and valleys.

The highest point in the terrain is a hill with the height of 50 meters. That point
will then get the brightest rgb-value (white 255,255,255). The lowest point is
at 0 (black 0,0,0).

I export the produced heightmap as a grayscale bmp-file (1024x1024)

Then in MED I import the bmp-file as terrain. (using default values).
I save this as a hmp file and loads it into WED.

In WED i now has a terrain 1024x1024 with heigt 512.
I know I should perhaps have increased the number of vertices in MED import
to get better resolution, but that is not important for now.

The problem is the relationship between the area and the height. The highest
that was 50 meter in L3DT is 512 here.

A solution would be to scale the terrainblock down in Z, but in WED I only have
found globally scaling so doing that would just scale the whole terrain and thats
not what I want.

So scaling of Z has to be done in MED. This can be done by using arrow down
in scale mode. A problem with this is that I have not found any way to scale by
giving a value (50/1024=0.0488..). Scaling to such a value by using down arrow
is almost hopeless.

That was my though by suggesting to use the R-component in the import formula
as a Z-scaling factor. Then I would get it right directly in import.

Hope that this explains what I'm trying to do.
My English is not to good so its can be hard to explain

Kindly
~Roland

I'll check what the height formula really does - this is not fully documented. I believe it can also be used to convert greyscale images to a certain height, but it's a different formula then. The MED developer, Wladimir, is not in the office this week and I'll be away next week, so I have to ask for patience, but after my return I'll post a solution here.

it comes in handy to import color-coded heightmaps (such as my terrain generator): r*1 + g*256 + b*65536