ETC1 VS ETC2 texture compression

So I'm trying to set up my project with all the correct texture types for all the platforms. And not suprisingly it seems the Unity documentation is out of date as usual?

http://docs.unity3d.com/Documentation/Components/class-Texture2D.html

I'm counting 29 texture options for Android in the Advanced settings but I only see 14 in the documentation.

But specifically I'm wondering if I should be using ETC2 instead of ETC1? According to the wiki it's backwards compatible and supports RGBA (RGBA plus alpha) in addition to having higher quality compression.

http://en.wikipedia.org/wiki/Ericsson_Texture_Compression

So am I missing something here why Unity even includes ETC1 if ETC2 sounds like it's better in all ways? Pretty confused about what to do with all these undocumented options...

Anyone have some info about this?

Edit: Hmm seems like ETC2 also supports non POT textures... that's another very good reason for me to use it if it's viable for all Android platforms?

 

ETC2 basically requires OpenGL ES 3.0. And number of OpenGL ES 3.0 supported Android devices isn't very high.

https://www.khronos.org/assets/uplo...pengl-es-bof/Ericsson-ETC2-SIGGRAPH_Aug12.pdf

 

Dangit, well gonna have to redo all my Android textures again

Really annoying how mobile platforms can't seem to handle simple texture stuff I don't get it oh well.

So what would happen if I leave ETC2 in the game for devices that can't support it? Would they still work fine but just cause really long load times to decompress everything for each scene?

I have a lot of 1280x720 full screen textures, some of them are RGBA kinda need the non power of 2 compression

 

Meh I just undid all the ETC2 ones to be safe sounds like if you use unsupported ones it really screws everything up with double memory and/or rendering problems.

I guess we can only use ETC1 where possible and everything else must just be a huge file?

 

You can have multiple APKs, that use texture compression (DXT/PVRTC/ATC) that the platform supports. But if you want easy way out, then yes, use ETC1 when possible and in other cases use RGB32 or RGB16.

 

I thought ETC2 was backwards compatible with ETC1, are you telling me that unity will decompress an ETC2 into a full true color image in the ram? I always assumed it was just falling back to ETC1 when the device couldnt decode it. Great now it doenst make sense to use ETC2 at all, and instead to use DXT5 Crunched instead. if its just going to decompress anyway on es2 devices.

 

ETC2 is backwards compatible in the way that you can load an ETC1 texture as an ETC2 texture and it'll decode correctly in the hardware.

And yes, Unity decompresses an ETC2 texture back to 32bit if it's not supported on the device. I think the number of devices that support ETC2 (all ES3.0 devices, which are starting to become more common) will be larger (if it's not already) than the number of devices that support DXT, so using ETC2 still makes sense. Crunched DXT5 does take less storage space, though.

 

mh114, low end devices is where ram matters, meaning if its decompressed, it doesnt matter whether its Crunched DXT5 or ETC2, because it will end up decompressed on these devices. The fact that it saved for me, between 50%-90% is amazing, the file size was only smaller by acouple of megabytes but i only changed about 10 textures so far.

Higher end devices that support ETC2, probably be effected by having Crunched DXT5 decompressed, since they will have enough ram to handle it.

So it actually makes almost no sense currently to use ETC2, unless your targetting ES3+ only. Then it makes sense, to pay a few extra megabytes to get a slightly higher quality of compression and potentially performance from using less ram, since it supports the format.

 

It does make sense in the case where you'd have 32bit textures anyway, say for 2D sprites. In that situation it makes sense to compress them somehow (for lower storage footprint; companies still releasing 16GB devices in 2015!) since it doesn't matter if they end up taking the same amount of RAM. And again in that particular situation, I'd lean towards ETC2 since it has the potential of being more supported.

For example in the game I'm making I had several atlases that were in 32bit, but are now ETC2 compressed. For some reason Unity doesn't compress the 32bit textures at all (even basic zlib/Deflate would help, LZ4 would be better), so they take huge amounts of storage space after being extracted from the APK.

 

i didnt say dont compress at all, im saying the only 2 options that make sense, are crunched DXT5 and ETC1 , the dxt5 is for Argb textures, and the etc1 is for rgb textures. This way you you get a good balance of high compression, and low ram usage. you cant avoid it currently if you have alpha, unless your using sprites then unity has that extra alpha for etc1 option. but for other textures you have to do etc2 or dxt5, and dxt5 crunched is a smaller file size. since they will both be decompress at load anyway.

 

But they don't decompress at load if the device supports the format. Which was my point, ETC2 is or is going to be more supported than DXT (on Android, obviously).

But I guess we're both correct, you seem to be thinking of old lower-end devices, and I'm thinking of current and future ES3.0 devices.

 

Ofcourse we're both right,

Thats why i said before, if you "only" targeting ES3.0 devices, then it makes sense to use ETC2 because u get the reduced ram usage which could help with performance (and ofcourse Alpha, and slight quality improvement).

But if your targeting all devices... which u should consider doing in 2015, then it doesnt matter if you pick ETC2 or DXT5 Crunched because theyre both getting decompressed. Which makes sense for ARGB. And then for RGB just ETC1

I was able to remove 25% of my file size this weekend, thanks to switching to ETC1 + DXT5 Crunched. And the quality looks very very comparable, especially since im using IBL and lightmapped. It helps offset any quality difference from ETC2.

Also thanks to unity 5.3.1's correction of file size issues i went from 60mb to 35mb apk. combined with the optimizations above.

And theres a performance increase, but to be fair, i cant tell if its from 5.3.1, or from the fact that i now use even less ram (due to ETC1)

 

Alright, my bad, I missed the "unless your targetting ES3+ only" part.