I love PVRTexTool for generating .pvr files. I’m wondering if there is any benefit to using it for ETC or DXT files.
Right now I’m using NVIDIA’s nvcompress tool for DXT/DDS and I’m using Mali’s etcpack -slow tool for ETC/KTX files.
Neither of these produce textures nearly as good as the .PVR files we use, and I’m wondering how much of that is the superiority of the PVR algorithm, and how much is the superiority of the optimization done by the compressor. It takes about 10x the amount of CPU to produce a PVR as an ETC, and 100x the CPU to produce a PVR as a DXT, so either the PVR compressor is poorly written, or it is working a lot harder. The quality difference makes me think it is the latter.
Does PVRTexTool do more/better optimization than the other tools I mentioned?
(I’m starting some experiments now, but they take a long time to run, and it seems PVRTexTool cannot generate DXT/DDS files on Mac, so I’ll have to use a VM or a different computer or something to test/compare those. If PVRTexTool is just a wrapper around the same open source stuff in those tools, I won’t bother.)
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.
Since you are working on the tool, here’s my wish list:
- Be able to read .ktx files in the GUI. It says it can read them, but it fails. (I don’t use the GUI in my pipeline, but it’d be nice to be able to view files for comparison/diagnostics.)
- Be able to write DXT/DDS files on a Mac
- Throw all 8 of my cores at the compression of DXT and ETC files (the tools I’m using now are single-threaded); this would be a good reason to switch to using your tools
- FInd a way to make DXT and ETC suck less [Although I cannot imagine what the business case for this would be]
Ok well I can give you some good news with regards to a couple of these issues
-KTX file support has been completely redone for the next release, so the GUI now actually does support ktx files. -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.
-That would be lovely, but I’m afraid there are currently no plans to do this. Although it’s worth noting Ericsson did recently do the legwork on ETC - for OpenGL ES 3.0 you now have ETC2 available which is a definite improvement.
[Although I cannot imagine what the business case for this would be]