Atlases as PNGs in build

[oddurmagg]

Has anyone experimented with including atlases as PNGs in the unity build, by having them as resources with .bytes extension. Then using Texture2D.LoadImage to load them at runtime(http://docs.unity3d.com/ScriptReference/Texture2D.LoadImage.html)  and use as a atlas texture.

This would bring my built size down by an order of magnitude, since I have all atlases as uncompressed 16bit RGBA, and I have a lot of them (1 per level). The reason I have that many atlases is I have a custom build step which goes over all the sprites in the scene and creates a scene specific atlas only containing the sprites used in the scene, I do that to collapse drawcalls atlases and minimize runtime memory overhead. But the flipside is my build balloons in size.

I am going to start experimenting with loading .png.bytes at runtime and I just wanted to check if anyone had gone down a similar route.

[Nicki]

Textures are already compressed in builds; the size in the preview window is memory use, which would still be present even if you loaded it as a png or jpg. It depends on the what types of image formats are readable from memory; for iOS it's raw bitmap or PVR compressed, windows it's DXT or bitmap. Point being, I don't think you'll win anything doing that.

[oddurmagg]

At runtime the images would be loaded into raw bitmap, which is what I want (PNG files are loaded into ARGB32 format.)

Runtime memory size if now what I am battling, but rather the build size. If I choose to have my atlases at uncompressed 16/32 bit, they are included like that in the build. What I am trying to achieve is including them as PNGs in the build and loading into a texture2d object at runtime, where they would be ARGB32.

According the the build report, the textures are taking up as much space in the build as is shown in the preview window.

[oddurmagg]

I have this working now. I am loading pngs from .bytes file, which drastically reduced the size of my build.

I have also created an IOS extension that loads the png's into a RGBA4444/RGBA5551 texture instead of the RGB32 as LoadImage does. I also have the support for RGBA5551 since most of my texture only require a single but transparency anyway and my artist really appreciated the extra color depth. This is giving my best of both worlds, small disk usage (pngs!) and low memory usage (16bit!) and extra color depth (RGBA5551 in 16 bit!)

My only step now is hooking correctly into the UIAtlas lifetime events, since properties of prefab don't receive f.x OnDestroy. I am putting together a proxy component which goes on to all my sprite gameobjects which forward those messages to the atlas on the sprite. Ugh..

If anyone is interested in working on or receiving the code .. just contact me. I would love for someone with android experience to port the opengl part to android.

[Nicki]

Sweet, well done. I'd love to take a look at the code.