Open alecazam opened 6 years ago
It's not really said anywhere in the documentation, but the command line tool takes png images as input. Other formats seem to be supported if you compile the tool with stbimage support: https://github.com/google/etc2comp/blob/aecc84fc97f2d21a8067d0baa3186c9c17eacd6f/EtcLib/Etc/EtcConfig.h#L58
Haven't tried that though.
Also it's a shame but this project seems to be pretty much abandoned.
Yes, I was able to run EAC_RG11 and use a png file. Colt knows his compression, and has some great books and articles that were probably inspired by this work. I was just hesitant to pull the source and build it without that. There's a nice easy flow with png in and ktx out.
I feel like with S3TC now off patent, that all of these unnecessarily complex and inconsistent mobile formats just need to get replaced and we go back to DXT everywhere. ASTC is no simpler, but the ETC default compressor is unusable slow. How can a company push a compression format, and then release a compressor that bad to encourage it's use.
For a 1024x1024 image with mips, the times are really good. The times seem much more reasonable. This would be (4 + 1.3 = 5.3MB) without compressed textures. These were the sizes produced.
R - 0.7MB
RG - 1.4MB
RGB - 0.7MB
RGBA - 1.4MB
Do most people really have float image data to feed into an encoder? Shouldn't this take png files containing data and compress them like all of the other tools.
I also don't see EAC_RG11 support, but there is EAC_R11. The former is useful for normal maps which only have two uncorrelated channels.