Hi,
I just watched the in-depth video about the new 2D system of Unity 4.3 and it looked really nice but I was really hoping to also see a solution to filesize of 2D images which generally have to be stored lossless and thus eat unholy amounts of disk space on iOS. Will there be a new builtin texture format for this?
Why would sprites, which are just textures, have a requirement to be stored uncompressed? You can use DXT or whatever else on the texture. If you want full quality sprites then either you need to use uncompressed 24-bit formats, or maybe reduce your palette to 256 colors and use an Alpha8 texture with a special shader to pull colors from a palette.
Why would a proprietary texture format work better than the public ones that already exist, like PNG?
It doesn’t make sense for them to invent their own format. People dedicated to that idea are already trying, and very few have improved on the existing stuff.
You can also use this:
I still don’t quite get what the op is asking here… for an image store file format so you can store pictures as like png’s or whatever within the built distributable project? or a texture format that takes up less run-time memory? It sort of sounds like you want to store images in a file on the iOs harddrive? Like screengrabs or extra resources outside of the built app?
In your compression settings it would be nice to store a file compressed as a PNG or JPEG and then have it automatically decompress that to an uncompressed texture through the fastest means possible.
Right now WWW.LoadImageIntoTexture is horribly slow compared to the native PNG loading capabilities of iOS.
iOS has things in it which allow you to load and decompress a 2048x1536 PNG into video ram almost instantly. It’s extremely useful, because both your images load faster, and the size of your ipa is smaller.
JPEG are smaller and better quality than DXTC
Texture compression like DXTC use algo made to be fast on GPU but not the best at quality/compression ratio.
Unity probably want to avoid people using only jpeg texture and asking the support why it’s so slow to start their game 
Its iOS thing. You don’t have DXT there only PVRTC which ruins most sprites. I’m guessing here but the OP probably means that when you set the format to uncompressed the files are saved in some unity format which takes more disc space than png or jpg style compression would and then you app size grows fast and might exceed the 50mb limit.
Then why not use PNG to store the files and load them in from a resources folder?
Hmm my last post seems to have dissappeared somehow for some reason. Anyway, loading from the resources is indeed exactly what we do.
To get an indication: our games would use 600mb+ each without using this custom loading solution. We cannot explain to our customers that a (in their eyes) simple 2D game uses that much disc space, so we have no choice.
With the solution our games are only around 50mb on disc, however:
A: it is very slow, I’m sure native loading would be much much faster
B: temporarily eats even more RAM as LoadImageIntoTexture seems to keep at least one extra copy while decompressing (meaning +20mb RAM usage for about a second which causes trouble on low RAM devices such as the iPad 1
C: eats lots of RAM as it only works on Texture2D which keeps a system copy around, calling .Apply(false,true) to clear the system copy does not seem to entirely clear the RAM as it still uses more than a regular Texture with same dimensions and bit depth
C-2: if you use Apply(false,true) Unity cannot reconstruct the texture in case the OpenGL context is lost (as happens often on Android). This context loss happens sometimes when the user suspends and resumes your game. As there is no way to detect a context loss, you have to reload all the textures everytime the game resumes.
Next to this there is also the horrible inefficiency in the pixel manipulation functions SetPixel(s) etc. which reuploads the entire texture to VRAM instead of just a rectangular area around the changed pixels making it pretty much unusable on mobile devices.
I don’t like being negative but I really feel Unity should address these issues if they intend to continue improving 2D development.
Thats an incorrect statement. PVRTC does not ruin it per se (at least not more than DXT would) unless you choose bad settings.
What ruins it is Apples command line pvrtc compressor on OSX which is still quite a joke compared to the official tools.
Unity 3.5 added support for pvr files so you can go to Imagination Technologies website, download their tool and create PVRTC textures outside of Unity and Apples tool with more control, better quality etc. Just be aware that it also can be a pain if you don’t watch what you do cause Imagination Technologies new GPUs support PVRTC2 which Apple does not support on iOS despite all but the iPhone4 and other equally old devices supporting it technically
Didn’t Unity upgrade the internal tool with the latest imagination tech tool, recently ?
Yes. Update happened in 3.5 series, and you can now select the quality setting directly from Unity. But yes, there are certain situations were PVRTC doesn’t work very well. And one big issues is that runtime PVRTC loading from web or runtime PVRTC generation isn’t possible.
Thing that most people would want is that you can choose the disc compression format (JPEG, JPEG2000, PNG, RAW, PVRTC etc.) and display format (RGB32, PVRTC, RGB16 etc.) separately, and you can also do loading filters (e.g. convert 8 bit PNG file to RGB16 with custom color conversion). Currently RGB16 isn’t very useful in Unity since build-in color conversion doesn’t handle colors very well.
PvrTexTool updated to version 2.10.87.498
http://unity3d.com/unity/whats-new/unity-3.5.2
Compression can only do so much to make files smaller, it rather depends on the type of images you’re compressing too. If you could reduce your palette down to 256 colors per sprite you could couple these with tiny palette textures so each sprite is 256 dedicated colors… then save each as 8-bit data with some kind of compression scheme similar to PNG or better (LZMA is better than GZIP, for example, especially when coupled with some better pre-filters). But then you gotta work pretty much with a limited number of colors. You wont get 24-bit color taking up minimal space at the same time as preserving full detail. But then as you say the loading and decompressing of that data is a bit slow - at least storing it as 8-bit data saves 75% of your storage requirements, and cuts down on memory overhead, and could be saved raw with no compression to speed up the loading, but you’re right Unity is still very slow at sending image data to the GPU.
I guess this is discussing exactly the same thing as another thread, so hereby I link my other reply: http://forum.unity3d.com/threads/162962-Unity-iOS-Image-Sizes?p=1353808&viewfull=1#post1353808
With regards to sprites and PVRTC 1, make sure the fully translucent parts of the textures aren’t filled with unrelated and/or random (!!!) colours. The compressor still has to try to represent the colours in areas where alpha==0, because it can’t read a developer’s mind to know what blend mode their shader will be using. FWIW, I’ve seen some truly horrendous examples in source texture data.
For example, if you have a texture with a sharp-edged green leaf, try to use a similar shade(s) of green in the adjacent, fully transparent pixels. Don’t, as I’ve seen in some examples, fill the translucent data with, say, black or, deity-forbid, magenta!
FWIW, the PVRTexTool from Imagination has a viewing mode for images which allows you to ignore the alpha channel so you can see what is normally hidden with (Src Alpha, 1-Src Alpha) blend modes.
What I would like to see in Unity and which would be helpful for this sort of thing, would be to expose the LZMA compression library to scripts so that we can do our own compressing and decompressing of data. LZMA is really nice and faster/better than GZIP. Unity has it in the editor and webplayer compression etc but to have script access would be great for fast decompression.