A Question about Textures and 0.20 - blurring

[TriggerAu]

Hi, In the Kerbal Alarm Clock I use a number of png's as textures for buttons. I noticed in the change the 0.20 and above that there appears to be some graphical blurring occuring in the textures. I have narrowed it down to the way the textures are loaded and have the below.

• I used to load the textures by reading the png contents to a Byte array and then using the Texture2D.LoadImage() function with the Byte Array
  
• When I use the pngs as loaded by the GameDatabase using GameDatabase.Instance.GetTexture("Texture1",false) I can see blurring occuring of the texture even when the game is set at the highest settings
  

* Easier to see if you zoom in a bit, particularly on the left most image and the DN arrow.

Does anybody have any idea about why this is occuring and if there is a way for me to get "unaffected" Textures to use for Buttons? (The pngs are all 24bit color, and pretty small)

[MOARdV]

Does anybody have any idea about why this is occuring and if there is a way for me to get "unaffected" Textures to use for Buttons? (The pngs are all 24bit color, and pretty small)

My first impression is that it's a quantization artifact, possibly caused by converting the RGBA32 image to a DXT5 compressed format. DXT5 doesn't handle continuous tones, nor sharp edge transitions, particularly well, and its artifacts tend to show up in 4x4 grids, since that's what it uses for quantization. It might be with the new asset loader, Squad is loading the image and handing it to Unity to convert to a compressed format. That could also explain some of the higher memory usage that's been reported, if there's a memory leak in there. As for getting around it, that I don't know. I've never used Unity.

[John FX]

My first impression is that it's a quantization artifact, possibly caused by converting the RGBA32 image to a DXT5 compressed format. DXT5 doesn't handle continuous tones, nor sharp edge transitions, particularly well, and its artifacts tend to show up in 4x4 grids, since that's what it uses for quantization. It might be with the new asset loader, Squad is loading the image and handing it to Unity to convert to a compressed format. That could also explain some of the higher memory usage that's been reported, if there's a memory leak in there. As for getting around it, that I don't know. I've never used Unity.

Sounds logical. Seems to me that the test for that would be to convert some PNG to the format used and see if they still get altered once loaded. I also do not know Unity.

Anyone with more knowledge have any ideas?

[MOARdV]

Sounds logical. Seems to me that the test for that would be to convert some PNG to the format used and see if they still get altered once loaded. I also do not know Unity.

I ran img_iconPauseEffect_100.png through Microsoft's texconv utility to convert it to DXT5 (BC3_UNORM) and back to PNG, and the results are pretty close to identical to what Trigger Au sees (I don't have a drop box to post the image, or I'd include it). It's an artifact of DXT5 texture compression.

[TriggerAu]

Thanks for the thoughts/tests, I hadn't thought of Compression

So basically the way the new loader is converting the files to textures adds some compression, and without any way to control that I'll need to go back to the previous method.

Sound right?

[MOARdV]

So basically the way the new loader is converting the files to textures adds some compression, and without any way to control that I'll need to go back to the previous method.

Sound right?

Pretty much. If the current asset loader system automatically converts each image to a DXT format (which is what it looks like), you're going to have artifacts on your icons. If the old method still works, you might want to do that for the UI icons.

I don't know if devs look at threads like this, but if they do: I'd suggest "small" textures (say, 64x64 or smaller) be stored as uncompressed RGBA32 format, instead of DXT compressed. If the texture is that small, you gain very little by compressing it, and, if it's a UI component like these are, the quality loss is substantial, and the memory cost is pretty small: RGBA32 64x64 textures use 16k, while DXT5 64x64 uses 4k (or 5k for a full mipchain) for the same data.