Has the CubeMap texture compression bug been fixed in Unity4?

are now cubemap texture compressed? back in 3.5 there was a bug where it was impossible to compress the cubemap textures.

 

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?

 

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: http://www.2shared.com/file/Qe367qoo/Cubemap_Compressor_001.html

 

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?

 

This is very good news but I'm looking at Unity 5 and I'm not seeing any options for compression on the Cubemap class. How does one control compression for a Cubemap object? I'm specifically interested in generating a cubemap at run time in an RGBM format and then compressing it for mobile. Thanks.