Planettool 0.4.2 released

[vogloblinsky]

Just trying today to convert a mercator to equirectangular image.

Is this possible with Planettool ?

[Commander McLane]

Just trying today to convert a mercator to equirectangular image.

Is this possible with Planettool?

Hi and welcome, vogloblinsky.

According to the first post of this thread the following input and output projections are supported:

Code: Select all

    --output, -o:  Type and name of output file. Type must be one of: "latlong" (l), "cube" (c), "cubex" (x), "mercator" (m), "gall-peters" (g)
     --input, -i:  Type and name of input file. Type must be one of: "latlong" (l), "cube" (c), "cubex" (x)

Mercator is not amongst the input formats. So the answer to your question appears to be "no".

[JensAyton]

Mercator isn't supported as an input projection because it doesn’t cover the whole sphere (unless it’s infinitely high). We could render the out-of-range area as transparent pixels, but the user would still have to specify the exact latitudes of the north and south cut-offs.

[Norby]

It is a very handy tool for making cube maps, thank you Jens!

I made 2048x12288 maps due to it is the minimum to do not enlarge in the game when viewing a planet from its station.
Here is a comparsion which show it is 1:1 with a small 1149x863 screen's view in game:



But FullHD monitors show planets in almost double size than this, so I need 4096 wide cubes for the best result (which still not the best for closer views than the orbit of station). I tried to make some, but without success.

In Linux rendering run up to 100% but the length of the output file is 0.

In Windows can not start but say: "Could not create a 4096 by 0 pixel pixmap."

It is a bug or is not possible to make 4096x24576 cube maps?
It is working in Mac (I can not try it)?

[JensAyton]

It works fine in my Mac.

However, the buffer needed to render at that size (using a 128-bit-per-pixel internal colour format) is over 1.6 GiB. Then it will need an additional 403 MiB to convert it to 32 bpp for the PNG file, plus space for the PNG data (40 MiB in my test of a high-res Earth texture), as well as the memory for the original image. This won’t fit in a 32-bit process.

You’ll also need 403 or 806 MiB of RAM and 403 MiB of VRAM to actually use it in game.

[Norby]

This won’t fit in a 32-bit process.

Thank you, the 64-bit version is working well under Linux.

I made comparisons to decide which resolution I should use, here is my results.
I converted a 8192x4096 texture to cube maps from 0.5k to 4k wide (left column) and take fullscreen shots in my 2048x1152 monitor viewing the planet from the station (right column).



Surprisingly my winner is the 1k wide cube due to the quality is not so better over this but the size of png about 4 times more after each step: 3.4M, 14M, 58M and 203M.

I do not know why the 2k and 4k wide cubes are not looking better in the game when the png is much better. There is a minor difference in favor of 2k than 1k if I searching it (depending on texture) which is not always worth the 4x size.

The 4k cube is absolutely not better than 2k so forgettable which is a good news for players with limited hardware.

Next I converted a larger version (16384x8192) of the same texture to 2k and 4k wide cube:



The 4k result is not better than 2k and both are near than the previous 1k so I can not get better quality using a larger source texture and 4k is still useless.

Then I tried the texture without cube conversion. First 8k, second 16k wide, and third is a special case where I make a cube without converting: I appended the 8k one 3 times to make it wider and rotated it to get a 4k cube map.




So the 8k latlong texture (upper right) give much better view from the station than anything else.

The 16k one is shrinked from this distance which result quality loss, get similar quality at about halfway between the planet and station and better is nearer only, which is not the most common situation and 8k is require less resources.

The size of my 8k wide texture is 21MB (left) and 1k wide cube is 14MB (right) but the details are nowhere near so I see no other solution to get the best quality than leave out the cube conversion.

[cim]

I do not know why the 2k and 4k wide cubes are not looking better in the game when the png is much better. There is a minor difference in favor of 2k than 1k if I searching it (depending on texture) which is not always worth the 4x size.

What's the output of glxinfo -l | grep MAX_.*SIZE on your system? It should return something like

Code: Select all

    GL_MAX_TEXTURE_SIZE = 4096
    GL_MAX_3D_TEXTURE_SIZE = 512
    GL_MAX_CUBE_MAP_TEXTURE_SIZE_ARB = 4096

[Norby]

What's the output of glxinfo -l | grep MAX_.*SIZE on your system?

Code: Select all

    GL_MAX_TEXTURE_SIZE = 8192
    GL_MAX_3D_TEXTURE_SIZE = 256
    GL_MAX_CUBE_MAP_TEXTURE_SIZE_ARB = 2048

Thank you, I guess the last line is the limit of my HD4000 and the first is why I saw a black planet only when I tried to use 16k wide latlong texture (so I needed to take my 16k screenshot above on another machine). I guess many other videocards has similar limits which is a good reason to forget 16k latlongs and 4k cubes.

I am curious if GL_MAX_TEXTURE_SIZE = 4096 is the limit of your hardware and you try to use a 8k wide latlong gal-1-Lave.png in Povray Planets then you will get a black planet in a new game after undock?

[cim]

I am curious if GL_MAX_TEXTURE_SIZE = 4096 is the limit of your hardware and you try to use a 8k wide latlong gal-1-Lave.png in Povray Planets then you will get a black planet in a new game after undock?

In theory Oolite should scale the texture down to 4096x2048 before even trying to pass it to the hardware, though that's going to take up a lot of time and memory to do the rescaling every time the texture needs to be loaded. A 16384x8192 would take up 512Mb uncompressed; scaled down to 8192x4096 for your card would be another 128Mb, plus working memory for the transformation, plus however much memory the rest of the game is taking up. That's a lot of texture to cache

I suspect the best way to get a good quality planet texture is to have a moderately large cube map (say a 1024) for the main surface, and then a bunch of smaller textures (256x256, perhaps) which add sub-pixel detail (a pair of 256s could easily add enough pseudo-random noise to the texture that it looked good even up close) to the cube map in the shader. It'd need to be a really good shader, though, and the main surface map would probably not be a conventional diffuse map: let's say "height above sea level", "rainfall", "temperature" and "population" in the four colour channels, and the shader uses those (modified by our noise textures) plus a bunch of uniforms to derive diffuse and emission colours, and the normal map.

[Diziet Sma]

I guess many other videocards has similar limits which is a good reason to forget 16k latlongs and 4k cubes.

Yep.. for instance, my laptop returns

Code: Select all

    GL_MAX_TEXTURE_SIZE = 4096
    GL_MAX_3D_TEXTURE_SIZE = 4096
    GL_MAX_CUBE_MAP_TEXTURE_SIZE_ARB = 4096
    GL_MAX_RECTANGLE_TEXTURE_SIZE_NV = 4096
    GL_MAX_RENDERBUFFER_SIZE = 4096

[Norby]

In theory Oolite should scale the texture down

Confirmed: my netbook's max. texture size is 2048 and can use the 16k latlong map, but the quality is reduced:

So the black planet is unique at my HD4000 which mean the usage of 8k maps in OXPs is safe.
Using shaders is a good idea but over my knowledge at the moment.

[Cholmondely]

To what extent is this still useful?