Project Orbiter texture tree tools (OT3)

[Face]

Nevertheless, it seems to me that there still is two problems remaining with the Martin's explanations and formulas in the PlanetTextures.pdf. A question of off-by-one conversion also on latitude. And a question of levels.

I changed the picture of my post number #29 page 2 to explain what i mean ( with the Edit2 and 3 ).

http://www.orbiter-forum.com/showthread.php?p=543323&postcount=29

I'd say you report this to martins, so he can take a look and perhaps adjust the documentation for the patch release.

 

[fort]

I'd say you report this to martins, so he can take a look and perhaps adjust the documentation for the patch release.

I'll try to post tomorrow the detailled result of my complete test on the VAB and Woomera at level 16 ( with attachement: base config, respective dds etc ).

 

[igel]

I've used new treeman to once again convert Baikonur Surf tiles to 2016 (first had to re-uncomress a fresh tree to clean out the traces of the past exercise). This time, a charm! All new tiles are in proper places, no any longitude shift. So, now I even have two sets of new tiles - one from treeman, downsampled one level, and another from my "cut and splice" script in the next level. All in proper places!

---------- Post added at 07:39 PM ---------- Previous post was at 03:58 PM ----------

I can probably try another worflow, with elv2png:

1. Convert /13/000125/000692.elv to /13/000125/000692.png, 259x259x32bit;
2. Split/splice png into quaters, expanding each resulting quater up 259x259, producing png tiles for Level 14;
3. Repeat step 2, either recursively or in a cycle over original tile, all the way down to level 17;

Combination of 2-3 gives a total of 256 png files in all levels. Such amount can only be obtained by some tool or by scripting (with command line ImageMagic tool).

Alternative way may ge to try to generate just one particular Level 19 tile that I will beed to update. Still, only practical way is a script, to will calculate which particular pixels to take from the original tile A-B-C for a downstream tile D-E-F.

4. (Optional?) As the resulting lower-level tile will be too "pixelized", and if it turns out to be a problem in elevations, some graphic filter may be applied to smoothen the gradations of extrapolated pixels.

5. Select only png tile(s) that are needed for custom modification (e.g. launchpad site, or railway grades, or built-up area flattening).

6. Convert selected png tiles to "*.elv" file(s) with elv2png and place it in \17\2006 folder of the Elev (not Evel_mod!) folder.

7. Finally, tweak local elevations in tileedit.

 

[Face]

I've used new treeman to once again convert Baikonur Surf tiles to 2016 (first had to re-uncomress a fresh tree to clean out the traces of the past exercise). This time, a charm! All new tiles are in proper places, no any longitude shift. So, now I even have two sets of new tiles - one from treeman, downsampled one level, and another from my "cut and splice" script in the next level. All in proper places!

Thanks for the test. :thumbup: Looks like the CSSC tiles where off in the end, Loru already suspected that much.

I can probably try another worflow, with elv2png:

1. Convert /13/000125/000692.elv to /13/000125/000692.png, 259x259x32bit;
2. Split/splice png into quaters, expanding each resulting quater up 259x259, producing png tiles for Level 14;
3. Repeat step 2, either recursively or in a cycle over original tile, all the way down to level 17;

Combination of 2-3 gives a total of 256 png files in all levels. Such amount can only be obtained by some tool or by scripting (with command line ImageMagic tool).

Alternative way may ge to try to generate just one particular Level 19 tile that I will beed to update. Still, only practical way is a script, to will calculate which particular pixels to take from the original tile A-B-C for a downstream tile D-E-F.

4. (Optional?) As the resulting lower-level tile will be too "pixelized", and if it turns out to be a problem in elevations, some graphic filter may be applied to smoothen the gradations of extrapolated pixels.

5. Select only png tile(s) that are needed for custom modification (e.g. launchpad site, or railway grades, or built-up area flattening).

6. Convert selected png tiles to "*.elv" file(s) with elv2png and place it in \17\2006 folder of the Elev (not Evel_mod!) folder.

7. Finally, tweak local elevations in tileedit.

As treeman already has an option to integrate tiles into lower-res tiles, and internally has the feature to scale tiles up to non-existing higher resolutions, I can imagine building that whole workflow above into it, using ele2png just the same way as texconv was used. That way the integration and extrapolation will also support Elev and Elev_mod layer.

 

[Loru]

Thanks for the test. :thumbup: Looks like the CSSC tiles where off in the end, Loru already suspected that much.

I was sure of that. Since 2010 CSSC edition was using single 4096x4096 surface tile I hade to move it one 512 tile west to fit entire island on single 16megapixel tile.

 

[fort]

Hello,

I chose to experiment at level 16 which corresponds to 'tiles for bases' at level 4 (Earth_4 _...) containing here unicolor images (green 256x256 pixels) and by the fact with own material and standard values.

The Orbiter 2016 tiles (in Earth / surf), assumed at similar position on the map, are in red.

At level 16: 8192 tiles (4096 x 2) from east to west and 4096 (2048 x 2) from north to south.

North west: the VAB locally. tile 002260.dds / 1397 folder.
South east: Woomera locally. tile 007209.dds / 2756 folder.

Be carefull: as my explanations starts - inconveniently i know - from the 2016 tiles values, one have at the end to reverse the conclusion and adjust the red tiles on the green and not the opposite ( see annotations in bold ) for the demonstration but the conclusions are nevertheless valid i think.

In longitude, if i only consider to calculate the values of x and the number of tiles to the level (2 ^ 4 + 8), a base tile to cover the VAB could be set to:
4096 - 2260 (Nx) = 1836 (Earth_4_w1836 ...).Canaveral.cfg.
For w1836 the tile in longitude corresponds visually to the VAB 4096> (2 ^ m + 8) - 1836> (x) is correct ( pdf is correct ).



In longitude, the tile for Woomera could be set to:
7209 (Nx) - 4096 = 3113 (Earth_4_e3113 ...).Woomera.cfg.
For e3113 the tile in longitude corresponds visually to Woomera 4096> (2 ^ m + 8) + 3113> (x) is correct ( personal formula is correct ).



It's different in latitude yet the reasoning should be identical. Paper and pencil and research in the surftilecalculator bring answers.

In latitude the tile to cover the VAB could be set to:
2048 - 1397 (Ny) = 651 (Earth_4_e ...._ n0651)
For _n0651 the tile is located just above (north) the VAB. 2048 (2 ^ m + 7) - 651 seems insufficient.


If i want that the red tile cover my green tile:

Ny> 2 ^ m + 7 -1 - 651 is right ( pdf is correct ).

That of Woomera could be set to:
2756 (Ny) - 2048 = 708 (Earth_4_e ...._ s0708)
For _s0708 the tile is still just above (north) from that of Woomera. 2048 (2 ^ m + 7) + 708 seems insufficient.

If i want that the red tile cover my green tile:

i should also remove 1.
Ny> 2 ^ m + 7-1 + y is good ( personal formula is right ).

It will be interesting to see if i made errors or not. I can't test actually treeman.

Don't open the zip directly in orbiter 2016. It is not exactly made for that.

 

[Ripley]

...I can't test actually treeman...

Eh eh, oldish 32bit Operating System in use?

 

[fort]

Eh eh, oldish 32bit Operating System in use?

Eh non

Or plus or less.

By the fact - it's not exactly the same theme - but now that the D3D9 seems match orbiter 2016, i was looking for a XP 32 version. Did you see something about that ?

No, i wanted to understand and use tileedit ( and now treeman), and as tileedit is a 64 bits prog, i spend a part of my holidays to find a 64 bit version of win 7 and put it on another hdd, with the dual boot wich looks well. But my principal activity stays on my XP 32 and as many old mens ( and not only ), i have my habits ( Alzheimer ? )

But for the moment, switch to the second hard drive and learn and load treeman, when i'm on nightlights nights an days...

good day Ripley

( je suis une communauté en déclin )

 

[jacquesmomo]

No, i wanted to understand and use tileedit

Now, I know how to use tileedit !!! :tiphat: I am happy !!!

 

[Face]

Progress: ele2png can now convert PNGs to ELV.

Round-trip is possible by means of PNG meta-data support. I simply serialized info into the "Comment" string and read it back again. If no meaningful data is in there, it simply assumes a 1x1 padded 16-bit elevation data with full 16-bit range. Conversion will then take a bit longer, as it needs to guess the off-colors into the OT3-colormap range.

This way you can even import non-OT3-colormapped images. I've imprinted my avatar into the vicinity of Ascension Island for the lulz:

=> \Textures\Earth\Elev\10\000034\000058.elv

Result is this rendering:

So with this you can convert a tile to PNG, edit it (e.g. flatten some area), then convert it back to ELV.

 

[igel]

This is so-o spooky, jut in time for Halloween!

 

[Loru]

We had face on mars. Now we have Face's face on the ocean.

 

[4throck]

Looks like the Shroud of Turin :hmm:

Good news on the PNG import.
In theory makes it possible to import data from grayscale images, converted to the right palette. I've see such data for some places on Titan for example...

 

[Face]

In theory makes it possible to import data from grayscale images, converted to the right palette. I've see such data for some places on Titan for example...

You don't need to convert it to OT3 colormap, because the guesser also takes grayscale mapping into account. Take any grayscale image, convert it to RGBA8 PNG, then use ele2png. It will take the 8-bit grayscale value and spread it from -32768 to 32767 linearly. You will lose precision that way, though.

With a round-trip, you can also re-scale the image: convert ELV to PNG, edit the comment string to change emin and emax, then convert it back again. GIMP can do that under Image->Image Properties->"Comment" tab.

I will certainly implement an option to use pure 16-bit grayscale PNGs, but since many editors don't support that format, I went with the common format (RGBA8) first. Fortunately, the 16-bit grayscale PNG export/import is more straightforward than the complicated color-mapping.

 

[fort]

Hello,

In spite of the good report of Igel and Loru (?), conversions made by treeman ( 03-09-2016 20h40 ) in terms of coordinates vis à vis of Orbiter 2016 are false.

 

[Face]

In spite of the good report of Igel and Loru (?), conversions made by treeman ( 03-09-2016 20h40 ) in terms of coordinates vis à vis of Orbiter 2016 are false.

Well, AFAIK Igel made a report for the version posted here: http://orbiter-forum.com/showthread.php?p=543594&postcount=33

That post has a timestamp of 01-10-16, 20:56, not 03-09-2016 20h40. Seems like you've tested the wrong version.

 

[igel]

Confirming: My last test (success) was done with version from post http://orbiter-forum.com/showthread.php?p=543594&postcount=33. treeman.exe, size 215,552 bytes.

 

[Face]

Progress: ele2png can now create and round-trip 16-bit grayscale format by means of using option "-g" when generating the PNG.

In addition (and in contrast to previous versions), ele2png will now create (and populate) an alpha channel only if Elev-mod layer is used. The following formats are created/supported in the appropriate direction:

  ELV Mode   | -g| Output format
-------------+---+------------------------------------------------------------------------
    Elev -16 | - | 8-bit RGB no alpha colormapped with 16-bit HSV Hue/Value Blue to Cyan
    Elev -16 | X | 16-bit Grayscale no alpha
    Elev  8  | - | 8-bit RGB no alpha colormapped with 10-bit HSV Hue Blue to Cyan
    Elev  8  | X | 16-bit Grayscale no alpha
Elev_mod -16 | - | 8-bit RGB with alpha colormapped with 16-bit HSV Hue/Value Blue to Cyan
Elev_mod -16 | X | 16-bit Grayscale with alpha
Elev_mod  8  | - | 8-bit RGB with alpha colormapped with 10-bit HSV Hue Blue to Cyan
Elev_mod  8  | X | 16-bit Grayscale with alpha

Input mode | Alpha | Depth | Output ELV mode | Comment
-----------+-------+-------+-----------------+---------------------------------------------------------------------------------------
    Color  |  no   |   8   |     Elev -16    | Guessed on 16-bit colormap, roundtrip possible
    Color  |  no   |   16  |     Elev -16    | Color-intensity used as 16-bit value
    Color  |  no   |   8   |  Elev_mod -16   | Guessed on 16-bit colormap, maximum value is transparency
    Color  |  no   |   16  |  Elev_mod -16   | Color-intensity used as 16-bit value, maximum value is transparency
    Color  |  no   |   8   |      Elev 8     | Guessed on 10-bit colormap, roundtrip possible
    Color  |  no   |   16  |      Elev 8     | Color-intensity used as 16-bit value, precision is lost
    Color  |  no   |   8   |   Elev_mod 8    | Guessed on 10-bit colormap, maximum value is transparency
    Color  |  no   |   16  |   Elev_mod 8    | Color-intensity used as 16-bit value, maximum value is transparency, precision is lost
    Color  |  yes  |   8   |     Elev -16    | Guessed on 16-bit colormap, alpha info is lost
    Color  |  yes  |   16  |     Elev -16    | Color-intensity used as 16-bit value, alpha info is lost
    Color  |  yes  |   8   |  Elev_mod -16   | Guessed on 16-bit colormap, roundtrip possible
    Color  |  yes  |   16  |  Elev_mod -16   | Color-intensity used as 16-bit value
    Color  |  yes  |   8   |      Elev 8     | Guessed on 10-bit colormap, alpha info is lost
    Color  |  yes  |   16  |      Elev 8     | Color-intensity used as 16-bit value, alpha info and precision is lost
    Color  |  yes  |   8   |   Elev_mod 8    | Guessed on 10-bit colormap, roundtrip possible
    Color  |  yes  |   16  |   Elev_mod 8    | Color-intensity used as 16-bit value, precision is lost
 Grayscale |  no   |   8   |     Elev -16    | Scaled to 16-bit
 Grayscale |  no   |   16  |     Elev -16    | Roundtrip possible
 Grayscale |  no   |   8   |  Elev_mod -16   | Scaled to 16-bit, maximum value is transparency
 Grayscale |  no   |   16  |  Elev_mod -16   | Maximum value is transparency
 Grayscale |  no   |   8   |      Elev 8     | 
 Grayscale |  no   |   16  |      Elev 8     | Roundtrip possible, precision is lost
 Grayscale |  no   |   8   |   Elev_mod 8    | Maximum value is transparency
 Grayscale |  no   |   16  |   Elev_mod 8    | Maximum value is transparency, precision is lost
 Grayscale |  yes  |   8   |     Elev -16    | Scaled to 16-bit, alpha info is lost
 Grayscale |  yes  |   16  |     Elev -16    | Alpha info is lost
 Grayscale |  yes  |   8   |  Elev_mod -16   | Scaled to 16-bit
 Grayscale |  yes  |   16  |  Elev_mod -16   | Roundtrip possible
 Grayscale |  yes  |   8   |      Elev 8     | Alpha info is lost
 Grayscale |  yes  |   16  |      Elev 8     | Alpha info and precision is lost
 Grayscale |  yes  |   8   |   Elev_mod 8    | 
 Grayscale |  yes  |   16  |   Elev_mod 8    | Roundtrip possible, precision is lost

PNG with color palettes are not supported.

 

[Face]

Progress: OT3's ele2png now produces binary identical roundtrips, supports 4/2/1-bit PNGs, too, and prompts on file overwrites (just as treeman does).

In addition, I've added a range option in order to manually set the range the values should be in. This way, you can convert multiple tiles to the same range, so you can stitch them together in editors.

Example: I've wondered how the Elev_mod data actually overlays the Elev data in the KSC area. So I've convert the Elev and Elev_mod data of /16/001396/002259-002262 with the same range, stitched it together in GIMP, then laid Elev_mod over the Elev strip, then blended it in and out like so:

Here is also one of those 16-bit grayscale PNGs (central Europe with alps):

Updated conversion table:

  ELV Mode   | -g| Output format
-------------+---+------------------------------------------------------------------------
    Elev -16 | - | 8-bit RGB no alpha colormapped with 16-bit HSV Hue/Value Blue to Cyan
    Elev -16 | X | 16-bit Grayscale no alpha
    Elev  8  | - | 8-bit RGB no alpha colormapped with 10-bit HSV Hue Blue to Cyan
    Elev  8  | X | 16-bit Grayscale no alpha
Elev_mod -16 | - | 8-bit RGB with alpha colormapped with 16-bit HSV Hue/Value Blue to Cyan
Elev_mod -16 | X | 16-bit Grayscale with alpha
Elev_mod  8  | - | 8-bit RGB with alpha colormapped with 10-bit HSV Hue Blue to Cyan
Elev_mod  8  | X | 16-bit Grayscale with alpha

Input mode | Alpha | Depth | Output ELV mode | Comment
-----------+-------+-------+-----------------+---------------------------------------------------------------------------------------
    Color  |  no   |   8   |     Elev -16    | Guessed on 16-bit colormap, roundtrip possible
    Color  |  no   |   16  |     Elev -16    | Color-intensity used as 16-bit value
    Color  |  no   |   8   |  Elev_mod -16   | Guessed on 16-bit colormap, maximum value is transparency
    Color  |  no   |   16  |  Elev_mod -16   | Color-intensity used as 16-bit value, maximum value is transparency
    Color  |  no   |   8   |      Elev 8     | Guessed on 10-bit colormap, roundtrip possible
    Color  |  no   |   16  |      Elev 8     | Color-intensity used as 16-bit value, precision is lost
    Color  |  no   |   8   |   Elev_mod 8    | Guessed on 10-bit colormap, maximum value is transparency
    Color  |  no   |   16  |   Elev_mod 8    | Color-intensity used as 16-bit value, maximum value is transparency, precision is lost
    Color  |  yes  |   8   |     Elev -16    | Guessed on 16-bit colormap, alpha info is lost
    Color  |  yes  |   16  |     Elev -16    | Color-intensity used as 16-bit value, alpha info is lost
    Color  |  yes  |   8   |  Elev_mod -16   | Guessed on 16-bit colormap, roundtrip possible
    Color  |  yes  |   16  |  Elev_mod -16   | Color-intensity used as 16-bit value
    Color  |  yes  |   8   |      Elev 8     | Guessed on 10-bit colormap, alpha info is lost
    Color  |  yes  |   16  |      Elev 8     | Color-intensity used as 16-bit value, alpha info and precision is lost
    Color  |  yes  |   8   |   Elev_mod 8    | Guessed on 10-bit colormap, roundtrip possible
    Color  |  yes  |   16  |   Elev_mod 8    | Color-intensity used as 16-bit value, precision is lost
 Grayscale |  no   |   1   |     Elev -16    | Scaled to 16-bit
 Grayscale |  no   |   2   |     Elev -16    | Scaled to 16-bit
 Grayscale |  no   |   4   |     Elev -16    | Scaled to 16-bit
 Grayscale |  no   |   8   |     Elev -16    | Scaled to 16-bit
 Grayscale |  no   |   16  |     Elev -16    | Roundtrip possible
 Grayscale |  no   |   1   |  Elev_mod -16   | Scaled to 16-bit, maximum value is transparency
 Grayscale |  no   |   2   |  Elev_mod -16   | Scaled to 16-bit, maximum value is transparency
 Grayscale |  no   |   4   |  Elev_mod -16   | Scaled to 16-bit, maximum value is transparency
 Grayscale |  no   |   8   |  Elev_mod -16   | Scaled to 16-bit, maximum value is transparency
 Grayscale |  no   |   16  |  Elev_mod -16   | Maximum value is transparency
 Grayscale |  no   |   1   |      Elev 8     | Scaled to 8-bit
 Grayscale |  no   |   2   |      Elev 8     | Scaled to 8-bit
 Grayscale |  no   |   4   |      Elev 8     | Scaled to 8-bit
 Grayscale |  no   |   8   |      Elev 8     | 
 Grayscale |  no   |   16  |      Elev 8     | Roundtrip possible, precision is lost
 Grayscale |  no   |   1   |   Elev_mod 8    | Scaled to 8-bit, maximum value is transparency
 Grayscale |  no   |   2   |   Elev_mod 8    | Scaled to 8-bit, maximum value is transparency
 Grayscale |  no   |   4   |   Elev_mod 8    | Scaled to 8-bit, maximum value is transparency
 Grayscale |  no   |   8   |   Elev_mod 8    | Maximum value is transparency
 Grayscale |  no   |   16  |   Elev_mod 8    | Maximum value is transparency, precision is lost
 Grayscale |  yes  |   8   |     Elev -16    | Scaled to 16-bit, alpha info is lost
 Grayscale |  yes  |   16  |     Elev -16    | Alpha info is lost
 Grayscale |  yes  |   8   |  Elev_mod -16   | Scaled to 16-bit
 Grayscale |  yes  |   16  |  Elev_mod -16   | Roundtrip possible
 Grayscale |  yes  |   8   |      Elev 8     | Alpha info is lost
 Grayscale |  yes  |   16  |      Elev 8     | Alpha info and precision is lost
 Grayscale |  yes  |   8   |   Elev_mod 8    | 
 Grayscale |  yes  |   16  |   Elev_mod 8    | Roundtrip possible, precision is lost

 

[NukeET]

Thanks for posting this fort.

I thought I was losing my mind when the documentation and treeman were giving two different latitude index results for the converted file, old surface tile to new.