Problem Very high resolution texture conversion problems.

galleto

Member
Joined
Feb 24, 2017
Messages
35
Reaction score
73
Points
18
Hi, I'm trying to make a cloud map for the earth out of a 43200X21600 texture, and afaik first I have to convert it to a .tex file, and then convert that to a .tree file.
The problem is that the pltex converter for whatever reason only accepts .bmp images, which seem to have a limit of 30000X30000 pixels so whenever I try to convert my raw file to a 43200X21600 bmp it just makes a corrupt mess (I have tried irfanview, gimp and photoshop).
Then I found out that there is another program, texbuild that accepts other formats but it crashes before finishing:

Building .tex...
Traceback (most recent call last):
File "texbuild.py", line 239, in <module>

File "texbuild.py", line 186, in main
buildtex(outfn, fmt, level)
File "texbuild.py", line 231, in buildtex
tmpfile.close()
IOError: [Errno 2] No such file or directory: 'out\\dds\\tex_0.dds'


and besides it only seems to reach level 8 mipmaping so that does not really suit me.

So I guess my question is, how can I convert my image to a .tree file readable by orbiter 2016 with the maximum tile level available?

thx.
 

Donamy

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Oct 16, 2007
Messages
6,910
Reaction score
206
Points
138
Location
Cape
I believe Orbiter only accepts square textures, although I could be wrong.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,917
Reaction score
2,921
Points
188
Website
github.com
I think the sides must be a power of 2.
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk
A couple of things:

* use of pltex is no longer recommended, since it produces the outdated .tex format. It is better to use plsplit64 instead, which generates the current quad-tree texture format. You mentioned that you planned to convert .tex to .tree. Is there actually a tool that does that?

* the input image files must be a power of 2. If it isn't, you have to interpolate up or down using your favourite image processing program.

* For global coverage, the source image must be twice as wide as it is high (except for levels 1-3, see below). with a longitude range of -180 (left edge) to +180 (right edge) and latitude range from -90 (bottom edge) to +90 (top edge).

* BMP does indeed have a limit of 30000 x 30000. Even if you find an image processing tool that generates BMP beyond that, it isn't standard and won't be properly processed by pltex or plsplit64.

* To solve this, you have to split the source image into subimages (just two in your case - western and eastern hemisphere) and process them separately. Both pltex and plsplit64 can do that.

* If you use plsplit64, it involves slightly more work
- you need to generate interpolated source images for each resolution level from 1 up to the max resolution supported by your source file. In your case, this involves

Level 1: 128 x 128
Level 2: 256 x 256
Level 3: 512 x 512
Level 4: 1024 x 512
Level 5: 2048 x 1024
Level 6: 4096 x 2048
Level 7: 8192 x 4096
Level 8: 16384 x 8192
Level 9: 32768 x 16384

plus level 10 if you decide to interpolate up from your source image.

- plsplit64 then needs to be run for each of these resolution levels, providing the correct interpolated image. For Level 9, you will have to split the image into 2 parts and process both of them, providing the correct boundaries in the command line parameters. If you process Level 10, you will have to split the image into 4x2 sub-images and process all of them.

- plsplit64 generates the quadtree in a directory structure with a separate file for each tile. If you want to compress it into a single .tree file, use the texpack utility.

More detail may be found in Doc\PlanetTexures.pdf.


Edit:

So much for the basics. Now for the interesting stuff: For cloud maps, it might be worth trying to implement an adaptive resolution approach. While there will be areas with high detail that benefit from high resolution textures, it will be wasted in other areas. In particular for large cloudless regions there is obviously no reason to subdivide a node further if the parent is already entirely transparent. Similar for large uniformly cloud-covered areas.

So you could try the following: generate the entire quadtree up to resolution 10. Then do an FFT of each of the highest resolution tiles. If their high-frequency content is below a given threshold, delete that tile. If all four children of a parent node are deleted, recursively process the parent as well. This way you would get a cloud texture map that retains all the interesting high-resolution bits, but saves significantly on file size. A cool project or what?
 

galleto

Member
Joined
Feb 24, 2017
Messages
35
Reaction score
73
Points
18
A couple of things:

* use of pltex is no longer recommended, since it produces the outdated .tex format. It is better to use plsplit64 instead, which generates the current quad-tree texture format. You mentioned that you planned to convert .tex to .tree. Is there actually a tool that does that?

* the input image files must be a power of 2. If it isn't, you have to interpolate up or down using your favourite image processing program.

* For global coverage, the source image must be twice as wide as it is high (except for levels 1-3, see below). with a longitude range of -180 (left edge) to +180 (right edge) and latitude range from -90 (bottom edge) to +90 (top edge).

* BMP does indeed have a limit of 30000 x 30000. Even if you find an image processing tool that generates BMP beyond that, it isn't standard and won't be properly processed by pltex or plsplit64.

* To solve this, you have to split the source image into subimages (just two in your case - western and eastern hemisphere) and process them separately. Both pltex and plsplit64 can do that.

* If you use plsplit64, it involves slightly more work
- you need to generate interpolated source images for each resolution level from 1 up to the max resolution supported by your source file. In your case, this involves

Level 1: 128 x 128
Level 2: 256 x 256
Level 3: 512 x 512
Level 4: 1024 x 512
Level 5: 2048 x 1024
Level 6: 4096 x 2048
Level 7: 8192 x 4096
Level 8: 16384 x 8192
Level 9: 32768 x 16384

plus level 10 if you decide to interpolate up from your source image.

- plsplit64 then needs to be run for each of these resolution levels, providing the correct interpolated image. For Level 9, you will have to split the image into 2 parts and process both of them, providing the correct boundaries in the command line parameters. If you process Level 10, you will have to split the image into 4x2 sub-images and process all of them.

- plsplit64 generates the quadtree in a directory structure with a separate file for each tile. If you want to compress it into a single .tree file, use the texpack utility.

More detail may be found in Doc\PlanetTexures.pdf.


Edit:

So much for the basics. Now for the interesting stuff: For cloud maps, it might be worth trying to implement an adaptive resolution approach. While there will be areas with high detail that benefit from high resolution textures, it will be wasted in other areas. In particular for large cloudless regions there is obviously no reason to subdivide a node further if the parent is already entirely transparent. Similar for large uniformly cloud-covered areas.

So you could try the following: generate the entire quadtree up to resolution 10. Then do an FFT of each of the highest resolution tiles. If their high-frequency content is below a given threshold, delete that tile. If all four children of a parent node are deleted, recursively process the parent as well. This way you would get a cloud texture map that retains all the interesting high-resolution bits, but saves significantly on file size. A cool project or what?

Yes, the map I wanted to generate for orbiter 2016 is a global cloud map, I forgot to mention that. It is basically NASA's next gen blue marble but corrected and filtered in photoshop so it looks more detailed up close. I have the cylindrical projection in double wide than tall, so scaling it to powers of 2 won't be a problem.
Another thing is that I didn't know of the plsplit 64 tool (I need to read the documentation in detail), I was trying to use the treeman tool I found in another post so it should be easier this way.
The FFT definitely sounds worth the time, I don't really have the skills to automatize that but maybe I can select the mostly empty ones with an action in photoshop and remove them.

Thank you for the detailed response, i'll see what results I get.
 
Top