Is anyone experiencing excruciatingly slow texture compression times for ETC1/ETC2?
I’m on Unity 5 with patch 0p3 now. Compression on the Android side used to be really quite fast (way faster than my pvrtc compressions on iOS), but now the times are much slower. It appears pvrtextool is running single threaded and its taking a 2048 texture over 30 minutes to compress on best quality (on a 3.4Ghz i7 5K iMac and longer on my older '08 Mac Pro).
Any suggestions or ideas whats going on considering how significantly longer its become? Scott
To be honest I can’t recall ever checking until now but I was surprised to see pvrtextool being launched for each texture in the import process. I had to even check to make sure that it even supported etc compression, but according to their website; it does.
So I’m not sure if something is falling back to pvrtextool, this is a recent change, or what. I just know so far that the performance is incredibly bad. Scott
Maybe it’s because you are running on MacOS. I’m in Unity 4.6 right now on Windows 8.1, and it pops up an ETC tool exe. So maybe I’m not the best help, but maybe it’s something changed for Unity 5, or because it’s using pvrtextool on a Mac.
I’m sure if it was taking everyone 30min there would be a lot more complaining going on though!!
I just checked: we switched from etcpack to PVRTexTool in Unity 5. Compression Quality ‘Best’ is now super slow for ETC. The result should be of higher quality now but I think it’s just too slow.
This was the case for Unity 4 also. Superslow compression on my ETC2 textures. I really hate updating the textures now. But ETC2 gives very nice result on my Android app I am working on. Unity with the PVRTexTool running as a process spent over 24 hours on converting my project from Unity 4 to Unity 5
I did contact Imagination Technologies and this is what they said “Unfortunately PVRTexTool doesn’t have multithreaded ETC1 compression capability. It’s a good suggestion and we will be investigating it for a future release.”
so only options for now are:
Use different tool
or
Make Unity do threaded texture importing, when multiple textures are imported
If it’s based on the standard ETC compression code that Strom et al released, then, IIRC, there are three quality settings Fast, Medium, & Slow, and (according to their code) the latter two increase the search space relative to Fast by factors of around 27x and 125x respectively. They might also try test other modes which may increase the search time further.
Setting GLES 2.0 or GLES 3.0 compression on the Android build for example, a unitypackage import can take 30 mins per PNG / EXR file, absolutely killing development.
Any tips on how this can be improved, avoided? Do I only set compression at night before I go to sleep and process 8-10 pngs per day? =/
I know this doesn’t help make the compression times run faster but figured I’d share what I do.
installed asset server cache
turned off “compress assets on import” in Unity preferences
I also installed Unity on a second machine configured to share the same instance of the asset server cache but left the compress preference on.
When updating images or modifying atlases, the compression gets skipped – until a build is performed making development quicker. To help cut down build times, I periodically will do one of two things:
when shutting down for the night, I’ll turn on “compress assets on import” and let it run over night. The compressed textures will be updated in the cache for later.
or
I’ll load the project up on my second machine letting me continue working while it compresses and updates the textures in the shared cache.
This is obviously for builds when I’m not using Unity’s cloud build. It’s not perfect but it at least keeps me from wanting to run in traffic Scott
I’m sorry, but it’s unacceptable how this slow conversion process is single threaded. 15 hours ago I opened my Unity 4 project for the first time in Unity 5. I still don’t have it open because it’s still importing textures and only about 70% done. My task manager consistenly reads 8% CPU usage. Big fat waste of time, this is really annoying. It can’t be that hard to launch multiple threads.
Is there at least a way to do this conversion in a multi threaded manner via some script?
ETC compression will be multithreaded in Unity 5.2. I’ll check if a backport to 5.1 is feasible.
But even in multithreaded mode ‘Best’ compression quality will still be much slower than ‘Normal’.
In Unity 4.6 ‘Best’ was just mapped to ‘Normal’.
The import does still seem to be incredibly slow compared to how it used to be. It only says ~1 sec on Normal, and up to 20 mins for best on a 2k texture using a quad core processor .
[quote=“Madhotdog, post:18, topic: 575696, username:Madhotdog”]
It only says ~1 sec on Normal, and up to 20 mins for best on a 2k texture using a quad core processor .
[/quote]Well, PVRTexTool is a 3rd party software so I don’t think you should address that to UT.
Is there any way to map “Best” back to “normal” quality for compression, it takes almost an hour to convert my project from 5.3 beta to 5.3 release… it reimported everything! which would be fine if i could find out which of those textures are not set to normal, without having to stare at the screen and write them all down =/
Scott