Project Orbiter texture tree tools (OT3)

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
But this to delete the SURFTILELIST from the .cfg file is a new i formation.

At the end of the very first post in this thread I had that noted already.

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
Joined
Aug 12, 2020
Messages
10
Reaction score
4
Points
3
At the end of the very first post in this thread I had that noted already.



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.
At the end of the very first post in this thread I had that noted already.



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.

Now I've one more question. When I used the treeman and I created the Mask folder the .DDS file used for the tile has been automatically recognized having a mask and I can see it in the Mask folder in black and white which is ok but the problem is that it overlapped with the original night light mask, practically I can see a fusion of the new water mask with old night light mask. How can I avoid this? And after avoiding this to make a night light mask what should I do? May be I've the answer but not sure... When I added a new Channel in photoshop (see picture) and made the mask, on the channel window there where also other levels, there is the RGB level, should I edit that one for the light with white or yellow colors? or more simply apply some real night light picture?

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

Attachments

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

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
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

Addon Developer
Joined
Mar 28, 2008
Messages
252
Reaction score
119
Points
43
Website
www.pin-plus.ca
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:

MinZoom.png

Higher zoom level: tiles continue to slip right.
MidZoom.png

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.
HighZoomMultiples.PNG

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?
 

igel

Addon Developer
Joined
Mar 28, 2008
Messages
252
Reaction score
119
Points
43
Website
www.pin-plus.ca
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
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
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
Joined
Mar 2, 2012
Messages
506
Reaction score
272
Points
78
Location
Greater Detroit
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:
1605462581356.png
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
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
Joined
Mar 2, 2012
Messages
506
Reaction score
272
Points
78
Location
Greater Detroit
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:
1605483949777.png
 
Last edited:

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
Yes, treeman does not convert higher than 7 currently.
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
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
Joined
Mar 2, 2012
Messages
506
Reaction score
272
Points
78
Location
Greater Detroit
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
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
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

Read the documentation!
Joined
Apr 18, 2020
Messages
125
Reaction score
117
Points
58
Location
Scotland
Been having problems creating elevation tiles.
Any ideas?
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
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

Read the documentation!
Joined
Apr 18, 2020
Messages
125
Reaction score
117
Points
58
Location
Scotland
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

Addon Developer
Addon Developer
Donator
Joined
Mar 5, 2010
Messages
9,271
Reaction score
3,244
Points
203
Location
Toulouse
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.
 
Top