I love PVRTexTool for generating .pvr files. I’m wondering if there is any benefit to using it for ETC or DXT files.
The PVRTC code does work a lot harder than DXT or ETC, but these are separate technologies which don’t really allow for the same breadth of optimisations that PVRTC does. The main reason the PVRTC compressor works so hard is because it can - there are a huge number of optimisations that work for PVRTC which wouldn’t work on ETC or DXT due to how they are specified.
ETC and DXT on the other hand only have a limited number of ways to get an output, and so the optimisation choices are much more limited. In terms of PVRTexTool’s DXT and ETC output - it’s basically the same as what you’d find elsewhere I’m afraid.
The only benefit of choosing PVRTexTool in this case would be to standardise how you compress your textures. From the next release, KTX and DDS support have been rewritten to be far more robust - and you’d see the same output from PVRTexTool as you would from Ericsson’s etcpack, or NVidia’s nvcompress tool for example.
Also it’s worth noting that ETC and DDS can be written into PVR files, the filetype is independent of the texture format. In the same way, PVRTC can be saved into DDS and KTX files.
Thanks for the info. I was guessing that might be the case.
Ok well I can give you some good news with regards to a couple of these issues
-DDS file support is available on MacOS, but due to ongoing issues we’re unable to provide DXT compression on MacOS at this time.
-It’s unlikely that we’ll add multi-threaded compression code for these formats any time soon - though in theory they may be quite easy to parallelise. It’s something I’ll consider adding in future.