云风的 BLOG

bgfx 的 astc 支持是做足球经理项目的同学提的，我在几个月前提了个 issue 希望他能完善一下，可能是他工作很忙，一直没有回音。最近我们自己的项目向手机 port ，必须用到压缩法线贴图了（不然内存不够），只能自己动手。好在这样也就激活了这件事，现在那位同学已经自己开始干了。

btw, 这次发现我向 bimg 提的 pr ，居然可以跨仓库合并到 astc_encoder 项目上，而保留 patch 的作者和时间信息等。我一直不知道 git 还有跨仓库合并 patch 的功能 :)

这事我起了个头，不用自己做了，很开心。多出来的时间，我饶有兴趣的比较几种压缩格式的质量。

首先，图形有损压缩的质量衡量标准，业界一般采用 PSNR 峰值信噪比 。这个值越高，表示压缩质量越好。不过也不完全唯 PSNR 论。ASTC 和 ETC 的官方压缩器都提供了一个叫 percep 的选项，它的 psnr 差不多（略低）但号称对人的视觉上感觉更好。etcpack 更是把它作为默认选项。

我使用了 Nvidia 的贴图压缩工具 生成 DXT 格式贴图，ARM 的 astcencoder 生成 astc 格式贴图，Ericsson 的 etcpack 生成 etc 格式贴图。

astc encoder 有一个文档 专门说明法线贴图的压缩方案。

我今天使用了 Unity 官方公开的一个场景中使用的 2048x2048 的切线空间法线贴图。原始图片可以在这里找到。

下表是我的比较结果：

PSNR 全部是用 astcenc 计算得到，因为 nvidia 的工具生成并还原的贴图只有两个通道，其它工具会还原成三通道。为了公平起见，我用 imagemagik 把结果中的 blue 通道全部清空再做计算。

我们可以发现，etcpack 生成的 EAC_RG11 质量最好，不过 etcpack 的算法实现实在是太糟糕了，慢的令人发指。同样一张 2048 的图，nvidia 压缩 dxt 只需要一秒，etcpack 需要跑几分钟。前段时间我自己实现过一个版本 ，可以把 O(n*n) 的时间复杂度降低到 O(n) 。

dxt 的质量最差，当然这个格式也最古老。

astc 最具弹性，选择 6bpp 就能到达到 dxt 8bpp 的质量。针对双通道的优化质量提升也很明显。而且在追求更小体积时，还可以选择更低质量（这点 EAC 做不到）。