Project Orbiter texture tree tools (OT3)

[Face]

The Orbiter texture-tree tools project - or OT3 for short - is inspired by the release of Orbiter 2016, discussions about texture-tree manipulation during the RC-phase and an early addon request.

The idea is to extent Orbiter's /Utils/ toolset with useful programs to inspect and/or manipulate the new texture and elevation file formats. These programs should eventually be released as open-source software.

My idea is to create small programs that can be joined together to create a full-featured work-environment, similar to the Unix mindset:

• archive tree manager (treeman) as CLI tool, making it possible to selectively manage texture-tree archives and/or caches
• visual selection tool (treevis) as GUI tool, allowing users to visualize the various aspects of the new formats (textures, elevations, tree population, etc.), navigate through the tree(s), and select tiles for further processing
• elevation converter for 2D solutions (ele2png), creating compositions of texture and height-map in order to seamlessly edit both aspects in a graphics program, then converts it back to tile formats
• elevation converter for 3D solutions (ele23DS), creating terrain meshes from selected tiles to be edited in 3D programs, then converts meshes back to tiles

For the first point in the list above, there is already some progress to show: treeman . Extract the archive together with the included Microsoft texconv.exe tool (it is MIT licensed, don't worry ) into /Utils/ folder.

From the usage text:

treeman: Orbiter texture tree managing tool
  Lists, extracts, or updates the files of a packed planet texture layer directory tree.

Usage: treeman <Planet-tree-root> <Layer> [<Actions> | <Options> | <Configs>]

<Planet-tree-root>:
  Path to planet textures, e.g.
  c:\Orbiter\Textures\Earth

<Layer>:
  Surf       surface layer tiles
  Mask       water mask and night light texture tiles
  Cloud      cloud tiles
  Elev       elevation tiles
  Elev_mod   elevation modification tiles

<Actions>:
  -l         (default) lists files included in the archive
  -s         prints a summary
  -e         extracts files into planet tree root

  -i[res]    integrates files in the planet tree root into low-level tiles
             [res] is an optional single digit specifying the minimum tile resolution,
             with 2^res meaning 0=1x1, 1=2x2, 3=4x4, 4=8x8, etc. - default is 0=1x1
             supported layers: Surf, Mask, Cloud
             note: file list (-F) is mandatory, only full pathes will be checked

  -b <path\to\base\file> <path\to\textures>
             converts old style base surface tiles into planet tree root
             supported layers: Surf, Mask

  -t <path\to\tex\file>
             converts old style texture archives (*.tex) into planet tree root
             supported layers: Surf, Mask, Cloud

<Options>:
  -T <path>  tree archive file - default is <Layer>.tree in <Planet-tree-root>\Archive
  -I <rgx>   file filter include regular expression - default is include all files
  -X <rgx>   file filter exclude regular expression - default is exclude no files
  -F <path>  file list - if defined, this list defines the base file set for actions
             if no path is given, standard input is read until EOF
             entries in the list are newline separated, can use '\' or '/' as
             separator, and don't need to be full length (e.g. /04/000010 is valid)
             padding whitespace and empty lines will be removed
  -n         dry run - all file writing actions will be skipped
  -v         increase verbosity level (-vvv supported)
  -w         run stop-watch for timing information
  -y         acknowledge all questions positively
  -y0        acknowledge all questions negatively

<Configs>:
  --texconv <path>  path to texconv.exe DDS conversion tool - if not present,
                    DDS files in the wrong format will be skipped - defaults to
                    'texconv.exe', which will start the bundled version.

As of now, you can use this to:

• list the files in a *.tree archive,
• extract files by specifying regular expressions and/or file lists,
• print a summary on the contents of the archive (also use -v option to get more details),
• import old-style *.tex files into the cache (currently only up to old level 5),
• import old-style base tiles into the cache,
• integrate high-res tiles into lower levels to have seamless experience (only non-elevation tiles for now)

Planned is:

• print difference between archive and cache as status list,
• update files from cache into archive selectively,
• merge archives,
• import full-scale old-style textures,
• support integration of elevation tiles

If you want to try out base conversion, you can get the best results by converting Surf and Mask layer, as well as integrate the tiles involved back to 1x1 pixels like so:

1. treeman ..\Textures\Earth Surf -b <path_to_base_config> <path_to_textures_dir> -y > surf.txt
2. treeman ..\Textures\Earth Mask -b <path_to_base_config> <path_to_textures_dir> -y > mask.txt
3. treeman ..\Textures\Earth Surf -i -F surf.txt
4. treeman ..\Textures\Earth Mask -i -F mask.txt

Point 1 converts the base config texture tiles to the surface layer of Earth, overwriting every file that might be there already (-y) and pipes the list of files it produces to a file "surf.txt".
Point 2 does the same to the water-mask layer, piping to the file "mask.txt".
Point 3 takes the files from surf.txt and integrates them back into the texture tree (-i). Point 4 does the same for the water-mask files.

So far I've tried that with Edwards, Vandenberg, Ascension and CSSC successfully. The results are certainly not perfect, but you can get a pretty good starting point for further development with it.

A last note: if you use old base configuration files in Orbiter 2016 with converted tiles by treeman, you might have to remove the SURFACE_TILES section from the base config in order to see the converted textures. In addition, you should have the "Try cache first, then archive" setting in the "Visualisation parameters->Planet rendering options" dialog set, which should be there by default.

 

[fort]

Face hello,

I'll be brief ..There is something that i don't really understand.

treeman

...integrates files in the planet tree root into low-level tiles

With the exception of KSC, at level 19 to its central portion, and for few other places - five or six - at L16 (zone containing Baikonur eg for high resolution), all other surfaces with high-resolution start from L11 to reach L13. If in one of these areas, at level 13 for example, I create a scenery at level 16, 17, etc ( and the intermediate tiles ... L14, L15 ), does the tileedit code that I began to discover, or the one of treeman that I do not know yet, allows you to spread/propagate the information from the* .elv L13 to .elv of higher level, 14, 15 ... usefull ( usefull or not ? ) for newly created tiles ? And how, if it's the case ? By subdivision and replication/creation of the *.elv of L13 for higher levels and/or *.elv in the elv_mod folder ?

Or, and for example, does the level 13 *.elv will only be necessary to create ( support ) relief for the new upper levels ( indeed without a great precision at those higher levels ) ?

I could experiment with treeman or tileedit but if i could have an answer already for a first approach ( approche ).

thank you and good day.

 

[Face]

If in one of these areas, at level 13 for example, I create a scenery at level 16, 17, etc ( and the intermediate tiles ... L14, L15 ), does the tileedit code that I began to discover, or the one of treeman that I do not know yet, allows you to spread/propagate the information contained in the* .elv L13 to .elv of higher level, 14, 15 ... necessary for newly created tiles in 3D ? And how ? By subdivision and replication/creation of the *.elv of L13 for higher levels and/or *.elv in the elv_mod folder ?

Well, I can't speak for the tileedit code, of course. treeman in fact works in both directions, but only the high- to low-level direction is exposed directly to the user yet.

treeman uses both directions, because while converting alpha-blended base textures, it needs a texture it can blend on. Often this tile is not present, because base textures are mostly higher level. Therefore, treeman extracts the highest available tile in the tree-path, takes the appropriate pixel-range from it, and blows this smaller tile up via cubic interpolation scaling. The result is blended over with the base tile to be converted. So this is the direction you talked about, if I understood you correctly.

The inverse direction, which is exposed to the user via "-i" action takes a high-level tile, shrinks it into smaller tiles (again via cubic interpolation scaling), and integrates those tiles into the lower levels, so you have a smooth LOD transition while e.g. approaching WIA.

Or, and for example, does the level 13 *.elv will only be necessary to create ( support ) relief for the new upper levels ( indeed without a great precision at those higher levels ) ?

If I understand this right, your question is if it is necessary to provide elevation data at the same level as texture data, even if you only need the low-level terrain resolution. IMHO, the answer to this is no.

For example: I've converted Vandenberg textures at resolutions 14/15/16 and integrated them back to level 6. Although the highest resolution of available elevation data in the release distribution at this location (probably 12) is lower than 14, I see the (coarse) terrain nicely overlayed with the high-res texture.

Currently treeman does not support elevation tiles on import and integration. This is planned, but it is a bit tricky because of the padding data involved.

I hope this helps,
Face

 

[fort]

Hello,

I'm not completely a newby in that matter even if i've never released anything of that sort - sceneries - for orbiter and i understand the whole part of your explanations. But i'm not very comfortable with the english language and some things, that question of alpha blending, for example, that i've read in another topic , from you, escape a little to my understanding. I think that it's evident and in the same time i'm not sure to really visualize all that articulation.

I have to reread calmly your answer first and in it's entirety.

good day.



Edit:

If I understand this right, your question is if it is necessary to provide elevation data at the same level as texture data, even if you only need the low-level terrain resolution. IMHO, the answer to this is no.

OK. I have just made à try on KSC with that. Right. If i delete the elv from, by example, the L14 to the end ( L17 ), those in the elv folder, and the other one, for the same levels, in the elv_mod folder, the tiles are there in Orbiter with values for elevation at the max levels remaining in Orbiter and in that case level 13.

I have to understand the first part.

 

[Face]

I'm not completely a newby in that matter even if i've never released anything of that sort - sceneries - for orbiter and i understand the whole part of your explanations. But i'm not very comfortable with the english language and some things, that question of alpha blending, for example, that i've read in another topic , from you, escape a little to my understanding. I think that it's evident and in the same time i'm not sure to really visualize all that articulation.

I see. With alpha blending, I mean that old-style base texture tiles often come with an alpha channel, meaning that the texture contained transparency information. E.g. coast lines were often outlined with transparency, so the water was not overwritten by the tile, just the land part.

Orbiter 2010 then overlayed the coarse planet texture with the fine base texture tile, letting the coarse water part shine through. Of course that wasn't restricted to only coast lines, it was often done to gradually blend-in surrounding coarse land area into the finer base texture, too.

2016 changed that a bit. Now the texture is not containing transparency anymore (or better: doesn't support overlaying). So in order to convert base textures to new-style planet texture tiles, I had to do something with the alpha channel. I chose to let treeman do the overlaying in the import process, just as Orbiter 2010 did it in the past on the fly.

This overlaying process, if done in a certain way, is called alpha blending. It takes every pixel of the underlying picture, multiplies its color values with the inverse alpha channel value for that pixel, then adds the pixel of the overlayed picture, multiplied by the alpha channel value for that pixel, which results in the value for the appropriate color for the pixel in the finished picture. This perhaps complicated sounding process gets pretty simple if you visualize the alpha channel values as either 1 or 0, like with the DXT1 format. It means that for each pixel, the system just decides if it takes the value from the underlying or the overlayed picture.

Things get even a bit more confusing, if you realize that Elev_mod is almost like a DXT1 alpha channel format for elevation data. :shrug:

 

[fort]

I see. With alpha chanel...

Yes i think that i understand better. You, as you say, where talking about the alpha chanel coming sometime with surf tiles.

Yes in the 2016 edition, the alpha comes in the mask with nightlights, but the surftiles are in 32 bits when i extract the bmp from the dds. I think that is due to the processus of creation of the tiles and that that blank alpha was necessary for that. I don't know. Or something else. Or ...

Things get even a bit more confusing, if you realize that Elev_mod is almost like a DXT1 alpha channel format for elevation data. :shrug:

Yes, i read that in another topic. I've used the old Terragen a long time ago only two or three times to create a mesh if i remember...not sure. Not sure if it was Terragen. Anyway those conversion from a 2d grayscale to a 3D object, of vectors...i don't know what it is. I suppose like the data as they are in a mesh. There a DXT1. Well. It's a direct conversion ?

The inverse direction, ... LOD transition while e.g. approaching WIA.

Oui.

Last thing: i don't know if treeman in the gui version will show, for the surf, the number of the tiles and their coordinates values, but it will be maybe usefull, and in tileedit also but it's not your work, to show, for a tile, in the same time, the coordinates values as they was implemented in the 2010 version and before. I mean for example Earth_1_W0347_N0105.

Taking account of the difference of one level between the 2010 and 2016 version of orbiter if i'm not wrong (?). And on the old 2010 basis of 256 px by cell ( if i'm not wrong ) ? That makes a lot of thing to consider at the same time but maybe simpler that i think.

Good day and thank you again.

 

[jacquesmomo]

Last thing: i don't know if treeman in the gui version will show, for the surf, the number of the tiles and their coordinates values, but it will be maybe usefull, and in tileedit also but it's not your work, to show, for a tile, in the same time, the coordinates values as they was implemented in the 2010 version and before. I mean for example Earth_1_W0347_N0105.

Yes, this would be a good idea ...:tiphat:

 

[Face]

Yes in the 2016 edition, the alpha comes in the mask with nightlights, but the surftiles are in 32 bits when i extract the bmp from the dds. I think that is due to the processus of creation of the tiles and that that blank alpha was necessary for that.

If you convert DXT1/3/5 with alpha channels to BMP, it will sure get lost, because BMP does not support alpha channels. For this reason, I use PNG internally, which supports alpha channels.

Yes, i read that in another topic. I've used the old Terragen a long time ago only two or three times to create a mesh if i remember...not sure. Not sure if it was Terragen. Anyway those conversion from a 2d grayscale to a 3D object, of vectors...i don't know what it is. I suppose like the data as they are in a mesh. There a DXT1. Well. It's a direct conversion ?

I think you mean tessellation. It's where you take the plane and subdivide it into more and more triangles, using the texture data to offset the triangle points in height. The result would be a 3D terrain mesh of the 2D height-map.

Last thing: i don't know if treeman in the gui version will show, for the surf, the number of the tiles and their coordinates values, but it will be maybe usefull, and in tileedit also but it's not your work, to show, for a tile, in the same time, the coordinates values as they was implemented in the 2010 version and before. I mean for example Earth_1_W0347_N0105.

I didn't think about the GUI component of OT3 (treevis) that much yet, but I'll keep that in mind. The coordinate transformation between lat/lon/resolution, old-style level-bands and new-style level-bands is not that complicated, treeman is doing that already to convert old-style base textures to tiles.

 

[fort]

Hello,

I made a point of some aspects in relation to the textures of the device used in 2010p1 version with regards for surftiles coming as addon - i mean, out of *tex files - (noted Earth_0_n xxxx_e xxxx for example), with respect to the new system, with level folders and sub dds files (or * .tree files in the archive folder), of the 2016 release.

I redid a general picture, surely too detailed of equivalence between 2010p1 and surftiles for 2010p1 version and equivalence between 2010p1 and 2016.

[URL=http://ww

A surftile eg Earth_0_n0012_e0032, so of level 0, corresponds to an overall level of 12 in 2010p1.

The number of cells in latitude and longitude, at the level 11 of the 2016 version is equivalent to the number of cells at level 12 of the version 2010p1. But those of the version 2016, starting from the level 3, included, contain 512 pixels, while those of the 2010p1 release contain only 256.

Suppose, to take a simple example, I created a scene with a unique surftile for 2010p1, at level 0, a cell containing 256px x 256px.

How is reinstated this image/dds in the tree of the 2016 release ( how treeman do it ) ? A resize is certainly necessary (?).Does Orbiter itself do it ? And does the tile is reintegrated at L-1, level 10 here, for example or the opposite, L12 ( for angular equivalence ) ? I have not really pushed my reflexion on that last question.

good day

Edit:

First question answered (Is a resize necessary ?): Orbiter, resize it. And the answer for the second is i think: the tile is reintegrated at level 12.

Edit2: I redid the table of equivalences in a more comprehensible presentation ( i hope ).

Edit3 (02/10): modified some comments in the table.

Edit4 (12/11): added comments in the table.

 

[fort]

Hello

I want to see how treeman works trying with a simple surf tile. I put it in a base.cfg but i wanted first try to " integrate a high-res tiles into lower levels..." not particulary included in a base.

I must be wrong somewhere:

My command line:
E:\ESSAI>treeman e:\ESSAI\Textures\Earth Surf -i -b e:\ESSAI\Config\Earth\Base\Orlando.cfg e:\ESSAI\Textures2\Earth_4_W1852_N649.dds

Result:
E:\ESSAI>treeman e:\ESSAI\Textures\Earth Surf -i -b e:\ESSAI\Config\Earth\Base\Orlando.cfg e:\ESSAI\Textures2\Earth_4_W1852_N649.dds
/16/001398/002244.dds
error: unable to open file e:\ESSAI\Textures2\Earth_4_W1852_N649.dds\Earth_4_w1852_n0649.dds, error 3



BASE-V2.0
Name = Orlando
Location = -81.383160 28.535231
Size = 1000
ObjectSize = 100
MAPOBJECTSTOSPHERE = TRUE

BEGIN_NAVBEACON
END_NAVBEACON

BEGIN_OBJECTLIST
END_OBJECTLIST

BEGIN_SURFTILELIST
4 -1852 649 1
END_SURFTILELIST

Do i need -i or is it -b or an error with the path or the syntax ( do i need the <...> ) or does the dds must be in the Textures folder and not in the Textures2, or something else ?

Except the last thing: Textures versus Textures2 ... i tried different things/scriptings without success. Sometimes with an error2 sometimes like here with an error3.

I must reread your instructions for sure.

good day

 

[Face]

I want to see how treeman works trying with a simple surf tile. I put it in a base.cfg but i wanted first try to " integrate a high-res tiles into lower levels..." not particulary included in a base.

I must be wrong somewhere:

My command line:
E:\ESSAI>treeman e:\ESSAI\Textures\Earth Surf -i -b e:\ESSAI\Config\Earth\Base\Orlando.cfg e:\ESSAI\Textures2\Earth_4_W1852_N649.dds

For conversion AND integration, you would have to do two calls. First the base conversion call, piping files into a text file:

E:\ESSAI>treeman e:\ESSAI\Textures\Earth Surf -b e:\ESSAI\Config\Earth\Base\Orlando.cfg e:\ESSAI\Textures2 -y > surf.txt

Note how there's no '-i', but a '-y'. The former is missing because you can't do two action at once currently, the last action will always win. The later is because the system might ask for user input, if the file to be converted is already present, so this option quietly acknowledges it.
Second, the integration call, using the text file as input list to integrate the tile(s) upwards:

E:\ESSAI>treeman e:\ESSAI\Textures\Earth Surf -i -F surf.txt

 

[fort]

Hello and thank you for your answer,

With the first command line:

treeman e:\ESSAI\Textures\Earth Surf -b e:\ESSAI\Config\Earth\Base\Orlando.cfg e:\ESSAI\Textures2 -y > surf.txt

i obtain a surf.txt file containing:
/16/001398/002244.dds
error: unable to open file e:\ESSAI\Textures2\Earth_4_w1852_n0649.dds, error 2

At first my Earth_4_w1852_n649.dds was 512x 512 px ( for my convenience unicolor, red ) without mip and dxt5.

After my failures during my first trys i've converted it ( dxtbmp ) to dxt1 and resized it to 256 x 256.

I tried also with Earth_4_w1852_n649.dds in Textures and in Textures2.


Something else:

The first command line is supposed to create a dds ? With the new denomination ( 002244.dds ) ?

The second command line is supposed to integrate the dds and it's low level in the surf.tree or in the simple/basic cache ?

There is certainly something that i don't understand.

good day.

Edit 1:

first error from me: my dds was named
Earth_4_w1852_n649.dds .
If i rename it
Earth_4_w1852_n0649.dds

There is a change but the surf.txt now is:

/16/001398/002244.dds
error 193: can't execute '"texconv.exe" "e:\ESSAI\Textures2\Earth_4_w1852_n0649.dds" -w 512 -h 512 -m 1 -f BC1_UNORM -o "e:\ESSAI\Textures\Earth\Surf\16\001398" -nologo'
please check paths

Treeman and texconv.exe are actually at the root of Orbiter - named ESSAI - but without anything else in it than config and textures folder.


Edit::shrug::beathead::suicide:texconv.exe is not a 32 bits application valide !

 

[Face]

Suppose, to take a simple example, I created a scene with a unique surftile for 2010p1, at level 0, a cell containing 256px x 256px.

How is reinstated this image/dds in the tree of the 2016 release ( how treeman do it ) ? A resize is certainly necessary (?).Does Orbiter itself do it ? And does the tile is reintegrated at L-1, level 10 here, for example or the opposite, L12 ( for angular equivalence ) ?

If you have an entry for a surftile in a base configuration, treeman will calculate the appropriate 2010P1 name and find it in the given texture path. It will then resize/recode the tile to the appropriate layer's format (Surf 512x512 DXT1 no alpha, Mask 512x512 DXT1 1-bit alpha). Resizing/Recoding is done via Microsoft's texconv.exe tool. The resulting file will be placed in the tree by means of Martin's publicized formulas.

 

[fort]

Hello Face,

I've added comments to my previous post. At the end: texconv.exe is not a win 32 bits application valid...

But anyway...

1) On a 64 bits OS treeman resize my dds with the right new name and put it in the right cache folder. Not in the archive/surf.tree. I'm i right on that ?

Do i have to create by myself all the previous levels as for the highest ( for example for a level 16, the levels 15, then 14, then 13 ) or does treeman do it ?

I think that i have the answer but...

thank you.

 

[Face]

The first command line is supposed to create a dds ? With the new denomination ( 002244.dds ) ?

The second command line is supposed to integrate the dds and it's low level in the surf.tree or in the simple/basic cache ?

The first command line takes a base configuration file and import all listed tiles into the file system cache. The second command takes a file list - which should be file system cache paths - and for each of them it integrates the tile into low-level tiles taken from the *.tree archive, and saves them in the file system cache, not the surf.tree file. ATM, treeman does not change the tree files.

first error from me: my dds was named
Earth_4_w1852_n649.dds .
If i rename it
Earth_4_w1852_n0649.dds

Interesting. If Orbiter2010P1 supported this non-zero-filled format, treeman should of course support it, too. Did you try that naming scheme in 2010P1?

There is a change but the surf.txt now is:

/16/001398/002244.dds
error 193: can't execute '"texconv.exe" "e:\ESSAI\Textures2\Earth_4_w1852_n0649.dds" -w 512 -h 512 -m 1 -f BC1_UNORM -o "e:\ESSAI\Textures\Earth\Surf\16\001398" -nologo'
please check paths

Treeman and texconv.exe are actually at the root of Orbiter - named ESSAI - but without anything else in it than config and textures folder.

Error 193 is this:

ERROR_BAD_EXE_FORMAT 193 (0xC1) %1 is not a valid Win32 application.

However, according to the PE header texconv.exe is a 32-Bit tool. Perhaps there is some path issue, try to explicitly set the texconv path by means of adding the configuration "--texconv <path/to/texconv.exe>" to your calls.

---------- Post added at 14:04 ---------- Previous post was at 13:54 ----------

I've added comments to my previous post. At the end: texconv.exe is not a win 32 bits application valid...

I've also tried it on a 32-bit machine now, and indeed the texconv.exe is not working there, although the signature is 32-bit. I will dig for a 32-bit build.

On a 64 bits OS treeman resize my dds with the right new name and put it in the right cache folder. Not in the archive/surf.tree. I'm i right on that ?

Exactly. It puts it in the file system cache, not in the tree archive.

Do i have to create by myself all the previous levels as for the highest ( for example for a level 16, the levels 15, then 14, then 13 ) or does treeman do it ?

If you have level 16, treeman can integrate them back to 15,14,13,etc. for you with the -i option.

 

[fort]

... and for each of them it integrates the tile into low-level tiles taken from the *.tree archive, and saves them in the file system cache, not the surf.tree file.

I'm not sure that i understand if for example my initial level 16 finished as a low level or not, but i'll try to experiment by myself; i don't want to help you each minutes for things that i could maybe solve by myself. But thank you again for your help.

Interesting. If Orbiter2010P1 supported this non-zero-filled format, treeman should of course support it, too. Did you try that naming scheme in 2010P1?

By the fact, i don't know. I made quickly, from an airport ( Mojave ), a cfg for my tile and give it the right coordinates for Orlando. But the abscence of the 0 in the north range for the dds is an error from me . Maybe coming from the fact that in the cfg file there was no 0 ( 629 and not 0629 ). I've not made bases since a long time and all that notations are not actually in my head.

This does n't mean that orbiter 2010 cant work with short notations ( 629 for 0629 ) but i don't remember to have seen that in the past. I'll try .
[/QUOTE]

Error 193 is this:
However, according to the PE header texconv.exe is a 32-Bit tool. Perhaps there is some path issue, try to explicitly set the texconv path by means of adding the configuration "--texconv <path/to/texconv.exe>" to your calls.

I'll try, but. My system is 32 bit, if nevertheless, i've another system 64 bits on another drive.

"Texconv is not a win 32"...appear in a window when i click on it. Exactly as tileedit.exe.

Looking on internet to see if it was possible to download a texconv.exe 32 bits there was a page offering two versions for the exe: a 32 bits and a 64 bits. Simultaneously in my memory was an addon made by Tofitouf, Zorglub moon, with an util folder with texconv.exe.

If i click on it it open and close immediately. If i start from a cmd windows it open with it's menu.

I've no conclusions for the moment about that. I must made some experiment. But the fact is that they react differently.

I'll give you all my informations about all that points later.

And again, thank you.

---------- Post added at 12:33 PM ---------- Previous post was at 12:24 PM ----------

If you have level 16, treeman can integrate them back to 15,14,13,etc. for you with the -i option.

This answer close one of my questions about low-levels. But i'm curious to see how this works. I turn and turn this im my mind and i don't see how this can be made so simply ( apparently so simply ).

good day.

 

[Face]

By the fact, i don't know. I made quickly, from an airport ( Mojave ), a cfg for my tile and give it the right coordinates for Orlando. But the abscence of the 0 in the north range for the dds is an error from me . Maybe coming from the fact that in the cfg file there was no 0 ( 629 and not 0629 ). I've not made bases since a long time and all that notations are not actually in my head.

This does n't mean that orbiter 2010 cant work with short notations ( 629 for 0629 ) but i don't remember to have seen that in the past. I'll try .

My question was because in Orbiter's documentation, the following is noted: emphasis mine

<Surface tile list>

An optional list of high-resolution surface tiles covering the base area. Each tile is represented by a line in the list, with the format
<res> <lng-idx> <lat-idx> <flag>
where <res> is the tile resolution (integer >= 1), and <lng-idx> and <lat-idx> are the position indices. The position indices define the location of the tile on the global planet map at the given resolution. <flag> is a bitflag (bit 0 = 1: render tile; bit 1 = 1: tile contains transparency in the alpha channel).

For each tile entry, a corresponding texture file in DDS format (DXT1 or DXT5) must exist in the Textures subdirectory, with naming convention
<planet>_<res>_[W|E]<lng-idx>_[N|S]<lat-idx>.dds
where <planet> is the planet name, <res> is the tile resolution as defined in the list, and <lng-idx> and <lat-idx> are the position indices as defined in the list (zero-padded to 4 digits).

I'll give you all my informations about all that points later.

I guess I'll just go ahead and compile my own version of texconv . The project is MIT licensed, and the SDKs are available.

And again, thank you.

Valuable input is always welcome. Thanks for trying out treeman!

---------- Post added at 14:54 ---------- Previous post was at 14:44 ----------

This answer close one of my questions about low-levels. But i'm curious to see how this works. I turn and turn this im my mind and i don't see how this can be made so simply ( apparently so simply ).

treeman takes each tile of the input list. For them, it plots the path in the tree towards root. For each level in this root, it creates a tile in the file system cache (either from the tree archive, or it uses what's already there). Then it converts the tiles there to PNG and loads the PNG. It also resizes the input tile (which should be integrated) to the target resolution by means of shrinking it and converts it to PNG.
E.g. if the current step is to integrate a level 16 tile into a level 14 tile, it shrinks it from 512x512 to 128x128 with cubic interpolation.
Then treeman places this small PNG image over the appropriate pixels in the target PNG. At last the PNG is converted back to DDS.

No magic there. You can get a rather detailed work report by using the "-vv" option with the "-i" action.

 

[fort]

Then treeman places this small PNG image over the appropriate pixels in the target PNG. At last the PNG is converted back to DDS.

It's a copy past on the existing level 14 tile - in your example - and on a quarter or the quarter of a quarter - starting from the level 16 - of the level 14 and at the right place, if i undertstand. Well it's as i imaginate it but i didn't think that the procedure was that one in treeman. But what else ? There is not other possibility i think.

For the moment, i 've no time to switch to my 64 bit OS, and experiment, plus the texconv.exe 32 bits i think, from zorglub moon addon, that seems to work alone don't work with treeman.

A command line tool calling another command line tool ?

There:

 

[Face]

For the moment, i 've no time to switch to my 64 bit OS, and experiment, plus the texconv.exe 32 bits i think, from zorglub moon addon, that seems to work alone don't work with treeman.

There are various versions of texconv.exe around. treeman uses syntax/options of the Microsoft open-source project one .

A command line tool calling another command line tool ?

Yes. That's what I meant in the first post with "similar to the Unix mindset". Reading/writing/converting various DDS formats is not an easy job, so why should I use a huge library or a self-made algorithm, when the work has already been done in a tool that does that job perfectly fine?

 

[fort]

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

I ve installed recently a 64 bits os for tileedit. So i will experiment later with treeman.