Project Orbiter texture tree tools (OT3)

[Face]

If one day you can made treeman to work with a texconv 32 bits...or find a texconv 32 bits working with treeman....

I'm currently trying to compile the sources for XP. It seems like texconv.exe really IS 32-bit, but doesn't run on XP. I think there is a DirectX problem, not an architecture problem.

 

[fort]

Not only i am in 32-bit but in addition I use XP. Decidedly I accumulate a lot of troubles and maybe even all vices .:rofl:

 

[Face]

Not only i am in 32-bit but in addition I use XP. Decidedly I accumulate a lot of troubles and maybe even all vices .:rofl:

No worries. I've found a working version for both 64- and 32-bit XP. I'll check if treeman is compatible with that and put it up as alternative downloads.

 

[fort]

I'll try to see this evening with the 64 bits.

In the meantime, the representation i had to realize that sort of work manually, and maybe what OT3 do. I don't want to say: exactly, but something on that model if i understand your explanations, well. This on three level. For more i have'n't take the time to conceptualize it ( Does that could contest that first approach ? I dont think so but... ).


This schema is, yes, very ugly and so vertical

To make it complete, also add a blue arrow line from level 16 to the green level 14 tile...

Done

 

[Face]

This schema is, yes, very ugly and so vertical

Looks good. One thing is missing, though. To make it complete, also add a blue arrow line from level 16 to the green level 14 tile, as this is what happens in treeman. It does not take the resulting level 15 and integrates it back into 14, but just 16 into 15, then 16 into 14, and so on. This is to minimize cascading shrink artifacts.

 

[igel]

Hi Face!

Thanks for a great tool, and looking forward for more to come

I just tried treeman on the same Baikonur's tiles that I converted before with my Powershell script and ImageMagic. A small heads-up for you: I found a problem with Marin's formula for Longitude conversion for Eastern Hemisphere, and in my test verified that you use the same formula, Ex → 2^(m+8) + 1 + x. Here, +1 is wrong, not needed, as resulting tiles get shifted right by 1 tile.

In my script, until I fixed the formula, they were shifted by 2 - I did not downsample the 1024x1024 tile to a single 512x512 tile, but rather split it into 4 tiles of lower level, so lat-lon indexes had to be multiplied by two and then adjusted for four three new adjacent tiles out of four.

 

[Face]

I just tried treeman on the same Baikonur's tiles that I converted before with my Powershell script and ImageMagic. A small heads-up for you: I found a problem with Marin's formula for Longitude conversion for Eastern Hemisphere, and in my test verified that you use the same formula, Ex → 2^(m+8) + 1 + x. Here, +1 is wrong, not needed, as resulting tiles get shifted right by 1 tile.

In my script, until I fixed the formula, they were shifted by 2 - I did not downsample the 1024x1024 tile to a single 512x512 tile, but rather split it into 4 tiles of lower level, so lat-lon indexes had to be multiplied by two and then adjusted for four three new adjacent tiles out of four.

Well, that's strange. I (thought I) knew that already from experiments with Loru's CSSC, and also removed the +1 in the code. If you now say that it is still off by one, I've either uploaded the wrong version here, or one of the coordinates is wrong. Would be interesting to hear what Martin has to say about your bug report.

 

[igel]

I downloaded the version posted in the very first post of this thread. Hm-m... If it is the right version... maybe it should be -1 instead of +1? i.e. shift by two, not one?

My formula in Powershell (corrected after a few experiments) was
$newLon = ([math]::pow(2,$oldLevel+8) + 1 + $oldLon) * 2 - 2[/math]

 

[fort]

error

 

[Face]

Little progress: I've worked on the elevation part and made a first cut of the ele2png converter: http://snoopie.at/face/pics/ele2png.exe

It has a similar interface to treeman, meaning that it takes the texture root as first argument, followed by the layer name (of course only Elev and Elev_mod is supported here), followed by additional options and arguments. One of these last arguments should be the name of the tile to be converted, e.g.:

ele2png ..\Textures\Earth Elev /08/000003/000016.elv -vv

If the tile is present in the cache (i.e. already extracted from the tree archive), this example will spit out a PNG on the same path with the same name, but extension *.png . As of now it is a pseudocolored R8G8B8A8 PNG of the elevation data.

The appropriate Surf tile shows this:

The corresponding Elev tile is this:

With GIMP, you can merge those together to get a neat overlay like so:

Next step is the round-trip, so edited PNG can be converted back to elevation data again.

 

[igel]

So cool, thanks!

My task (as described in other thread) will be to take an elevation tile at level 13 and use it to generate selected approximated hi-res elevation sub-tiles in, say, level 17. Working with png in graphic editor seems perfect for that. Then I will need this yet-to-be-done round-trip feature

 

[fort]

error

 

[Face]

I have compiled a new set of OT3 here: http://snoopie.at/face/beta/ot3.zip .

It contains new builds of treeman and ele2png, with 2 changes:

• treeman now converts with adjusted longitude calculation. It would be helpful if folks involved in the off-by-one conversion error debugging can test if it now matches the expected results.
• ele2png now uses a different pseudo-color conversion, details below.

The new pseudo-color conversion uses a different LUT (Lookup table) than before, because the previous one only had a 10-bit precision. I still use this 10-bit precision HSV-Hue LUT for 8-bit elevation tiles, as it produces no collisions that way.
On 16-bit elevation tiles, the new 16-bit precision HSV-Hue/Intensity LUT is used, producing a better distinguishable pseudo-coloring for highly detailed tiles.


First is 10-bit, last is 16-bit:

Note the "noise" in the low-level land parts. This is because the new coloring does a small variation in the intensity of the values that are close to each other.

The current ele2png reverse procedure (i.e. if you give it a *.png file instead of a *.elv file) doesn't actually convert the PNG back to ELV, but instead creates an ELV that contains a table with all possible 16-bit values. In addition, it also checks it for collisions (i.e. if 2 16-bit values by accident produce the same RGB value). With the LUT in place, the collisions are zero, meaning that every 16-bit value has an exact RGB value in the following spectrum (never mind the upper blue part, that's because 259x259 is bigger than 256x256):

FYI, this is the conversion of the highest resolution level (10) of the stock Ascension Island elevation:

Also note that PNGs created by ele2png now contain a comment with the metadata of the conversion, such as min/max values, scaling and offset data as well as type and padding information. This makes it possible on round-trips to correctly map the RGB values back to elevation data, especially if dynamic ranges are used.

 

[N_Molson]

Looks great ! :thumbup:

 

[Face]

Looks great ! :thumbup:

At least it is really colorful! :rofl:

 

[igel]

I've generated my first Level 17 png from the heat map provided by tileedit. As next step, I'd like to convert it into the elv file within the Elev layer. Once it it there, I'll be able to use tileedit to tweak just the needed areas.

For that, I'd like to see some kind of png2elev tool or procedure that, along with the png file name, will just take two extra parameters for Min and Max altitudes (in meters) corresponding to the Darkest and Brightest color in the heat map. Such tool can even be standalone and work in isolation, and pick and create tiles in any separate folder. Once converted, I can place the tile to the needed folder myself.

Can such functionality be added to png2elev or to other tool?

 

[Face]

I've generated my first Level 17 png from the heat map provided by tileedit. As next step, I'd like to convert it into the elv file within the Elev layer. Once it it there, I'll be able to use tileedit to tweak just the needed areas.

For that, I'd like to see some kind of png2elev tool or procedure that, along with the png file name, will just take two extra parameters for Min and Max altitudes (in meters) corresponding to the Darkest and Brightest color in the heat map. Such tool can even be standalone and work in isolation, and pick and create tiles in any separate folder. Once converted, I can place the tile to the needed folder myself.

Can such functionality be added to png2elev or to other tool?

No. It can't take arbitrary color-mapped data and convert it to elevation data. The mapping between values and colors is not trivial. Especially not with 16-bit input and standard 8-bit RGB color-space.

The range parameter you mentioned will be there, though. However, normally you should not need to specify it, because that info is stored in the PNG's meta-data, as mentioned before.

What colormap and what bit-depth is used in your work?

 

[igel]

Here is my starting point:


My planned approximate workflow from here:

1. Cut out the heatmap image,
2. Resize it to 259x269 image
3. Save it as "11074.png" the resulting Lon index of the needed Level 17 Elev tile).
I'd keep colors the same as produced by tileedit, with whatever bit depth best.
4. Pick the Min and Max elevations from the tile, also with tileedit.
5. Convert tile to "11074.elv" and place it in \17\2006 folder of the Elev (not Evel_mod!) folder.
6. Tweak local elevations in tileedit.

 

[Face]

Here is my starting point:
View attachment 14848

My planned approximate workflow from here:

1. Cut out the heatmap image,
2. Resize it to 259x269 image
3. Save it as "11074.png" the resulting Lon index of the needed Level 17 Elev tile).
I'd keep colors the same as produced by tileedit, with whatever bit depth best.
4. Pick the Min and Max elevations from the tile, also with tileedit.
5. Convert tile to "11074.elv" and place it in \17\2006 folder of the Elev (not Evel_mod!) folder.
6. Tweak local elevations in tileedit.

In this workflow, ele2png won't do the job of 5. , because the "heatmap" color-mapping is different. Does it have full 16-bit precision? Unfortunately I don't see what colormap is used in Martin's Matlab code, at least I did not find it. Perhaps it is hidden in the *.fig file, but then I don't have Matlab to decode it.

---------- Post added at 11:09 ---------- Previous post was at 09:39 ----------

From the color codes in the "heatmap" of your tileedit screenshot, I think Martin uses the jet colormap, which seems to be a simple color-cube edge-walking according to this SO poster: http://stackoverflow.com/a/7811134

If this is true, the amount of values that such a mapping can distinguish is:

#00007F: dark blue
+128
#0000FF: blue
+128
#007FFF: azure
+128
#00FFFF: cyan
+128
#7FFF7F: light green
+128
#FFFF00: yellow
+128
#FF7F00: orange
+128
#FF0000: red
+128
#7F0000: dark red
=1024

So you can encode 1024 unique values, but the 16-bit elevation info can have 65536 values. Even if the picture uses dynamic range, it could well be that you lose information that way. E.g. the central Europe tile with the alps I've posted before has a dynamic range of -27 to 4117 meters.

 

[fort]

It would be helpful if folks involved in the off-by-one conversion error debugging can test if it now matches the expected results.

I'll try to see that. I searched for a base this morning - and there is a lot - but i think to made something simple by myself with one tile.