Texturing Format Information (Modders Please Read!)

[rbray89]

So I have been seeing a LOT of misinformation on the forums regarding how KSP currently (.23) handles textures/formats.

PNGs:

PNGs are compressed in memory, resulting in smaller, but (barely noticable) lower quality textures in-game. Mipmaps are NOT generated for these, so when viewed at a distance, they tend to "shimmer"

TGAs:

TGAs are NOT compressed in memory, resulting in huge image size. Mipmaps ARE generated, so they don't have the same problem as PNGs.

MBMs:

MBMs MAY be compressed, but only if the texture type is set to regular texture. Normal maps are not compressed, to preserve correct normals. Mipmaps are generated regardless. MBMs cannot be read in-game due to the texture importing setting Squad uses.

As you can see, there is a LOT of inconsistency in the texture loading Squad has implemented. By design or not, I couldn't tell you, but when modding, choose what works best for you.

Happy Texturing!

[Greys]

Made a chart!

<snip> (replaced in later post)

So funny story; KSP will automatically load jpgs, but don't tell anyone because there is literally no reason to use them

PS; there have been several glitches relating to PNGs being loaded incorrectly and it causing them to take up substantially more memory than they deserve; do you know if any of these are in effect for 0.22 and 0.23? 0.23 has an updated version of Unity and I know some of the glitches were Unity's fault so hopefully they've been eliminated.

Edited December 21, 2013 by Greys

[rbray89]

Made a chart!

http://i.imgur.com/sWTxfYu.png

So funny story; KSP will automatically load jpgs, but don't tell anyone because there is literally no reason to use them

PS; there have been several glitches relating to PNGs being loaded incorrectly and it causing them to take up substantially more memory than they deserve; do you know if any of these are in effect for 0.22 and 0.23? 0.23 has an updated version of Unity and I know some of the glitches were Unity's fault so hopefully they've been eliminated.

I think it could be related to compression scheme... I noticed that some normal maps were not compressed, though I can't find out why (KW rocketry I think has a few normal maps that don't compress)

TGAs CAN take up just as much space as MBM, but nut usually when run-line compressed.

[rbray89]

Also, TGA are not lossy. Same format as MBM almost. If anything, in-game TGAs would result in the best quality.

[blizzy78]

PNGs are compressed in memory, resulting in smaller, but (barely noticable) lower quality textures in-game.

Not as barely as I would like. For example, see the following picture:

At the bottom edge of the golden "toast" texture, you can see that there is a clearly noticeable line just breaking. And this is a scaled down version of the original screenshot. While the original PNG file is correct when viewed in any image viewer, it does show up like that in KSP. It does not happen with TGA.

[NathanKell]

Correction: Texel called BS on my PNG info (s/he had looked into it more than I) and I looked again to confirm. It turns out that it appears that only PNGs specifically flagged as UI textures internally (via Unity export), like flags, get no mipmaps. Normal PNGs (like the ones used in B9) do appear to get mipmaps. My apologies for spreading disinformation.

They do, however, get compressed to DXT, which is essentially a 16bit-color format, hence why you (blizzy) get artifacts. This is why, for example, reducing the resolution of a normal map but keeping it non-DXT results in higher quality than keeping it the same resolution but DXT compressing it.

Thus I eagerly await the next version of your tool, rbray, which hopefully then can be configured to resize rather than compress "do-not-compress"-flagged MBMs.

I suggest, since MBM are relatively easily editable, that unless anyone has a compelling reason to use a different format they should use MBM, as that format (1) allows a "compress/don't-compress" flag, and (2) does not have leaks or other issues in loading.

Greys: Yes, Unity reads JPGs. I too have avoided mentioning that previously in order to not encourage anyone silly enough to use one. :}

[rbray89]

Correction: Texel called BS on my PNG info (s/he had looked into it more than I) and I looked again to confirm. It turns out that it appears that only PNGs specifically flagged as UI textures internally (via Unity export), like flags, get no mipmaps. Normal PNGs (like the ones used in B9) do appear to get mipmaps. My apologies for spreading disinformation.

They do, however, get compressed to DXT, which is essentially a 16bit-color format, hence why you (blizzy) get artifacts. This is why, for example, reducing the resolution of a normal map but keeping it non-DXT results in higher quality than keeping it the same resolution but DXT compressing it.

Thus I eagerly await the next version of your tool, rbray, which hopefully then can be configured to resize rather than compress "do-not-compress"-flagged MBMs.

I suggest, since MBM are relatively easily editable, that unless anyone has a compelling reason to use a different format they should use MBM, as that format (1) allows a "compress/don't-compress" flag, and (2) does not have leaks or other issues in loading.

Greys: Yes, Unity reads JPGs. I too have avoided mentioning that previously in order to not encourage anyone silly enough to use one. :}

Last I checked, No PNGs AT ALL were given Mip-maps. I used KW as a benchmark. You can check the results out here: KW and B9 are used for reference.

https://drive.google.com/file/d/0B1BU16LO_gj3aDYzSXFFaEl5UVU/edit?usp=sharing

[hoojiwana]

I have to wonder how applicable much of this is now that 0.23 is out, especially the memory usage.

Correction: Texel called BS on my PNG info (s/he had looked into it more than I) and I looked again to confirm. It turns out that it appears that only PNGs specifically flagged as UI textures internally (via Unity export), like flags, get no mipmaps. Normal PNGs (like the ones used in B9) do appear to get mipmaps. My apologies for spreading disinformation.

They do, however, get compressed to DXT, which is essentially a 16bit-color format, hence why you (blizzy) get artifacts. This is why, for example, reducing the resolution of a normal map but keeping it non-DXT results in higher quality than keeping it the same resolution but DXT compressing it.

This one of my older parts that I was using to compare TGA to PNG, and to show the oddness that PNGs can display. The warning label on this isn't the best example, but my parts generally lack hard lines so this was essentially the only thing I could use. Whatever causes this is much more apparent on B9 aerospace parts (before Bac9 switched to using TGA).

Edited December 20, 2013 by hoojiwana

[rbray89]

I have to wonder how applicable much of this is now that 0.23 is out, especially the memory usage.

http://i.imgur.com/YwaFalw.png

This one of my older parts that I was using to compare TGA to PNG, and to show the oddness that PNGs can display. The warning label on this isn't the best example, but my parts generally lack hard lines anyway, whatever causes this is much more apparently on B9 aerospace parts (before the switch to TGA).

If you zoom up close does it get better? This is likely due to the Mipmap issue. When they aren't generated, the graphics card has to try and do pixel sampling on a large texture, and it usually sucks, as it just picks the closest pixel, whereas in a mipmap, the texture is resized and filtered so the graphics doesn't have to do this single pixel sample.

[hoojiwana]

If you zoom up close does it get better? This is likely due to the Mipmap issue. When they aren't generated, the graphics card has to try and do pixel sampling on a large texture, and it usually sucks, as it just picks the closest pixel, whereas in a mipmap, the texture is resized and filtered so the graphics doesn't have to do this single pixel sample.

That's exactly what I was looking to show with that picture. I should make a test cube with a grid texture on it or something to show it more clearly.

And I just double checked, the Unity settings for the texture are set to use "Texture" rather than "GUI".

[TriggerAu]

Thanks for the information, I was planning to investigate this during my holidays for my plugins so this is really timely.

So while I'm here, I've noticed that same noise in PNG files when you use the GameDB loader. In the case of small textures for plugin labels what do people think is the best way to proceed TGA's which I can easily export from PS or MBMs where I'll need to convert the PNG (I think thats right from memory)?

[Greys]

Also, TGA are not lossy. Same format as MBM almost. If anything, in-game TGAs would result in the best quality.

Ding

Sorry, at one point I misread the TGA wikipage and I keep forgetting that I've learned otherwise

Uncompressed TGAs are pretty much exactly the same as MBMs, minor differences in format and not in the jenky "Mu BitMap" header(?); but who uses those? Why use those? No reason, that's why.

Compressed TGAs are significantly larger than PNGs, in my testing I saw between 15 and 30 times larger than PNG; but PNGs are tiny most of the time; and they were still no more than one quarter the MBM version of the same file. To me, 30 times a small thing, is a lot better than 120 times; both are negligible in the few small regards that disk size matters at all. So anyways, I feel 'less small' is an appropriate vague categorization.

PS rbray, I don't really understand what to do with that log file of yours, could you explain?

PPS VI: Revenge of the PSOne: If any of the Squad developers happen to read this post. I appreciate the potential advantages that having your own image format grant; but you have to understand that currently MBMs don't offer anything over the other formats we have access to; and at the cost of easy editability MBMs just complicate things. You'd save time in the long run if you contract some beautiful peasant girl to re-export your textures in another format, dump MBM/JPG support entirely, and fix the two remaining options; might as well intentionally differentiate between them, have TGA uncompressed always, have PNG compressed always, workout MipMaps however; then we can put some things in this format and some things in the other to take advantage of the difference; since they're both compressed lossless. Textures in PNG, heightmaps in TGA? Other way around? It doesn't terribly matter.

Edited December 21, 2013 by Greys

[rbray89]

Ding

http://i.imgur.com/HZ3hF8I.png

Sorry, at one point I misread the TGA wikipage and I keep forgetting that I've learned otherwise

Uncompressed TGAs are pretty much exactly the same as MBMs, minor differences in format and not in the jenky "Mu BitMap" header(?); but who uses those? Why use those? No reason, that's why.

Compressed TGAs are significantly larger than PNGs, in my testing I saw between 15 and 30 times larger than PNG; but PNGs are tiny most of the time; and they were still no more than one quarter the MBM version of the same file. To me, 30 times a small thing, is a lot better than 120 times; both are negligible in the few small regards that disk size matters at all. So anyways, I feel 'less small' is an appropriate vague categorization.

PS rbray, I don't really understand what to do with that log file of yours, could you explain?

PPS VI: Revenge of the PSOne: If any of the Squad developers happen to read this post. I appreciate the potential advantages that having your own image format grant; but you have to understand that currently MBMs don't offer anything over the other formats we have access to; and at the cost of easy editability MBMs just complicate things. You'd save time in the long run if you contract some beautiful peasant girl to re-export your textures in another format, dump MBM/JPG support entirely, and fix the two remaining options; might as well intentionally differentiate between them, have TGA uncompressed always, have PNG compressed always, workout MipMaps however; then we can put some things in this format and some things in the other to take advantage of the difference; since they're both compressed lossless. Textures in PNG, heightmaps in TGA? Other way around? It doesn't terribly matter.

The MBMs do offer one thing, that is the normal map flag. That is about it.

[WinkAllKerb'']

very interesting i keep using png for testing/readability tuto purpose for now but will follow how all this evolve thanks to you all for thoose explains.

[swamp_ig]

Is there any way of co-opting anything apart from MBM to work as a normal map? Doesn't seem like it to me.

[rbray89]

Is there any way of co-opting anything apart from MBM to work as a normal map? Doesn't seem like it to me.

If you use the unity KSP tool it will export it automatically I think. The file should be named something_NRM.png

[SpannerMonkey(smce)]

I have been remiss in not noticing this info before, although not about texture type I have a question about resolution, What ppm(pixels per mm) or ppi (pixels per inch) are recommended as this affects or seems to affect loading times as well?

cheers in advance

[rbray89]

I have been remiss in not noticing this info before, although not about texture type I have a question about resolution, What ppm(pixels per mm) or ppi (pixels per inch) are recommended as this affects or seems to affect loading times as well?

cheers in advance

Ummm... ppm and ppi actually don't have any context (as you need a physical display surface to make sense of that info), rather you should be concerned of raw pixel dimension (ie. 512x512 px). Obviously, you will just want to try different sizes to see what works best for you. MBM and TGA will load the slowest, PNG being compressed should load the fastest.

One caveat is that you will want to use 2^n square texture sizes. (16x16, 32x32, 64x64, 128x128, 256x256, 512x512, etc) to use memory the most efficiently.

[blizzy78]

Is it a bad idea to use textures such as 2048x1024? I've seen that in KSP mods, too.

[rbray89]

Is it a bad idea to use textures such as 2048x1024? I've seen that in KSP mods, too.

(Haha mine?) It is less than ideal. If you do that, Unity automatically fills the remaining 2048x1024 with useless pixels. So while it isn't "bad" it isn't really great either.

[NathanKell]

Wait wut? I thought it only did it for NPOT textures, not power-of-two but not-square textures.

[rbray89]

Wait wut? I thought it only did it for NPOT textures, not power-of-two but not-square textures.

From what I was reading in unity, the textures also need to be square to avoid automatic re-sizing.

[xEvilReeperx]

From what I was reading in unity, the textures also need to be square to avoid automatic re-sizing.

They just need to have power-of-two sides

Texture Sizes

Ideally texture sizes should be powers of two on the sides. These sizes are as follows: 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048 etc. pixels. The textures do not have to be square, i.e. width can be different from height. Note that each platform may impose maximum texture sizes.

[rbray89]

They just need to have power-of-two sides

Ah... I think the thread I was reading must have just pertained to iOS then :

Note that PVRTC formats require textures to be square (width equal to height), therefore final size will be upscaled to 512x512.

[Faark]

They just need to have power-of-two sides

Jup. And automatic resizing seems to only occur if necessary. The directx texture behind a texture resource created by unity could have 64x20 when created with that resolution on my system. NPOT is still not recommended, ofc!

Some other details that surprised me/ i found interesting (though are directx specific):

- There is no real RGB24. A texture created with this format usually becomes D3DFMT_X8R8G8B8 with still 4 byte per pixel. Thus using RGB24 to save GPU memory doesn't make sense. Its still nice to tell unity to compress to DXT1, ofc.

- All textures i encountered so far were D3DPOOL_MANAGED. That means all of them are backed by system ram. Making them non-readable only gets rid of Unity's own backing (for editing, i suppose). Though i don't understand why textures cannot become readable again, especially when reading/writing all pixels anyway (and at least from a DirectX point of view). This also explains how unity can survive "simpler" device resets.