Project Orbiter texture tree tools (OT3)

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,398
Reaction score
578
Points
153
Location
Vienna
I used a colour height map from the internet. The colours were probably completely wrong, but I wasn’t worried about that, as I could edit the .png as necessary.

That's the culprit. If you do not know what kind of color mapping the original source used, strange results are not uncommon.
The problem is this: how do you map a linear height value into the 3-dimensional color space? Usually, you walk the color-space cube along its edges, excluding the white and the black corner. Now even with this simple coding, there are multiple paths to walk along, so there is no single way to say "this is it".
There is also a second problem: bit depth. With 3 8-bit color values, you theoretically can encode 24-bit values. Orbiter's highest precision for height is 16 bit, currently. So in theory, you can encode the full precision in an 8-bit color PNG. However, the classical edge-walking color-mapping only encodes around 10 bits. So I've extended the classic color-mapping a bit by varying the "brightness" of each pixel to increase the bit-depth to 16 bits. This means you can create a sufficiently color-mapped 8-bit color PNG without losing precision, making round-trips (i.e. convert to PNG, then back to ELV again) possible.

The edge-walking that ele2png does is as follows: low=blue-magenta-red-yellow-green-cyan=high. If your source is not using the same encoding, you have to re-color it to match this mapping. In addition, chances are very high that your source does not do the same inter-spacing to increase bit depth, so you see the "ripples" when decoding it with it. The header value determining whether inter-spacing is used or not is "colormap". Setting this value to 1 instead of 2 will force ele2png to fall back to the 10-bit LUT, effectively eliminating the "ripples".

"ele2png" also tries to guess if the color value of a pixel is outside the valid mapping range (e.g. black or white pixels are usually absent in strict color maps). The guessing is done based on color "distance" to valid color map values. Besides the usual blue-to-cyan mapping, simple linear color maps are used as well, such as the gray-value mapping (i.e. all three colors of the same value like 55,55,55 or 120,120,120), or single-channel maps (e.g. only the red channel is encoding the height value). The maximum mapping error during conversion (i.e. the furthest distance a pixel had from a valid mapping color) will be displayed if the "-v" option is used 2 or more times (e.g. "-vv"). This gives a hint on how much guessing the program had to do to interpret the given picture.

That said, I'd suggest to get a grayscale 16-bit PNG as source instead. Less troubles.
 

4throck

Enthusiast !
Joined
Jun 19, 2008
Messages
3,502
Reaction score
1,008
Points
153
Location
Lisbon
Website
orbiterspaceport.blogspot.com
I'd try with a 16-bit grayscale PNG, with levels matching elevation in meters.
For testing purposes disregard negative altitudes, go with ranges from zero to your maximum height range (ex: 10000 for 10km).
Try that and see what happens.
 

Owenmck

Read the documentation!
Joined
Apr 18, 2020
Messages
125
Reaction score
117
Points
58
Location
Scotland
I still have no idea where I am going wrong. Every time, if I use type=8, ele2png outputs an elevation tile that is completely smooth with a few tiny bumps on it, even if I force the range to 0:10000 or the scale to 100.
If I use Type=-16, it just gives me a tile with the ridges.

I am taking a color png, then converting it to grayscale bu exporting as "16bpc GRAY" in GIMP. I thought that this might have been the problem, but I tried exporting as 16bpc RGB, and also creating a png that was purely gray and white, but I still got the same results.
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,398
Reaction score
578
Points
153
Location
Vienna
I still have no idea where I am going wrong. Every time, if I use type=8, ele2png outputs an elevation tile that is completely smooth with a few tiny bumps on it, even if I force the range to 0:10000 or the scale to 100.
If I use Type=-16, it just gives me a tile with the ridges.

I am taking a color png, then converting it to grayscale bu exporting as "16bpc GRAY" in GIMP. I thought that this might have been the problem, but I tried exporting as 16bpc RGB, and also creating a png that was purely gray and white, but I still got the same results.

Do you know what the color mapping is in your picture?
Did you try setting "colormap" in your header to 1 instead of 2?
Did you try the "-vv" option to get feedback on the conversion process? What's the max. error distance?
Can you post one of the PNGs you try to convert?
 

Owenmck

Read the documentation!
Joined
Apr 18, 2020
Messages
125
Reaction score
117
Points
58
Location
Scotland
Kerbin_Elev_NEW7.png
Here it is. As far as I understand, I just need to recolor this, but I can't find a good way to recolor it.
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,398
Reaction score
578
Points
153
Location
Vienna
Here it is. As far as I understand, I just need to recolor this, but I can't find a good way to recolor it.

That looks like low=blue(0,0,255)-cyan(0,255,255)-green(0,255,0)-yellow(255,255,0)-red(255,0,0)-magenta(255,0,255)=high vs. low=blue(0,0,255)-magenta(255,0,255)-red(255,0,0)-yellow(255,255,0)-green(0,255,0)-cyan(0,255,255)=high . If you swap the red and green channel, you should be fine.

Also, the picture you've posted has 512 pixels. This would create a non-standard elevation tile. You need to re-scale it to 259x259 pixels.
I have swapped the channels with GIMP and re-scaled it like so:
kerbin.swapped.png

That said, you still won't be happy with the results, because the color-mapping is not a strict one, as it seems. This means that there are various brightness variations in the colors that can't be mapped to linear height values easily. Converting the above tile and back again gives me this height-map:
kerbin.png

Again, I can only suggest to get a better height-map, preferably a grayscale 16-bit one.

You can find the pictures, meta-data and converted elevation tile in the ZIP attached.
 

Attachments

  • kerbin.zip
    282.4 KB · Views: 4

N_Molson

Addon Developer
Addon Developer
Donator
Joined
Mar 5, 2010
Messages
9,278
Reaction score
3,247
Points
203
Location
Toulouse
Olympus Mons is quite certainly the "highest" place in the Solar System... Do we know where's the "lowest" ? The Marianna's Trench on Earth is like -11km, which is not bad... Still +-25km should be an acceptable scale for heightmaps.
 

4throck

Enthusiast !
Joined
Jun 19, 2008
Messages
3,502
Reaction score
1,008
Points
153
Location
Lisbon
Website
orbiterspaceport.blogspot.com
But you consider absolute range in meters you have 0 to 50000 meters. A 16bit image has a range of 0 to 65535 levels.
If you map each meter to a grayscale level, it fits nicely...
 

Owenmck

Read the documentation!
Joined
Apr 18, 2020
Messages
125
Reaction score
117
Points
58
Location
Scotland
I've finally cracked it. I feel so stupid, I read that they were supposed to be 259x259 in the doc, but I still made them 512x512 smh...

Anyway, now the really hard thing is going to be finding a suitable kerbin heightmap.
Thanks for the help :hailprobe:
 

N_Molson

Addon Developer
Addon Developer
Donator
Joined
Mar 5, 2010
Messages
9,278
Reaction score
3,247
Points
203
Location
Toulouse
At this point it would be extremely useful if someone could make an up-to-date guide / tutorial for manipulating terrain elevation data and understanding the whole tree concept. Right now it is probably a bit out of reach for people that don't have an IQ of 150, and that's a pity. I also have the feeling that this complexity is one of the reasons that made O2016 'not-so-popular'. Command line ure works, but it will scare to hell 99% of the potential users, so a basic GUI with 'tick boxes' for different options would be invaluable. I am old enough to have lived in a time as, as a child, I had to write a couple of lines in BASIC to run games from floppy disks on my shiny Amstrad 6128+ CPC (still have it in a box and it still works !!). People in their 20ies nowadays might not even know what MS-DOS is/was. Please let's keep all this in mind.

I'd say the hard coding work is getting done and many thanks for that, but it needs a more convenient 'packaging' and maybe not foolproof but 'usable by an average human being' documentation.

And again many thanks for working on that, it is critical stuff, don't get me wrong.

On a side note, I saw that @jarmonik made some kind of editor for surface texture (and is planning to update it). Maybe there's something to do there like a joint endeavor?

Edit: lets take something like ShipEdit as an example. Martins could have made it command line, really. It would work as well. But the simple "2000s-Windows-style" GUI really makes it easy-to-use, and that's all what we really need. Of course, for manipulating things like textures, a visual "preview" might be interesting, and that's also where using D3D9 Client for "realtime view" could be ideal.
 
Last edited:

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,398
Reaction score
578
Points
153
Location
Vienna
At this point it would be extremely useful if someone could make an up-to-date guide / tutorial for manipulating terrain elevation data and understanding the whole tree concept.

Indeed. I am not that someone, though, as I often enough failed to convey concepts in a digestible manner. But I'd welcome everyone that creates a GUI for these features, perhaps just using the tools silently in the background. If this is then maintained and supported as well, it would be perfect for the community.
 

Owenmck

Read the documentation!
Joined
Apr 18, 2020
Messages
125
Reaction score
117
Points
58
Location
Scotland
Spent yesterday setting up GRASS GIS, and finding a GeoTiff that shows the elevation on kerbin. After importing to GRASS, and setting the colour table to GREY, I've managed to get this png. Is this suitable? (I have it in 16384x8192)Kerbin_Elevx.png
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,398
Reaction score
578
Points
153
Location
Vienna
Spent yesterday setting up GRASS GIS, and finding a GeoTiff that shows the elevation on kerbin. After importing to GRASS, and setting the colour table to GREY, I've managed to get this png. Is this suitable?

The posted picture is in 16-bit grayscale. I've put it through ele2png and back again (with "-g" for grayscale export), and it came back fine. So I'd say this is a much better start than the color maps before. Just keep in mind to slice it into 259x259 tiles with overlaps. Do you know how to do that?
 

Owenmck

Read the documentation!
Joined
Apr 18, 2020
Messages
125
Reaction score
117
Points
58
Location
Scotland
The posted picture is in 16-bit grayscale. I've put it through ele2png and back again (with "-g" for grayscale export), and it came back fine. So I'd say this is a much better start than the color maps before. Just keep in mind to slice it into 259x259 tiles with overlaps. Do you know how to do that?
Yep, that’s fine, I’ll get back to you if I have any problems. Thanks
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,434
Reaction score
688
Points
203
I'm having a bit of trouble with treeman. More specifically with the mask texture part. I'm trying to convert this Vandenberg AFB add-on to work with Orbiter 2016. But it doesn't convert the masked out coastal parts, I have attached a screenshot of this. Is this an error my part or is the add-on not compatible with the mask option of treeman? It produces a 0 byte, empty mask.txt when I run it.
 

Attachments

  • VAFB_non_converted_ocean_masks.jpg
    VAFB_non_converted_ocean_masks.jpg
    81.7 KB · Views: 11
Top