# ProjectOrbiter texture tree tools (OT3)

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
But this to delete the SURFTILELIST from the .cfg file is a new i formation.

If I may ask why in a previous stage we need that and after the treeman-dance we don't need anymore? Because Orbiter 2016 will simply take as first the cache files?

The previous stage is old-style textures. This is how Orbiter2010 bases worked. The method kind of works in 2016 as well, but it shows visual artifacts if you also have terrain showing (looks like the textured sphere plane shines through the terrain). After the treeman-dance, you have the texture incorporate "properly" in the texture tree, i.e. you have 2016 base definition. However, the old surface tile list in the configuration will cause Orbiter to show both representations, possibly leading to visual artifacts, therefore I always recommend to remove those lines after conversion. This has nothing to do with cache/archive precedence.

#### Aviator1280

##### New member

The previous stage is old-style textures. This is how Orbiter2010 bases worked. The method kind of works in 2016 as well, but it shows visual artifacts if you also have terrain showing (looks like the textured sphere plane shines through the terrain). After the treeman-dance, you have the texture incorporate "properly" in the texture tree, i.e. you have 2016 base definition. However, the old surface tile list in the configuration will cause Orbiter to show both representations, possibly leading to visual artifacts, therefore I always recommend to remove those lines after conversion. This has nothing to do with cache/archive precedence.

The previous stage is old-style textures. This is how Orbiter2010 bases worked. The method kind of works in 2016 as well, but it shows visual artifacts if you also have terrain showing (looks like the textured sphere plane shines through the terrain). After the treeman-dance, you have the texture incorporate "properly" in the texture tree, i.e. you have 2016 base definition. However, the old surface tile list in the configuration will cause Orbiter to show both representations, possibly leading to visual artifacts, therefore I always recommend to remove those lines after conversion. This has nothing to do with cache/archive precedence.

Hi again, I had few minutes to try and I would say I'm having good progresses. So far I tried only with 1 tile because of lack of time and just to see if it was working and yes, it works.
I got the hig-res texture using SASPlanet with precise coordinates for the tile taken from tileedit2 so to obtain precisely 512x512 PNG files.
I used photoshop to add a mask, this time in the correct way, I actually deleted the water making it transparent. Saved the new PNG file.
I used Orbiter Base Maker to place better the runways using the PNG file just edited with mask included as background for a zoom level 4.
This automatically exported the PNG with the name Earth_4_......DDS in Textures2 and added to the .cfg file the code. I changed there 1 in to 3 as suggested.
I used the -b command to get the folder structure for the Surd and for the Mask in the Texture\Earth and it also exported the .DDS file with corrected name.
I removed the code in the .cfg file.
I didn't use -i yet because I just wanted to see if this was working.

Thank you for all the tips, I'm having results

#### Attachments

• Desktop Screenshot 2020.08.20 - 20.22.45.43.png
2.7 MB · Views: 28
• Desktop Screenshot 2020.08.20 - 20.42.45.50.png
596.5 KB · Views: 27

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
Nice to hear that you made some progress!

As for the night lights, unfortunately this is the way it works. Orbiter 2010 high-res tiles did not include night-lights, they only combined surface texture and water-mask. Orbiter 2016 OTOH has many layers, one of them being the so-called Mask layer. This layer - in contrast to 2010 - combines night-light textures an water-mask in one tile.
Now what treeman does in its "-b" option is to use the available archive tree, extract Mask tiles at the appropriate high-res level (or even extrapolates it if only low levels are available), then applies the water-mask extracted from the old format over it. So what you see is by design. If you want the night-lights to be different, you have to edit the resulting tree tiles manually.

In theory it might be possible to switch this behavior off by means of temporarily renaming the Mask.tree archive so treeman can't use the data to extrapolate the original night-lights there. But I never tried that.

#### igel

I tried to use treeman to convert base tiles used for my Baikonur bases. Original tiles - really great, realistic, very detailed and nice-blending tiles - (along with base config file) can be found in this addon. I am using tool and commands referenced in the top post if this thread - except that I am only converting Surf layer, ignoring Mask layer. (Baikonur is as waterless as you can get it on the planet, and converting Mask only finds a few false-positives).

Results are very promising - same nice look, same details, nice blending, nice zooming... except for one "minor" problem: converted tiles are placed into wrong locations. Looks like a one-off bug, or something like that.

Minimal zoom level: red circle shows the true base location, and blue shows where the corresponding converted tile has ended:

Higher zoom level: tiles continue to slip right.

Even higher level reveals strange tile duplications: the area that (is supposed to be under red circle, but is covered with a different tile) shows twice to the up-left of its origin.

Am I using the version that is too old? Ir is this indeed some bug? Like, maybe the tool had not yet been used in Easter Hemisphere?

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester

#### igel

Nope. Will try that now...

#### igel

Works perfectly - tiles are right on, and so are the objects placement. I still see some artefacts at the corner of some tiles at some zoom levels - these tiles use alpha channel for blending into underlying tiles, and it looks like this blending works differently in 2016. Maybe something that can be fixed in the individual files... Though there are ~150 tiles in the original tile set, and about half of them use this side or corner blending. Well, at least I am a half-step closer to where I need to be. Thanks!

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
There is no on-the-fly alpha blending anymore. What you see is the result of the blending work that treeman does on its own. Most of the time artifacts come from extrapolated base texture, i.e. the "blown-up" tile it needs to create before it can blend-in the high-res tile. Glad it made you make some progress, though.

#### Pioneer

##### Well-known member
Trying to convert a .tex file to a Surf.tree file. Not sure exactly how to properly input the syntax. The .tex file is located in a different directory and the Surf.tree file is in the main orbiter texture directory. Also I got two errors:

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
The first parameter is always the planet root, so "Archive" is too much. The "-t" option needs the path to the file, not only a directory.

#### Pioneer

##### Well-known member
Ok, it worked. However, the texture visually does not appear at the higher resolution that I was expecting. Plus, it is only doing up to level 7, not 8 as I was expecting. I set the max patch resolution in the config file to 8.
This was my input:
Code:
F:\Games\Orbiter\ot3>treeman F:\Games\Orbiter2016\Textures\Callisto\ Surf -t F:\Games\Orbiter\callistolevel8\Textures\Callisto.tex

These are the textures I'm converting:
They are in the .tex format

This is what I'm seeing:

Last edited:

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
Yes, treeman does not convert higher than 7 currently.

#### Pioneer

##### Well-known member
Are there currently plans to incorporate higher levels?

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
Are there currently plans to incorporate higher levels?

No. If there is increased demand for converting old textures, I'll take a look, but from last I checked the higher levels get much more complicated due to the tile layout.

I have to correct myself: level 8 is the maximum supported level. I already had implemented the higher levels with the layout matrix. However, the import is not complete, it just dumps half-processed tiles into the Surf directories, so they won't show up except for the lower levels up to 5. The new level dirs 5, 6 and 7 contain files, but they are not proper tiles yet. Some merging needs to be done there, and it is not trivial.

If there is increase demand for convertin old textures, I'll take a look into that merging.

Last edited:

#### Pioneer

##### Well-known member
No. If there is increased demand for converting old textures, I'll take a look, but from last I checked the higher levels get much more complicated due to the tile layout.

I have to correct myself: level 8 is the maximum supported level. I already had implemented the higher levels with the layout matrix. However, the import is not complete, it just dumps half-processed tiles into the Surf directories, so they won't show up except for the lower levels up to 5. The new level dirs 5, 6 and 7 contain files, but they are not proper tiles yet. Some merging needs to be done there, and it is not trivial.

If there is increase demand for convertin old textures, I'll take a look into that merging.

Well, in many cases the older textures are much higher-quality than those included with the default install and the additional hi-res packs when it comes to the outer planets. So there is definitely demand from me here, and presumably other Orbinauts as well who like to fly out there.

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
However, given that this feature is there since 4 years, and you are the very first to come up with it, I guess "increased demand" is not what we are talking about yet. I thought more people would have the need to convert old planet textures, but obviously they either found another way that better suits their needs, or they are happy enough with what O2016 delivers. ?‍

#### Owenmck

Been having problems creating elevation tiles.
Any ideas?

#### Face

##### Well-known member
Orbiter Contributor
Beta Tester
Any ideas?

If you use ele2png to convert a self-made color PNG, you have to keep in mind that it uses the internal 16-bit LUT for 8-bit RGB encoding by default. How did you make the PNG, and what do the colors in your PNG represent? E.g. is it just a gray height-map encoded in RGB?

Last edited:

#### Owenmck

If you use ele2png to convert a self-made color PNG, you have to keep in mind that it uses the internal 16-bit LUT for 8-bit RGB encoding by default. How did you make the PNG, and what do the colors in your PNG represent? E.g. is it just a gray height-map encoded in RGB?
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. I was only learning how to create any elevation tiles at all.
When I converted the .elv tile back to a .png, the png it created seemed perfectly correct. I’ll post it in a few minutes

#### N_Molson

Donator
Careful as with most advanced image editors, you have several "sub-formats" (or encoding types) for each extension. So you want to be sure to use the exact right note. Also Face is right, some formats/subformats are 8, 16 or 32 bits (again, encoding). GIMP 2.0 should give you pretty much all the options available.

Replies
1
Views
277
Replies
16
Views
1K
Replies
0
Views
729
Replies
118
Views
10K
Replies
180
Views
8K