Unity 5.2 Overriding my texture format settings.

In Unity 5.2, with the platform set to iOS, in import settings under the Default tab, if I set a texture to import as RGBA Compressed ETC2 8 bits, in the preview below I can see that Unity has override my choice and actually set it to RGBA Compressed PVRTC 4 bits.

Yes, I understand that ETC2 is not supported on iOS, and that it will cause the texture to be decompressed before loading into memory. I don't care. In many cases PVRTC looks like total garbage. In most cases I would rather live with the performance tradeoff.

In previous versions Unity did not override my settings like this.

Is this a feature, or a bug? Is there a work around?

If it matters, I am using Unity 5.2.2p3. Perhaps it is only a bug in this patch release?

 

bump

 

I would guess that unity can not uncompress the compressed image format, it has to be in a format that the platform supports. If you do not like the PVRTC format you have to stick with uncompressed.

You should try out the pvrtextool, its a nicer GUI version of the Tool that unity users internally and you can use it to procure higher quality PVRTC images then the unity one.

http://community.imgtec.com/developers/powervr/tools/pvrtextool/

 

I don't understand what you mean. My image is a PNG.

In Unity 5.1 this works fine. Unity takes my PNG and imports it to ETC2 format.

In Unity 5.2 for some reason it decides to use PVRTC even though I've selected ETC2.

 

iOS does not Support ETC2.
all the formats that are supported on IOS are listed here:
http://docs.unity3d.com/Manual/class-TextureImporterIos.html

Ericsson Texture Compression (ETC) is compression format by (sony)Ericsson and is not supported by Apple.

my guess would be that unity did allow the selection in 5.1 and below for backwards compatibilty like the do now for DXT1 and DXT5 compression (with does also not work on ios).

 

As stated, I understand the consequences of using ETC2 for iOS, but I accept the trade off for the sake of file size and more appealing visuals.

So my question is, is this a bug or a "feature"?

Should I still be able to use ETC2 on iOS in 5.2? Or have they changed it so I am not allowed?

 

Just confirmed that it behaves as expected in Unity 5.2.2p1, but NOT in Unity 5.2.2p3.

I just saw that 5.2.2p4 is available. Downloading now.

 

I narrowed this down to Unity 5.2.2p2.

I think it relates to issue 715380 mentioned in the release notes.

Editor: Unsupported texture compression formats now correctly fallback to default compression format for the platform.

So apparently it's a "fix". Doesn't seems like a fix to me. I was relying on this to keep my file size down while preserving presentable graphic quality.

 

Is there any way we can continue using ETC2 on "unsupported" platforms?

 

Having same issue here. We'd really love to spend amount of "computer"'s time by using software decompression if it looks good in every platform without spending "our" time to figure out how to make it look good with other compression. and i think this "fix" thing shouldn't be fixed. i mean, it's more like weird change, what's the point of software decompression, if it's really 'fix'.

 

Would be nice to at the very least be able to turn this "feature" off in settings somewhere.

 

Has anyone heard any official word from Unity on this "feature"? I'd really like to explore upgrading my projects so that I don't have to keep so many versions of Unity installed on my machine. However, this is a huge roadblock.

 

Could I get an official Unity response please?

 

Please someone from Unity weigh in on this. Is there a good reason this change has been forced on us?

 

Since the fix was listed as Editor, and not iOS, it was probably just a editor reporting issue, and the actual fallback was still happening, just not displayed correctly in the editor. Most likely it was actually falling back to uncompressed ARGB32 at build time.

Also, while Unity devs do occasionally pop into the forums, you should probably email support directly.

 

My build sizes disagree.

We were using this compression primarily to keep build file sizes to a minimum, but maintain a decent appearance.

If I didn't care about file size, of course I would simply set all my textures to ARGB32.

Suddenly, this "fix" is implemented and we are no longer able to do this.

I have tried filing bugs and contacting support with no response. I see Unity reps responding directly to other issues here. I'm still hoping for the same on my issue.

 

Here is my issue on Unity's bug tracker:
https://fogbugz.unity3d.com/default.asp?745434_1q2mcpnartn7e41p

This is the first bug I have ever entered there. So I don't really know what to expect. However the status has not changed since I reported it 2 months ago. I would think perhaps the status would change to "accepted" or "closed" or something when they have at least viewed it and decided to ignore me...

Perhaps this thread can go in a different direction?

Does anyone have suggestions for maintaining decent appearance yet realistic file sizes for 2D assets in Unity 5.2.2p2+?

 

It seems like you want to use ETC2 just as a file compression scheme and you expect Unity to decompress the 4-bit-per-pixel image to a 32-bit-per-pixel texture? If so, you would be much better off loading a png or jpg from StreamingAssets into http://docs.unity3d.com/ScriptReference/Texture2D.LoadImage.html

 

Thanks cory_munky, I will look into that.

However, the main point of this thread is that this "feature" was simply yanked with no explanation. If I choose to use/abuse the format for that purpose, what is the problem? Why is this ability taken away?

 

Well, to be frank, it's a pretty terrible use of the tech that should not be encouraged. Compared to PNG or JPG, decompressed ETC is a horribly slow, fat and lossy compression scheme. Unity has plan around dealing with millions of clueless newbies over the course of the past and future decade. Anything they let people abuse badly will, with great certainty, come back to bite them in the ass in long, painful, awkward and all-around enraging ways. The longer they allow it to be abused, the harder it is to ween people off of it. Better to cut if off early before too many people become dependent on it.

 

I'll explain a bit more about why ETC2 got "removed" for the iOS. It's a bit similar to what Cory_munky mentioned.

First, the only reason why iOS "can" use ETC2 and EAC is because it's able to emulate it through OpenGL ES 3.0. As you have already mentioned, there's a memory trade-off which you agree to. Now, why removing ETC2 from iOS if it can emulate it? Simple. There's no guaranty that any next up update of the OpenGL used by Apple for is iOS will have the ability to emulate a compatible OpenGL with ETC2 pr EAC format.

Think of it as this... What would happen if Apple's next major iOS update uses an OpenGL that, when using ETC2 or EAC compression formats, takes 5x-6x more memory than on previous iOS version? After all, iOS is not natively compatible with ETC2 or EAC. It can only runs its calculation through OpenGL and extract its results there and reformat it into PVRTC before it being rendered. Any update on OpenGL or iOS could render your game(s) inoperable on some or even all iOS device simply because of that.

Considering this, would you be okay with something like having a major part of your gamers' market raging on the web because an update on their iOS transformed your game into a blobware unable to run until you fix it and... as a result, the game takes more space of their already precious limited memory because you had to turn it to a PVRTC compression format for it to be able to run properly on iOS?

This is why Apple highly recommend that any software which uses texture data compression to uses PVRTC compression format because it's natively compatible through the extension implemented within the iOS itself.

So, if something happens with PVRTC, Apple will work to fix it ASAP. If something happens with ETC2, they might not bother for the next couple of months. Would you agree to that?