I remember reading a thread about someone importing PNG textures from their xcode project rather than saving them in Unity, but I cannot seem to find it. Is this indeed possible? I am particularly interested in the difference in file size from a PNG to a unity texture.
Using a PNG may have a significant negative impact on performance but if the texture quantity is minimal one could potentially set up a load screen where unity imports all the textures it will need for that level and sacrifice a little load time for a major cut in app size.
To load them from there you would need to use Texture2Ds LoadImage functionality or WWW and loading the bytes from there / using www.texture
But there is no way to really import them physically, you can only temporally load them, which is what these functions do.
And it definitely does not cut any app size, its actually even larger cause you can’t store it as compressed PVR texture this way for example, and that while being quite a bit slower.
Also there is still the bug present that textures loaded from outside take a fair bit more memory than if they were present in unity so if you intend to do it with a few 1024 textures, then you won’t go anywhere with it at all outside the iphone 4 for the time being. Fair bit in this context, going by what it was when I reported the error, is in the range of ~10 times as much memory.
There is only one scenario where it makes sense to do such a setup at all and thats if you provide publishers with the all setup and ready xcode project and allow them branding aspects for their specific needs. But really only then it makes sense in any other case its a waste of time and sacrifice of performance and resources.
Why wouldn’t it cut app size? His PNG is only 98 KB, but compressed it is 1 MB.
I’m having similar issues with my new project. I’m having to go to 16 bit to keep the image quality of my original PNG, but even compressed it is reporting much bigger sizes than the original.
Unity stores images on disk in the same format that they are stored in graphics memory. This means that loading is very fast, because there is no decompression (PVRTC decompression happens in hardware during rendering, and doesn’t change the contents of memory). The downside is that textures can take up a lot more space on disk than PNGs.
In theory, you could have Unity decompress PNG files before loading them at runtime. This would cause textures to be uncompressed in memory, so you would see 4MB for each 1024x1024 texture. This method requires that your PNG files are copied into the build by Xcode rather than processed by the Unity editor. Note that the PVRTC compressor is not included in the Unity player. You probably wouldn’t want it to be, anyway, as it would itself take up space, as well as take a very long time to compress your images.
Unfortunately, the issue dreamora mentioned would cause textures to use far more than 4MB each in memory, meaning that you would run out of memory after loading just a few such textures. I haven’t tried this on iOS, so I’m not sure what memory consumption looks like. I have tried it on PC/Mac standalone builds, but I wasn’t watching out for memory consumption there.
Yes for tool as this it can work.
But the price will be high, you won’t target pre 3GS anymore for granted and the loading time will grow significantly for these textures.
Indeed, and I addressed this by explaining why Unity’s texture compression is worse than PNG in terms of disk space, but much better in terms of loading time and memory usage.
As dreamora and I have both mentioned, loading PNGs at runtime can reduce your app footprint significantly, but the memory consumed as a result might stop your program from even running. This is something you’ll have to try out, but it is very easy to test.
Yes, this is likely to happen and would definitely improve the trade-off. You would still have to be careful about about the number of textures loaded in this way, though, as even 4MB per texture is a significant percentage of available memory on older devices.