are now cubemap texture compressed? back in 3.5 there was a bug where it was impossible to compress the cubemap textures.
You could call it a bug, or call it a lack of feature 
No, cubemaps still canât be compressed in Unity 4.0. Which is a shame, yeah.
So even if you set compression to pvrtc, Unity will load them into memory as trueolor?
What happens if you load directly .pvr cubemap textures in the Editor?
Where do you set them as PVRTC?
.PVR textures canât contain cubemaps, I think.
Anyway, right now cubemaps are always uncompressed.
you set your 6 textures as compressed in their inspector window (like you would with a usual texture) and plug each one the right side in the cubemap node.
Thanks to new (unity3d 4.1) memory profiler Iâve detected that my level environment map takes 16 Mb instead of only 1 Mb that Iâve expected. Face size was just 512x512 and all of them have ETC1 format.
*The first problem is that compression doesnât work and this gives 8x on the expected size.
*The second problem is âReadableâ checkbox was enabled and not visible in the default inspector layout, this gives us additional 2x on expected size.
*The third problem is that you donât see estimated memory requirements (in preview) and format for cubemaps so you canât detect these problems on the early stage.
BTW: âread/writeâ checkbox for texture asset doesnât affect asset size but affect run-time memory requirements and we should see this fact in the preview too.
Hope you add cool cubemap compression feature in Unity 4.1.3 or other:)
And help developers to detect memory hungry resources as soon as you can.
OK, Good news. I have found compressed cubemaps. The most interesting thing that they are introduced in Unity3d 4.1 
They are hidden in Texture2D. In inspector you can select texture type âAdvancedâ (than select âFullCubemapâ in âGenerate Cubemapâ) or âReflectionâ.
You can read other details in http://docs.unity3d.com/Documentation/Manual/Textures.html (Reflection Settings)
Unfortunately, that technique is in the end also uncompressed. In fact, itâs even larger than the Cubemap Asset with 6 Slots way, because it has the white space.
I did find a way of decreasing the Cubemap size by 33%, (I used a script to create a Cubemap with a 16 bit texture formatâit wouldnât let me use compressed formats), but thatâs not that comforting when a simple 512x512 cubemap is still adding just under 3MB to your gameâs compressed download size.
I did some tests.
6Slot Cubemap Asset: 3mb (with 16 bit script-hacked texture)
Cubemap generated from texture (the way you suggest above): 5.5mb
You are right. Donât trust anyone. Maybe itâs good idea to write editor + native plugin for iOS/Android which takes *.pvrtc file as input and creates proper Cubemap during run-time. If I have time on my project I will implement it and share.
Actually, I just created something like this yesterday. You supply the six images you want to be in the cube-map, (or just supply a cubemap and it will export out the images compressed), and on game startup (or whenever you want) it will reconstruct the cube-map in memory and apply it to the given materials. It really saves a lot of space, in the final game download.
I was thinking of putting it up for $5 on the Asset Store, but itâs a basic enough plugin, and needed enough, that Iâm thinking I might also post it here on the forums (or maybe on the Wiki). I would do it right now, except itâs 1:30 in the morning⌠
Okay, hereâs the Unity Package for it: Cubemap Compressor 0.0.1.unitypackage download - 2shared
Okay, you have solved just a part of problem. Your build size should decrease slightly, because you store all you cubemap faces in compressed format, but run-time memory pressure should be the same or even worse when youâre using embedded Cubemap asset, because format of your Cubemap is TextureFormat.ARGB32.
I have talked about this kind of plugin:
- serialized face data using ETC1 (or other) texture format
- create dummy cubemap resource (I donât try, maybe itâs an error to use TexterFormat.ETC1 for Cubemap)
- initialize resources with native plugin using GetNativeTextureID (using glBindTexture, glTexImage2D(âŚETC1âŚ) with serialized face data)
- free memory with serialized data
â- serialized face data using ETC1 (or other) texture formatâ
Iâm not sure what you mean by this. Wouldnât âserialized face dataâ just have to be deserialized and put into a cubemap at runtime? How would this be different than just serializing the âface imagesâ and then deserializing at runtime?
â- create dummy cubemap resource (I donât try, maybe itâs an error to use TexterFormat.ETC1 for Cubemap)â
I tried this, with pretty much all the different TextureFormats, and the only other one that works thatâs smaller than TextureFormat.ARGB32 is TextureFormat.RGB24. Cubemaps do work with this 6mb rather than 9mb format, but the problem is that for some odd reason the code-based âSetPixelsâ and âSetPixelâ methods stop working once you switch to this format. You have to drag the face images in through the editor. I donât know how the editor applies the face images differently than the way I did in code, but apparently thatâs the only way right now to get smaller-in-memory cubemaps. And the problem is that since you canât create these smaller RGB24 cubemaps at runtime, you then have to choose between a 1mb-in-download set of face images that is made into a 9mb cubemap at runtime, or a 6mb-in-download cubemap loaded also as a 6mb cubemap at runtime. So it appears you canât optimize both with existing methods.
â- initialize resources with native plugin using GetNativeTextureID (using glBindTexture, glTexImage2D(âŚETC1âŚ) with serialized face data)â
This sounds interesting. I wouldnât know how to do this, (yet anyway), but if it could be used to make compressed cubemaps itâs worth looking into.
â- free memory with serialized dataâ
Not sure what you mean by this. I guess just that if we serialize the cubemaps as explained above, the memory usage will be smaller.
Has this been solved in 4.2 (in 4.1.3f3 the problem still persits. although the editor allows to select compression, and the editor will also report a small compressed size, the profiler reveals that the memory consumption is huge. i.e. 2xuncompressed)?
I donât think so, just the partial solutions mentioned above. (reducing the size in the download, at least, by just storing the face images and having them turned into a cubemap on game launch)
download size is no issue for me. But 96 MB memory consumption for two environment maps (while the whole rest just consumes about 20 MB) is too much (developing for iOS).
Yeah, I definitely think itâs still a problem. I would think that it should be fairly easy to fix, (letting you choose the image format for cubemaps), though I donât know for sure.
I guess you could try putting up a request for it on the Unity Feedback subsite, (http://feedback.unity3d.com), though it seems to take a long time even if it gets accepted there.
Agreed, it is a shame! ⌠is this on some roadmap or other?
Just an FYI - this issue has been fixed in a future release:
Specifically, fixed for 5.0.
3 Likes