koobas.hobune.stream
Texture Compression Confusion For Mobile Games
I've been doing some research for a few weeks on recommended practices for compressing textures and I've done some trial and error on my textures and I've learned a lot but I still feeling like I'm missing some key points.
1) @hippocoder Two identical .PNGs, one compressed using PNGQuant and the other uncompressed, yield the same size in the editor when added to the project. If the file sizes are drastically different on disk why does Unity say that they're the same size?
2) Is my pre-Unity PNGQuant compression just creating poorer quality images without any reduction in build or RAM size?
3) @CodeAndWeb Changing the pixel format in TexturePacker doesn't actually change the imported sprite sheets size in Unity and the compression doesn't match what was chosen in TexturePacker. Is a pixel format option other than RGBA8888 providing any benefit?
Unity re-compresses unless you choose to use to load them yourself. I would actually recommend the new crunch texture support for tiny disc storage. On a modern GPU you're at the mercy of the texture format you've chosen. If you want more control over it (2D for instance), 16 bit can be an option with dithering via https://github.com/keijiro/unity-dither4444
First off, let me thank you for actually responding. I thought it was mad creepy to tag you in a question but since I saw you were providing good info in a lot of compression threads I knew I needed your input and you didn't disappoint. Crunched worked great and it's giving me the same compression I'm seeing in the file system from PNGQuant.
Second, just to clarify so that I don't get anymore confused, by "loading them yourself" do you mean writing an editor extension to create a pipeline for importing compressed images into Unity that retain their file system compression?
Finally, another clarification, did you mean decompress ins$$anonymous$$d of re-compress?
Yes, sorry: Loading them yourself means outside of Unity's API, tools like 2D Toolkit offer this extended functionality, so you could treat the PNGs however you wanted.
And Unity will compress assets itself over your own compression that you supply. I'm glad crunched is treating you well though.
You have to distinguish between file format and runtime texture format.
PngQuant PngQuant reduces the size of the PNG file by reducing the number of colors to 256 or less. This allows better compression on the disk. The unpacked PNG file still uses the RGBA8888 color space at runtime. There's no gain in runtime memory.
Unity repacks the sprite sheets. Images treated with PngQuant might give you better compression for the final App's download size.
RGBA4444 RGB5551 and RGB565
If you use TexturePacker the following happens: TexturePacker converts the images to the 16 bit color space and applied dithering to retain the image quality.
Pngs still have to be written as 32bit images - but when you set Unity's texture format to 16bit you get the higher quality images because of the dithering.
The difference between file and runtime formats seems to be what was causing my confusion.
So, basically, one of TexturePacker's features is the same as the asset that @hippocoder referenced which includes the dithering in the file format so that when the Unity texture format is set for the corresponding compression you get better quality at runtime (e.g. less or no banding on gradients).
Now things are making a lot more sense.
So, correct me if I'm wrong, I guess what @hippocoder means by Unity compressing over my own compression is that while the file format is already compressed before being imported into the project Unity will compress the runtime texture format.
Exactly. Unity loads the .png file and depending on what you decide re-packs the file into its assets.
It looks more or less like this:
TrueColor = RGBA8888
16 Bits = RGBA4444 maybe RGB565 on opaque sprite sheets
Compressed = Hardware dependent compression like PVRTC, ETC1, DXT
I would not recommend using Compressed for sprites - at least not of you plan to deploy on iPhones (PVRTC codec). The quality will usually become too low - but this depends on your art style. It's ok for backgrounds - but usually not for high contrast sprites.
TexturePacker gives you the advantage of dithering in 16 Bits. What you'll also gain by using TexturePacker is it's new Pivot Point Editor and optimized polygon sprites (saving both: CPU + GPU).
