Project Orbiter texture tree tools (OT3)

[Donamy]

Try .DDS 5

 

[Face]

No, the bit was 1 since it worked fine in 2010.
Tried changing to 3 but the results are the same!

That's strange. Could you please give me pointers on how I can get hands on that config/tiles to try and see for myself?

Anyway, why convert the tiles at all? They are already DDS. Woudnl't move and rename be enough?
Sorry if the question is dumb ;-)

The question is not dumb. The reason for conversion is that there are many different formats and resolutions out there, so it gets converted to DXT1 512x512. In addition - if there is the need for alpha-blending - treeman converts it to PNG, then creates/extracts a base-tile for it, then alpha-blends it in memory, then converts the resulting PNG back to DDS.

But the most important is that it's looking good.
For a single base OT3 is more than useful with minimal manual work. Great job!

Thanks. That was the purpose of that feature: give reasonable results with minimal work, that can be used as base-lines for base authors to upgrade their addons to 2016.

 

[Donamy]

I meant DXT 5

 

[Face]

Ah wait! 4throck, did you also remove the tile entries in the config file running in 2016? I remember DaveS to note that this is sometimes necessary to avoid strange white/black-tile effects.

 

[4throck]

I tried removing the tiles from the config, no change.

Also tried to use the original tiles (manual rename), got better results but of course no merge with the base tiles.
I now understand why that is needed

My source configs/tiles come from here:
[ame="http://www.orbithangar.com/searchid.php?ID=6007"]Orbiter stock bases upgrade[/ame]

 

[Face]

Sorry, I can't reproduce the issue. Could it be that your tree archive for Mars is corrupted? If you have "cache first, then archive" enabled, and your Mars textures directory already has the region extracted, you might not see that the tree textures are off. However, treeman uses the archive - not the cache - to get base tiles to alpha-blend into.

On my setup, this is what I see if I simply extract the Olympus/Mars textures and configuration into Orbiter 2016, and just edit the config to enable the transparency bit:

Yes, this means you can apparently use DXT5 old-style overlays. :shrug: Whatever.

I then used treeman with the "-b" option to convert that, and got the following tiles: http://snoopie.at/face/beta/MarsOlympusSurf.zip
Log:

S:\Development\Orbiter2016\Utils>treeman ..\Textures\Mars Surf -b ..\Config\Mars\Base\Olympus.cfg ..\Textures2 -vv
Examining base configuration ..\Config\Mars\Base\Olympus.cfg
Header ID:DDS  size:124 flags:00021007 512x512 DXT5
reading S:\Development\Orbiter2016\Textures2\Mars_2_w0772_n0071.dds (512x512,10 BC3_UNORM 2D) as (512x512 R8G8B8A8_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000440\Mars_2_w0772_n0071.PNG
renaming S:\Development\Orbiter2016\Textures\Mars\Surf\14\000440\Mars_2_w0772_n0071.PNG to S:\Development\Orbiter2016\Textures\Mars\Surf\14\000440\000252.png
Header ID:DDS  size:124 flags:00021007 512x512 DXT5
reading S:\Development\Orbiter2016\Textures2\Mars_2_w0772_n0072.dds (512x512,10 BC3_UNORM 2D) as (512x512 R8G8B8A8_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000439\Mars_2_w0772_n0072.PNG
renaming S:\Development\Orbiter2016\Textures\Mars\Surf\14\000439\Mars_2_w0772_n0072.PNG to S:\Development\Orbiter2016\Textures\Mars\Surf\14\000439\000252.png
Header ID:DDS  size:124 flags:00021007 512x512 DXT5
reading S:\Development\Orbiter2016\Textures2\Mars_2_w0772_n0073.dds (512x512,10 BC3_UNORM 2D) as (512x512 R8G8B8A8_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000438\Mars_2_w0772_n0073.PNG
renaming S:\Development\Orbiter2016\Textures\Mars\Surf\14\000438\Mars_2_w0772_n0073.PNG to S:\Development\Orbiter2016\Textures\Mars\Surf\14\000438\000252.png
Header ID:DDS  size:124 flags:00021007 512x512 DXT5
reading S:\Development\Orbiter2016\Textures2\Mars_2_w0771_n0071.dds (512x512,10 BC3_UNORM 2D) as (512x512 R8G8B8A8_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000440\Mars_2_w0771_n0071.PNG
renaming S:\Development\Orbiter2016\Textures\Mars\Surf\14\000440\Mars_2_w0771_n0071.PNG to S:\Development\Orbiter2016\Textures\Mars\Surf\14\000440\000253.png
Header ID:DDS  size:124 flags:00021007 512x512 DXT5
reading S:\Development\Orbiter2016\Textures2\Mars_2_w0771_n0072.dds (512x512,10 BC3_UNORM 2D) as (512x512 R8G8B8A8_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000439\Mars_2_w0771_n0072.PNG
renaming S:\Development\Orbiter2016\Textures\Mars\Surf\14\000439\Mars_2_w0771_n0072.PNG to S:\Development\Orbiter2016\Textures\Mars\Surf\14\000439\000253.png
Header ID:DDS  size:124 flags:00021007 512x512 DXT5
reading S:\Development\Orbiter2016\Textures2\Mars_2_w0771_n0073.dds (512x512,10 BC3_UNORM 2D) as (512x512 R8G8B8A8_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000438\Mars_2_w0771_n0073.PNG
renaming S:\Development\Orbiter2016\Textures\Mars\Surf\14\000438\Mars_2_w0771_n0073.PNG to S:\Development\Orbiter2016\Textures\Mars\Surf\14\000438\000253.png
Header ID:DDS  size:124 flags:00021007 512x512 DXT5
reading S:\Development\Orbiter2016\Textures2\Mars_2_w0770_n0071.dds (512x512,10 BC3_UNORM 2D) as (512x512 R8G8B8A8_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000440\Mars_2_w0770_n0071.PNG
renaming S:\Development\Orbiter2016\Textures\Mars\Surf\14\000440\Mars_2_w0770_n0071.PNG to S:\Development\Orbiter2016\Textures\Mars\Surf\14\000440\000254.png
Header ID:DDS  size:124 flags:00021007 512x512 DXT5
reading S:\Development\Orbiter2016\Textures2\Mars_2_w0770_n0072.dds (512x512,10 BC3_UNORM 2D) as (512x512 R8G8B8A8_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000439\Mars_2_w0770_n0072.PNG
renaming S:\Development\Orbiter2016\Textures\Mars\Surf\14\000439\Mars_2_w0770_n0072.PNG to S:\Development\Orbiter2016\Textures\Mars\Surf\14\000439\000254.png
Header ID:DDS  size:124 flags:00021007 512x512 DXT5
reading S:\Development\Orbiter2016\Textures2\Mars_2_w0770_n0073.dds (512x512,10 BC3_UNORM 2D) as (512x512 R8G8B8A8_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000438\Mars_2_w0770_n0073.PNG
renaming S:\Development\Orbiter2016\Textures\Mars\Surf\14\000438\Mars_2_w0770_n0073.PNG to S:\Development\Orbiter2016\Textures\Mars\Surf\14\000438\000254.png
Reading header of S:\Development\Orbiter2016\Textures\Mars\Archive\Surf.tree
Header ID:TX10 size:48 flags:00000001
Archive start: 0x1B9D0 length:316607081
Low level nodes: 1=0 2=1 3=2
Quadtree roots (level 4): 3,2168
TOC nodes: 3533
Header OK, reading TOC
Building base conversion merge tree
Mapping TOC to file list
/14/000439/000252.dds
reading S:\Development\Orbiter2016\Textures\Mars\Surf\14\000439\000252a.dds (512x512 BC1_UNORM 2D) as (512x512 R8G8B8A8_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000439\000252a.PNG
split /11/000054/000031 to 64x64 at 256,448
reading S:\Development\Orbiter2016\Textures\Mars\Surf\14\000439\000252a.PNG (64x64 B8G8R8A8_UNORM 2D) as (512x512 B8G8R8A8_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000439\000252a.PNG
alpha blending S:\Development\Orbiter2016\Textures\Mars\Surf\14\000439\000252.PNG
reading S:\Development\Orbiter2016\Textures\Mars\Surf\14\000439\000252.PNG (512x512 B8G8R8A8_UNORM 2D) as (512x512 BC1_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000439\000252.DDS
/14/000438/000252.dds
reading S:\Development\Orbiter2016\Textures\Mars\Surf\14\000438\000252a.dds (512x512 BC1_UNORM 2D) as (512x512 R8G8B8A8_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000438\000252a.PNG
split /11/000054/000031 to 64x64 at 256,384
reading S:\Development\Orbiter2016\Textures\Mars\Surf\14\000438\000252a.PNG (64x64 B8G8R8A8_UNORM 2D) as (512x512 B8G8R8A8_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000438\000252a.PNG
alpha blending S:\Development\Orbiter2016\Textures\Mars\Surf\14\000438\000252.PNG
reading S:\Development\Orbiter2016\Textures\Mars\Surf\14\000438\000252.PNG (512x512 B8G8R8A8_UNORM 2D) as (512x512 BC1_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000438\000252.DDS
/14/000439/000253.dds
reading S:\Development\Orbiter2016\Textures\Mars\Surf\14\000439\000253a.dds (512x512 BC1_UNORM 2D) as (512x512 R8G8B8A8_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000439\000253a.PNG
split /11/000054/000031 to 64x64 at 320,448
reading S:\Development\Orbiter2016\Textures\Mars\Surf\14\000439\000253a.PNG (64x64 B8G8R8A8_UNORM 2D) as (512x512 B8G8R8A8_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000439\000253a.PNG
alpha blending S:\Development\Orbiter2016\Textures\Mars\Surf\14\000439\000253.PNG
reading S:\Development\Orbiter2016\Textures\Mars\Surf\14\000439\000253.PNG (512x512 B8G8R8A8_UNORM 2D) as (512x512 BC1_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000439\000253.DDS
/14/000438/000253.dds
reading S:\Development\Orbiter2016\Textures\Mars\Surf\14\000438\000253a.dds (512x512 BC1_UNORM 2D) as (512x512 R8G8B8A8_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000438\000253a.PNG
split /11/000054/000031 to 64x64 at 320,384
reading S:\Development\Orbiter2016\Textures\Mars\Surf\14\000438\000253a.PNG (64x64 B8G8R8A8_UNORM 2D) as (512x512 B8G8R8A8_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000438\000253a.PNG
alpha blending S:\Development\Orbiter2016\Textures\Mars\Surf\14\000438\000253.PNG
reading S:\Development\Orbiter2016\Textures\Mars\Surf\14\000438\000253.PNG (512x512 B8G8R8A8_UNORM 2D) as (512x512 BC1_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000438\000253.DDS
/14/000439/000254.dds
reading S:\Development\Orbiter2016\Textures\Mars\Surf\14\000439\000254a.dds (512x512 BC1_UNORM 2D) as (512x512 R8G8B8A8_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000439\000254a.PNG
split /11/000054/000031 to 64x64 at 384,448
reading S:\Development\Orbiter2016\Textures\Mars\Surf\14\000439\000254a.PNG (64x64 B8G8R8A8_UNORM 2D) as (512x512 B8G8R8A8_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000439\000254a.PNG
alpha blending S:\Development\Orbiter2016\Textures\Mars\Surf\14\000439\000254.PNG
reading S:\Development\Orbiter2016\Textures\Mars\Surf\14\000439\000254.PNG (512x512 B8G8R8A8_UNORM 2D) as (512x512 BC1_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000439\000254.DDS
/14/000438/000254.dds
reading S:\Development\Orbiter2016\Textures\Mars\Surf\14\000438\000254a.dds (512x512 BC1_UNORM 2D) as (512x512 R8G8B8A8_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000438\000254a.PNG
split /11/000054/000031 to 64x64 at 384,384
reading S:\Development\Orbiter2016\Textures\Mars\Surf\14\000438\000254a.PNG (64x64 B8G8R8A8_UNORM 2D) as (512x512 B8G8R8A8_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000438\000254a.PNG
alpha blending S:\Development\Orbiter2016\Textures\Mars\Surf\14\000438\000254.PNG
reading S:\Development\Orbiter2016\Textures\Mars\Surf\14\000438\000254.PNG (512x512 B8G8R8A8_UNORM 2D) as (512x512 BC1_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000438\000254.DDS
/14/000440/000252.dds
reading S:\Development\Orbiter2016\Textures\Mars\Surf\14\000440\000252a.dds (512x512 BC1_UNORM 2D) as (512x512 R8G8B8A8_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000440\000252a.PNG
split /11/000055/000031 to 64x64 at 256,0
reading S:\Development\Orbiter2016\Textures\Mars\Surf\14\000440\000252a.PNG (64x64 B8G8R8A8_UNORM 2D) as (512x512 B8G8R8A8_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000440\000252a.PNG
alpha blending S:\Development\Orbiter2016\Textures\Mars\Surf\14\000440\000252.PNG
reading S:\Development\Orbiter2016\Textures\Mars\Surf\14\000440\000252.PNG (512x512 B8G8R8A8_UNORM 2D) as (512x512 BC1_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000440\000252.DDS
/14/000440/000253.dds
reading S:\Development\Orbiter2016\Textures\Mars\Surf\14\000440\000253a.dds (512x512 BC1_UNORM 2D) as (512x512 R8G8B8A8_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000440\000253a.PNG
split /11/000055/000031 to 64x64 at 320,0
reading S:\Development\Orbiter2016\Textures\Mars\Surf\14\000440\000253a.PNG (64x64 B8G8R8A8_UNORM 2D) as (512x512 B8G8R8A8_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000440\000253a.PNG
alpha blending S:\Development\Orbiter2016\Textures\Mars\Surf\14\000440\000253.PNG
reading S:\Development\Orbiter2016\Textures\Mars\Surf\14\000440\000253.PNG (512x512 B8G8R8A8_UNORM 2D) as (512x512 BC1_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000440\000253.DDS
/14/000440/000254.dds
reading S:\Development\Orbiter2016\Textures\Mars\Surf\14\000440\000254a.dds (512x512 BC1_UNORM 2D) as (512x512 R8G8B8A8_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000440\000254a.PNG
split /11/000055/000031 to 64x64 at 384,0
reading S:\Development\Orbiter2016\Textures\Mars\Surf\14\000440\000254a.PNG (64x64 B8G8R8A8_UNORM 2D) as (512x512 B8G8R8A8_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000440\000254a.PNG
alpha blending S:\Development\Orbiter2016\Textures\Mars\Surf\14\000440\000254.PNG
reading S:\Development\Orbiter2016\Textures\Mars\Surf\14\000440\000254.PNG (512x512 B8G8R8A8_UNORM 2D) as (512x512 BC1_UNORM 2D)
writing S:\Development\Orbiter2016\Textures\Mars\Surf\14\000440\000254.DDS

The log shows how at first the DXT5 tiles are converted to PNG. The second part then shows how the proper ancestor tile in the tree gets extracted, split, and blown up to the appropriate resolution to get a base tile. Then each converted PNG gets alpha-blended into its base tile, then converted to DXT1 DDS again.

After removing the Texture2 old-style tiles AND the config *_SURFTILELIST lines, this is what I see:

Of course this will not look good while zooming in/out, because I did not integrate the resulting tiles back into the lower resolutions, but it is what I would expect from just running the "-b" option.

 

[4throck]

Thanks for testing!
Your printscreens are as expected.

I agree that the problem is on my end and has to do with the tree archive.
Time to re-download ... :hmm:

 

[fort]

Hello,

As said,

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

What are x and y ?

PlanetTextures.pdf (paragraph 9); extract:


My reasoning is based on a reading of the x and y values as representative of the numbering of the surftiles. I think that it's the right - maybe the only - way but one never know.

And for Earth_4_w1836_n0650.dds for example, x would value 1836 and y 650.

I do not see wich other operational reading is possible.

#

For a simple approach, i uses a grid of level 7 in Orbiter, containing 16 tiles from West to East and 8 from North to South.

In the edition 2016 their distribution is:



Numbering starting from 0 ( 000000.dds, folder 000000) with, as origin, the upper left corner of the map.

The surftiles in orbiter in 2010 and earlier versions has for reference the center of the map each of it being assigned of a number and a letter - w, e, n, s - according to his position with respect to this center.

All things that we know.

There is no surftiles corresponding to that orbiter level of 7. But for simplicity of the reasoning if one imagines...

...oh but first, it is useful to observe what the Surftilecalculator of Ar81 indicates at level 0. And first for longitudes.

This level is defined by 512 tiles from West to East and 256 from North to South.



The tile the most at West has the number (w) 256.

We can assume (and that is the case) that there is no e256 surftile, since, if the reference, in general, for longitude, of a surftile, for her indexing, is its left edge, a e256 surftile would be out of the map.

Regarding references for latitudes if the indexing of the surftiles was from the North, the northernmost should be named n128. This is what, can be, comes first in mind.



But no; it is at South that the references begin and where the surftiles takes the s128 value.

Due North it's: 128 - 1; namely: n127 ( number of tiles in latitude (256) / 2 -1).

But maybe is it an error of the Surftilecalculator.

This image shows a surftile of n127 value and DG placed in the center. This is actually the last possible surftile at North.



#

And therefore, if one imagines a grid of surftiles at a very low level (- 5) - 16 surftiles from West to East and 8 from North to South - the surftile located the most northern should be entitled n3 (8/2 -1).

Combining the 2016 tree (gray) with that of such grid (orange) produces this:

http://www.easy-upload.net/fichiers/162148765765136.201832117

Edit1 (12/11 ): for simplification.

:coffee:

 

[Face]

I understand your reasoning.

This is what I've sent martins regarding my thoughts on the matter:

I think the reason for this mismatch is your definition of a value set with two zeros for both coordinate axis (E0 and W0, and N0 and S0, respectively). As it seems, this is incorrect, because it looks more like the standard integer value set (two's complement) - which doesn't include a negative zero - is used.

Martin's documentation list it as:

For base tile resolution level m, the surface is divided into [math]2^{m+9}[/math] longitude strips and [math]2^{m+8}[/math] latitude strips, with longitude designations
[W[math]2^{m+8}[/math], . . . , W0, E0, . . . , E[math]2^{m+8}[/math]-1]

Mathematically, Martin's sentence there is wrong. Proof by counter-example:

• Let n be number of longitude strips for m=1, then [math]n=2^{1+9}=2^{10}=1024[/math].

• Let k be the cardinality of the set of longitude designations [math]\Lambda[/math], then we have [math]k=|\Lambda|[/math] with [math]\Lambda[/math] being [W[math]2^{1+8}[/math], . . . , W0, E0, . . . , E[math]2^{1+8}[/math]-1].

• You can also write that set as union of the two sets [math]\Lambda_W[/math] and [math]\Lambda_E[/math] like so: [math]\Lambda= \Lambda_W \cup \Lambda_E = [W512, . . . , W0] \cup [E0, . . . , E511][/math].

• Since both sets are disjoint, [math]k=|\Lambda|=|\Lambda_W|+|\Lambda_E|[/math].

• [math]\Lambda_W[/math] enumerates the numbers from 0 to 512, making it 513 numbers.

• [math]\Lambda_E[/math] enumerates the numbers from 0 to 511, making it 512 numbers.

• Thus [math]k=513+512=1025[/math]. Therefore, [math]n \ne k[/math]. Q.E.D.

You can do the same for the set of latitude designations.

 

[fort]

Hello Face,

I think that i understand your explanation. Thank you for.

I tried to be pragmatic, as methodique ( in french ) as possible. Those formulas works almost everywhere on the map and maybe everywhere. There still will be maybe one or two things to verify....in case of but...And OT3 works to. So.

 

[Face]

Was it necessary to send a message for that to Martin ?

I think Martin is open for corrections of wrong statements in his documentation. While it might not have been necessary for OT3 here (because it works, anyway), it is necessary for others interested in base conversion.

Besides: this was the one and only PM I've sent him on this matter. You can hardly call that spamming :lol: . I will certainly not press the issue, though, and with this post here, I rest my case in this matters.

 

[4throck]

Just to say that I've redownloaded 2016 textures and deleted my converted surf tiles.
Tried new conversions with all source .cfg and .dss on the 2010 folder, and it works.

I think that putting the old bases and texture2 .dds in 2016 is what messed things up.

 

[4throck]

Some more constructive feedback

From my tests, I found out that when you have multiple tile levels on your 2010 base, transparency is always computed related to the base global level.
(I may be missing some command line parameter, and if such my wrong...)

Most bases have a larger low resolution coverage (level 1) with higher resolution insets (level 4 and above), both alpha blending.
As it is, the insets don't blend into the lower level tiles, but to the global texture.

Of course, I can blend the level 1 tiles into level 4 manually.
I know OT3 is not an emulator yet I think one can expected the output to be similar to what you get on Orbiter 2010. ;-)

 

[Face]

From my tests, I found out that when you have multiple tile levels on your 2010 base, transparency is always computed related to the base global level.
(I may be missing some command line parameter, and if such my wrong...)

Most bases have a larger low resolution coverage (level 1) with higher resolution insets (level 4 and above), both alpha blending.
As it is, the insets don't blend into the lower level tiles, but to the global texture.

Of course, I can blend the level 1 tiles into level 4 manually.
I know OT3 is not an emulator yet I think one can expected the output to be similar to what you get on Orbiter 2010. ;-)

Interesting information. Do you know an example of such a cascaded tile structure that I can take a look at?

Indeed treeman's -b option processes the tiles one after the other, always using the archive's content as base tile.

The option was thought to give people a reasonable starting point in converting old bases into new ones, not as 1:1 converter. However, if this "stacking" behavior can be incorporated easily into the process, I don't see why it should not be implemented.

 

[4throck]

Face, I'd appreciate that very much. I know it's beyond the original OT3 intent, but with that option one can use Orbiter Base Maker + OT3 as a 2016 base creation package.
Remember that OBM uses Landsat imagery that's compatible with 2016 global coverage. So we can have a complete solution.

Here's the Gran Canaria base with level 1 and level 4 tiles, both with cascaded transparency.
View attachment Gran Canaria.zip

And this is how it looks in 2010.
View attachment 14906

 

[Face]

Here's the Gran Canaria base with level 1 and level 4 tiles, both with cascaded transparency.

Thanks for the example. I'll give it a shot.

---------- Post added at 18:15 ---------- Previous post was at 11:53 ----------

View attachment 14907

There seems to be some corruption in there. /Textures2/Earth_1_W0045_N0080.dds can't be extracted with Win7 built-in ZIP support nor 7Zip. Both show a data error.

Can you take a look, please? I'll work on the remaining tiles in the mean-time.

 

[4throck]

Yep, the file got corrupted somehow. Strange.
Here's a new version:
View attachment Gran Canaria.zip

Anyway, the corrupted tile corresponds to the northern edge of the island, just copy/rename another one and it will work.

The thing to look for is the blending around the center of the base. That's where the higher resolution tiles are. Since we also have ocean there, I think it's a relevant test.

Thanks in advance for your time! :tiphat:

 

[Face]

I've made some tests with Gran Canaria.

This is what it looks like if I just put it into 2016 as it is:

Now after running -b both with Surf and Mask layer (for coast-lines):

You can clearly see where that falls apart. Obviously the mask layer conversion is not making it look good, so lets get rid of it:

And here I can see the mentioned stacking problem. The redish/brown color is the stock texture.

I think if I simply let Surf layer -b run from the lower resolutions to the higher resolutions and allow intermediate results to be re-used in upper resolution conversions, the last picture's color mismatch goes away. But that's only half of the story.
I guess I'll also have to let lower intermediate mask alpha overwrite higher mask alpha, so that weird insular result from picture 2 goes away, too.

However - and this is really something that makes me think - the simple drop-in of old bases in Orbiter 2016 seems to just work. And with good results. I wonder why I've even invested time into the -b option, with this already working out of the box. At first I thought this came in with the newest beta changes, but then I've realized that the version I'm using to test OT3 is still the 2016 release one.
So why even bother anymore? Why would somebody want to put those textures into the tree, if it works as drop-in anyway? The only advantage I can see is a better performance if you have many bases installed the old way.

Do I miss something here? I first thought that old bases will not work anymore, so the need was clear. I tried it once in the RC runs, and confirmed that bases like WIA did not show up anymore. But now it seems to me like it should make no difference. :shrug:

 

[Notebook]

Glad to hear you are confused, means I'm in good company! I thought(one) of the objects of your program was to assist in flattening terrain around airports?

I don't understand 2016 tile and surface mesh system well enough to have a go yet. I was waiting till you were further on to start converting my 2010 bases.

I hope you continue with the tools

N.

 

[Face]

Glad to hear you are confused, means I'm in good company! I thought(one) of the objects of your program was to assist in flattening terrain around airports?

Well, I really only started to bolt the base conversion option onto treeman after I realized that old bases won't work anymore. But they work just fine, as it seems. I've tested old bases in the RCs and saw that they did not work out, so I thought the -b option will be helpful to get people started with converting their bases.

Now it seems like I've made a mistake. Old bases work just fine. Granted, the coast-line masking is not as pretty as it could be, but otherwise they are OK. So the need for -b is not given anymore.

That's where my confusion is coming from. It has nothing to do with the terrain flattening aspect. OT3 was initially not meant to deal with editing of tiles directly. It assists with flattening of terrain around bases in so far as it offers a program (ele2png as of now, perhaps ele23DS later) that converts the proprietary ELV format to a format that can be edited by usual programs (e.g. GIMP), and back again.