This seems very promising, please get it into Unity ASAP! 
Current ETC2 compression (especially with “Best” quality setting) is painfully slow.
4 Likes
More tests in
1 Like
Bump! Unity Android devs, any chance of getting this into Unity? @Yury-Habets ?
We’ll consider it. Thanks!
1 Like
That would be great, only “best” has the really long wait times, increases the import time 20x easily.
I reckon ETC2Comp would help even in lower quality levels than “best”, so it’d be a win-win.
First tests show slower compression on Normal and faster on Best.
So it’s again not as easy as it could be.
@florianpenzkofer has more details!
1 Like
Interesting. Thanks for checking. Maybe use PVRTexTool (or what have you) for Normal and ETC2Comp for Best, then…? 
We only need it for best, everything else works fine on normal and fast
PVRTexTool is also not the fastest way to compress for normal.
We’re considering options - your feedback is valuable!
Are you extensively using Best quality?
Is Normal quality too slow? Could we trade off quality for speed?
I was considering using Best for my background images (2D game) but opted not to since the compression time was horrible. Normal is alright by me, but if you can make it faster I won’t complain!
I made some experiments with various ETC compressors. So far it looks like:
Etc2comp could give us significantly faster ‘Best’ quality. The actual quality will probably be slightly worse than current ‘Best’ but better than ‘Normal’.
etcpak could give us slightly slower but much higher quality ‘Fast’ compression.
With my test data etcpak actually looks good enough for ‘Normal’ when compressing to ETC2. So changing the default format for RGB to ETC2 would also be an option.
I have not found a tool that is faster than our current solution for ‘Normal’ that has similar quality.
1 Like
Btw, I tried etcpak, ETCPACK, PVRTexTool’s ETCPACK, ARM’s etcpack, rg-etc1/crunch, ISPCTextureCompressor, etc2comp, ALGCompressionTool
Can you mix and match?
The problem lies with “best” quality only, thats why i was asking.
For ETCPack, how is the speed on “Best”, because if its similiar quality but faster best, then we its a win win all around.
Yes we can mix and match. ETCPACK is what we use now (PVRTexTool’s flavor of ETCPACK). So I assume you mean etc2comp. ETCPACK/PVRTexTool at the quality setting we use for ‘Best’ was around 7x slower compared to etc2comp at ‘effort 70’ setting. But I didn’t do that measurement on a lot of texture, mainly because ‘Best’ takes so long to compress ;).
Comparing quality is not so easy. To me and in PSNR numbers etc2comp effot 70 seems fine compared to what we have now.
I’m curious, for what kind of textures do you typically use ‘Best’ quality?
No.
All of them?
Why wouldn’t I use best?
With some textures the difference in quality is very small, ‘Best’ takes a long time to compress and I would assume that many people stick to the default setting (‘Normal’) for textures where they are happy with quality. That’s why I was asking.
Otherwise, no reason not to use ‘Best’.
I’m of the opinion that spending extra offline cpu time for better looking compression is generally worth it, even if the improvement is miniscule.
So I would never agree with making “best” worse looking but faster. I’d actually be okay with better looking but slower.
Maybe you could add a few more tiers so everyone can be happy? Fast, Normal, Best, Insane? Or something like that.
Thanks, yeah I meant Etc2comp.
Could you give us a sample of PVRTextool/ETCPACK at best and then Etc2comp at 70.
Is there an 80? we could use a sample of that as well.
If its possible to show a 2048x2048 , and its Normal map compressed, on a 3D Model with an upper strong point light and lower weak point light.
We should be able to tell pretty easily, a good example is a Framed Picture, that has designs around the edge frame in normal map.
So the actual model is very flat around 100polys or so and the details lost will be obvious between the 2.
If they look nearly the same, then we’ll know the speed is better.