Project Orbiter texture tree tools (OT3)

[4throck]

I'm probably two weeks into this now and the frustration level is high.

Been trying since 2016 and still no luck :lol:

The only tool that works consistently for me is TerrainToolBox/Terrain ToolKit ( https://www.orbiter-forum.com/showthread.php?t=41279 ).
You load orbiter, select your titles, export, do changes, import back. No messing around, no guessing about numbers. Used it for Project Mercury 2016.

Unfortunately it doesn't support elevation tiles...

TileEdit works but I need to streamline my workflow. Some settings make it crash for example, and you need to do things in a certain way.
But it does work for simple terrain editing within the tool.

 

[mxk]

I updated this addon
Airport addon
and there i describe how i edit elevation with TileEdit

 

[Aviator1280]

Hello everyone and hello Face.
I tried to read as much as I could and experiment as well.
Following the steps in the PDF Bulgaria Airports and putting other things together I managed don't know exactly how to arrive to a point where I can insert tile textures in the right place but I've some doubt I couldn't solve so far by myself, if someone can help I appreciate. Here the steps I do:

1) I start to place my meshes on the ground using "Orbiter Base Maker", here don't know why I can't download the tiles automatically (may be because they are in the .tree format) but I just extract them from "SASPlanet" taking the information needed from "Surface Tile Calculator 5" or "tileedit2" then I applied them at the correct zoom level so I can see where to put meshes and runways. So far it seems everything ok.

2) When I'm done with "Orbiter Base Maker" it will save those tiles in DDS format in Textures2 folder.

3) I use then "treeman" to create the correct path where these DDS files will be located with the correct name.
Here is my first doubt because in the Bulgaria Airports PDF was jumping some detail. Is "Orbiter Base Maker" indispensable to easy create the DDS files in Texture2 that treeman needs to create the folder tree?

4) Since I used already high resolution PNG in "Orbiter Base Maker" I already have good quality DDS file so I just proceed to use "treeman" again to generate the other levels using the command "treeman ..\Textures\Earth Surf -i -F list.txt.
Here is my second question. When I use this command I could expect that the tile texture I made would be in the middle of those generated by treeman but it is not like this, the tile texture I made is usually at one of the corner. Is this normal?

5) Somehow anyway I get almost what I would like the problem now is that I didn't understand at all how to make the Water Mask. I tried to modify the PNG file of the ground using just black and white then saving ad DDS but so far Orbiter uses it as Light mask and not as water mask.
I tried to understand how the mask is made using one of the Bulgarian Airports and I can see in the same DDS there is a black and white area to define the land and the sea and other RGB colors for the lights. I'm wondering where I make the mistake or what I jump.

If anybody can read my steps and correct me if I do something wrong and answer to my question I would appreciate.
Thank you.

 

[Face]

3) I use then "treeman" to create the correct path where these DDS files will be located with the correct name.
Here is my first doubt because in the Bulgaria Airports PDF was jumping some detail. Is "Orbiter Base Maker" indispensable to easy create the DDS files in Texture2 that treeman needs to create the folder tree?

treeman's extraction mechanism does not need anything besides the archive (*.tree) to extract it to the folders (aka "cache"). You can restrict the set of extracted tiles via regular expressions, though.

4) Since I used already high resolution PNG in "Orbiter Base Maker" I already have good quality DDS file so I just proceed to use "treeman" again to generate the other levels using the command "treeman ..\Textures\Earth Surf -i -F list.txt.
Here is my second question. When I use this command I could expect that the tile texture I made would be in the middle of those generated by treeman but it is not like this, the tile texture I made is usually at one of the corner. Is this normal?

Since Orbiter uses a quadtree data structure to implement the tile LOD, it is normal that your lower level tile will usually be in the corner of the upper level tile.

5) Somehow anyway I get almost what I would like the problem now is that I didn't understand at all how to make the Water Mask. I tried to modify the PNG file of the ground using just black and white then saving ad DDS but so far Orbiter uses it as Light mask and not as water mask.
I tried to understand how the mask is made using one of the Bulgarian Airports and I can see in the same DDS there is a black and white area to define the land and the sea and other RGB colors for the lights. I'm wondering where I make the mistake or what I jump.

You have to make a so-called alpha layer in your PNG. This is additional data that determines the alpha value of each pixel, which means that it encodes transparency of this pixel. Usually, for water masks, you use either fully transparent or fully opaque pixels, mostly visualized as black and white colors.

For the rest I can't really help you, as I am not the author of the tutorials or PDFs mentioned in your post. I also don't know too much about Orbiter Base Maker.

 

[Aviator1280]

Thank you Face for your answer, very kind.

treeman's extraction mechanism does not need anything besides the archive (*.tree) to extract it to the folders (aka "cache"). You can restrict the set of extracted tiles via regular expressions, though.

If treeman doesn't need anything else besides the archive (*.tree) why if I don't have the .dds in Texture2 the list.txt that it generates is empty? So far following the command taken from this forum in the list.txt file I get something only based on the .dds files. So I'm confused.
How to "tell" treeman which tile to extract? I thought it could take this information from the .cfg file of the base.

You have to make a so-called alpha layer in your PNG. This is additional data that determines the alpha value of each pixel, which means that it encodes transparency of this pixel. Usually, for water masks, you use either fully transparent or fully opaque pixels, mostly visualized as black and white colors.

So if I understand on the same PNG file in a program like photoshop i generate a new level where I make the mask? Do you have any practical example on how to do this because I'm not sure I understood. So far I just tried to make a PNG with transparency on where I wanted the water but it didn't work and when I tried to make it black and white Orbiter thought it was a night light mask. If you can give me more detail would be nice.

Thank you

 

[Face]

If treeman doesn't need anything else besides the archive (*.tree) why if I don't have the .dds in Texture2 the list.txt that it generates is empty? So far following the command taken from this forum in the list.txt file I get something only based on the .dds files.

treeman does not generate a list.txt file directly, it generates output which you can pipe to a file. This output is usually the relative path to the extracted files it processed, and it is often used as input to the next call in the chain.
treeman has an option to convert old-style base high-res tiles. The relative paths of the tree tiles it generates there can be piped into a file for later use with the integration option of treeman. If you mean this base-conversion call, perhaps the specified base config-file does not contain the proper tiles to convert from?

I don't know what chain you are talking about, but I suppose you mean something from the tutorials you mentioned. Please contact the authors for further information.

So if I understand on the same PNG file in a program like photoshop i generate a new level where I make the mask? Do you have any practical example on how to do this because I'm not sure I understood. So far I just tried to make a PNG with transparency on where I wanted the water but it didn't work and when I tried to make it black and white Orbiter thought it was a night light mask. If you can give me more detail would be nice.

No, what you have to do in your picture editor is to add an alpha layer. Not just another level. This alpha layer is often called transparency or opacity layer as well. In this layer, you give each pixel another value besides color... it's alpha value, which represents transparency. I can't give you specific directions, as every image editor in different versions has other workflows and/or menu-cascades to achieve this.
Unfortunately I'm not a good teacher when it comes to basic image editing skills, but I'm sure there are tons of tutorials out there for adding alpha layer in PNG images for the photoshop version you use. A quick google search brought up this:

 

[Aviator1280]

treeman does not generate a list.txt file directly, it generates output which you can pipe to a file. This output is usually the relative path to the extracted files it processed, and it is often used as input to the next call in the chain.
treeman has an option to convert old-style base high-res tiles. The relative paths of the tree tiles it generates there can be piped into a file for later use with the integration option of treeman. If you mean this base-conversion call, perhaps the specified base config-file does not contain the proper tiles to convert from?

Hello Face, thank you for your answer.
While I believe I understood how to edit the PNG file and I'm going to try it today, I believe I still don't understand how treeman works. I couldn't find a guide or tutorial about it so all my understanding comes from trying things.
May be if I tell you what exactly I've you can tell me how to proceed correctly? It would be for a better understanding because anyway so far somehow I can create high res tiles. Let's suppose I don't use "Orbiter Base Maker" that generates from the tiles I load in it the .dds files in the format Earth_z_y_x in the Orbiter2016\Texture2 folder. Let's say I only made a .cfg file for the base I'm creating. In this case the file name and root are Orbiter2016\Config\Earth\Base\Hong_Kong.cfg and the file looks like this

BASE -V2.0
Name = Hong Kong
Location = 113.915001 22.30834
Size = 1000
ObjectSize = 100
MAPOBJECTSPHERE = TRUE
...
...
BEING_SURFTILELIST
4 2591 507 1 (this has been created by Orbiter Bame Maker that also gemerate the .dds file. Do I need this part of the code to use treeman or I need to modify it?)
END_SURFTILELIST

So now how should I proceed to extract with treeman the tiles I need from the .tree archive that are in the standard folder Orbiter2016\Textures\Earth\Archive?
So to have the new folders Surf and Mask under the folder Earth with the required .dds properly named to work with them later on for example to change them with better tiles and masks.

I hope I've been clear enough in my question and you can write here the commands for treeman I should use.

 

[Face]

I see. You are trying to create a base for Orbiter2016 by means of creating it first in the old format, then converting it to the new format.

In this case I'd suggest to first get the base working for Orbiter2010, with all high-res tiles necessary to make it look good. You had to provide the transparency data in the high-res tiles back then (i.e. the tiles had an alpha channel representing the water mask), which you also had to signal to Orbiter by means of setting bit1 of the flag value in the SURFTILELIST (your example shows flag value 1 in the single SURFTILELIST line, meaning that that tile should not be read having an alpha channel, it should be value 3 instead). Please consider re-reading Orbiter's 2010 documentation in this regards, it is in the "Doc" folder, named "OrbiterConfig.pdf".
Why Orbiter Base Make creates the tiles the way it does, I don't know. Please contact the author for this.

Then proceed to convert it via treeman's "-b" option. I have shown example commands in the first post of this thread, along with a description what each step does.

I fail to see why you want to extract tiles from the archive at all, because you are going the other way around, anyway. If you perhaps miss a good starting point for the mask, the tiles in the archive won't help you much, because you either have it in a low resolution, or have it in multiple tiles you'd have to stitch together, which is what treeman can't do for you.

 

[Aviator1280]

I see. You are trying to create a base for Orbiter2016 by means of creating it first in the old format, then converting it to the new format.

In this case I'd suggest to first get the base working for Orbiter2010, with all high-res tiles necessary to make it look good. You had to provide the transparency data in the high-res tiles back then (i.e. the tiles had an alpha channel representing the water mask), which you also had to signal to Orbiter by means of setting bit1 of the flag value in the SURFTILELIST (your example shows flag value 1 in the single SURFTILELIST line, meaning that that tile should not be read having an alpha channel, it should be value 3 instead). Please consider re-reading Orbiter's 2010 documentation in this regards, it is in the "Doc" folder, named "OrbiterConfig.pdf".
Why Orbiter Base Make creates the tiles the way it does, I don't know. Please contact the author for this.

Then proceed to convert it via treeman's "-b" option. I have shown example commands in the first post of this thread, along with a description what each step does.

I fail to see why you want to extract tiles from the archive at all, because you are going the other way around, anyway. If you perhaps miss a good starting point for the mask, the tiles in the archive won't help you much, because you either have it in a low resolution, or have it in multiple tiles you'd have to stitch together, which is what treeman can't do for you.

Hi again Face.
Actually I was completely ignoring that I was using the Orbiter2010 way to create a base. The problem is that everything I found around is so old that I'm trying to put things together and find out the better way. I also spent long time to understand how to make a mesh with 3D Studio Max with textures and import to Orbiter.
I arrived here I think essentially because i wanted to extract the correct tiles to place my runways and meshes since if inserted using real numbers something it is not perfectly aligned. I think Orbiter doesn't take in consideration the Magnetic Variation so everything should be placed respect the true north but doing so for example the localizer of the rwy shows a wrong number because is true and not magnetic and in real life we fly using a magnetic compass except if flying northern than 80° North or South. Because of this story I wanted to extract the textures from Orbiter to better place objects.
I will check the documentation you mentioned.
Since we are here I tried to use in some experiment tileedit2 to leveloff the land but O believe that one take the elevation file in the .tree and save a new edited file. So this elevation file it is not perfect at all and make it become perfect it's very difficult. I believe I should use the program included in ot3 to make a better elev file?
I still didn't try it but if I understood what I read here I can use a code to transform my PNG file in to a mask that contains the elevation data. Is this correct?

Thank you

 

[Face]

The elevation data story is complicated. What the OT3 toolset offers is ele2png.exe . This is a CLI tool that takes an elevation tile in Orbiter format and converts it into a PNG representation, and vice versa. The program has various options to control the mapping between the elevation data and the pixel color representation.

The idea is that you use treeman to extract elevation tiles, convert them with ele2png to PNG, edit the picture with an image editor, then convert it back to Orbiter format with ele2png. Unfortunately, this is not enough, because you have to integrate the information through the whole tree up and done, not only at the LOD level that the tile is at. And this is something neither ele2png nor treeman can do for you automatically (yet). It is also really cumbersome to deal with all the tiles separately when you want to edit a large area, especially given that you have to deal with the overlap of terrain tiles manually.

I stopped developing on this front, because Martin came up with a better approach to the elevation editing story: tileedit. This tool offers a GUI where you can edit the elevation points directly through a specialized editor, and it also does the integration throughout the tree for you automatically. In addition, there was the area flattening idea that IMHO addresses the real reason for the need for elevation editing much better: wanting to flatten ground for base objects. In reality, nobody wants to craft detailed terrain by hand, just wants to flatten the damn bumpy hills around his base.

However, with the tileedit workflow still being a bit cumbersome and the area flattening idea not being adopted, the story remains complicated.

 

[Aviator1280]

The elevation data story is complicated. What the OT3 toolset offers is ele2png.exe . This is a CLI tool that takes an elevation tile in Orbiter format and converts it into a PNG representation, and vice versa. The program has various options to control the mapping between the elevation data and the pixel color representation.

The idea is that you use treeman to extract elevation tiles, convert them with ele2png to PNG, edit the picture with an image editor, then convert it back to Orbiter format with ele2png. Unfortunately, this is not enough, because you have to integrate the information through the whole tree up and done, not only at the LOD level that the tile is at. And this is something neither ele2png nor treeman can do for you automatically (yet). It is also really cumbersome to deal with all the tiles separately when you want to edit a large area, especially given that you have to deal with the overlap of terrain tiles manually.

I stopped developing on this front, because Martin came up with a better approach to the elevation editing story: tileedit. This tool offers a GUI where you can edit the elevation points directly through a specialized editor, and it also does the integration throughout the tree for you automatically. In addition, there was the area flattening idea that IMHO addresses the real reason for the need for elevation editing much better: wanting to flatten ground for base objects. In reality, nobody wants to craft detailed terrain by hand, just wants to flatten the damn bumpy hills around his base.

However, with the tileedit workflow still being a bit cumbersome and the area flattening idea not being adopted, the story remains complicated.

I see. My included tileedit in the util folder doesn't work so I use tileedit2 anyway it does have some problem, many time crash to desktop when for example I keep open the Elevation picture or when I focus on a tile already added. Sometime it works sometime it crashes. Sometime after I added a tile it shows the original elevation mask from the .tree sometime instead it is just empty, I don't really understand when it happens what and why.
Anyway thank you for all your explanation it's a pity this simulator has been almost abandoned and can't find many updated tutorials or tools. I was actually surprised on how here there were recent posts.
I will try with the new information you provided me and I will let you know the result if any ?.
Thank you.

 

[Notebook]

I can't help with the tree structure, beyond me.

I have used this utility to make alpha masks for DDS tiles in Orbiter. For coastal tiles and blending to lower levels.

DXTBmp Texture tool

www.mwgfx.co.uk

It will open various format graphics and will generate an Alpha Mask for the tile you are working with.
It lets you select whatever paint program you have, defaults to Paint.

With an Alpha mask you have to set the dds type to three(you can do this when you save your modified tile back to the Textures directory) and make the corresponding entry in .cfg entry to a 3 from a 1.

 

[Aviator1280]

With an Alpha mask you have to set the dds type to three(you can do this when you save your modified tile back to the Textures directory) and make the corresponding entry in .cfg entry to a 3 from a 1.

Thank you. So at the end I will have in the ..Texture/Earth folder at least 2 other folders, Surf and Mask. Both of them with sub folder named according the zoom level, Latitude and Longitude for the DDS file.
It means I will have for the same tile 2 DDS file with same name but in 2 different positions. One is the terrain texture and the other one will be the Mask that can contain water and night lights.
In the .cfg file I will need to see the code ending with 1 for the Surf and the same code but ending with 3 for the Mask.
Is this correct or I only need 1 entry because that 3 means take the surf dds and the mask dds with this name (or something like this...)?
I can't try at the moment because busy with work.
Thank you

 

[Notebook]

Sorry, but no to most of those questions!

I was working only with Orbiter 2010 in mind, but the bases I made do seem to work in 2016.

I don't touch the new tree system with its multitude directories, It works straight on the .dds files in the Texture directory.
That utilty modifies the tile by adding the Alpha mask, then you work on the Alpha mask in your paint program. Save it back to the Textures dir. as a type 3 DDS file.
Then you have to change its entry in the base .cfg file from a 1 suffix to a 3 suffix or you won't see the masking.

I hope I'm not adding confusion here. All this will do is allow you to make coastal tiles, and blend to other tiles "below".

Its nothing to do with the Orbiter 2016 tile structure.

 

[Aviator1280]

Sorry, but no to most of those questions!

I was working only with Orbiter 2010 in mind, but the bases I made do seem to work in 2016.

I don't touch the new tree system with its multitude directories, It works straight on the .dds files in the Texture directory.
That utilty modifies the tile by adding the Alpha mask, then you work on the Alpha mask in your paint program. Save it back to the Textures dir. as a type 3 DDS file.
Then you have to change its entry in the base .cfg file from a 1 suffix to a 3 suffix or you won't see the masking.

I hope I'm not adding confusion here. All this will do is allow you to make coastal tiles, and blend to other tiles "below".

Its nothing to do with the Orbiter 2016 tile structure.

Thanks, that's fine, I will need to try. I need the new folder structure because I'm applying much better terrain textures. So far I was able to apply them and using the option -i pf treeman the effect was ok but no water effect so I need to take the PNG of the new tiles and apply and alpha layer and save this in the Mask folder in dds format in the proper sub directory and in the .cfg file change1 with 3 at the end of the dds file name listed there. Curious to apply these new stuff but now can't.

 

[Notebook]

As you are working in the new file structure, afraid I can't help with that. I did try a few times, but beyond me.

That utilty is useful, if nothing else for making alpha channels.

 

[Face]

I think Aviator's only "mistake" in the chain he followed (create in old format -> convert to new format) was that the old format creation was already faulty, as shown by the flag value 1 instead of 3 in the SURFTILELIST line. I think if he fixes this, it will work out.

So the flow would be:

• Create your base with high-res tiles
• Add an alpha layer in the high-res tiles
• Ensure that flag value 3 is set in SURFTILELIST
• Optionally check with Orbiter2010 if base shows up properly
• Do the treeman-dance (like shown in the first post here)
• Delete the SURFTILELIST section from the base config again
• Check in Orbiter2016

No other tree operation should be needed for a 2010 to 2016 base conversion. Of course the elevation data is a different story, as already described above.

 

[Notebook]

Thanks Face, that makes things a lot clearer.

I'm tempted to have a go myself!

 

[Aviator1280]

Delete the SURFTILELIST section from the base config again

Cool, I will try like this. 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?

 

[Aviator1280]

Thanks Face, that makes things a lot clearer.

I'm tempted to have a go myself!

You should try