传统的蒙皮数据需要在模型顶点上存两组数据，其一为该顶点受哪些骨头的影响，其二为受这些骨头影响的权重。因为 GPU 的对齐影响，通常游戏中会将同一顶点受影响的骨头数量上限设为 4 。如果不做任何优化，骨头总数在 256 以下时，每个顶点需要 4 个字节保存骨头编号，再用 4 个 float 表示分别的权重。
因为权重之和总是为 1 ，所以，只用 3 个 float 也是可以的（第四个权重通过简单的计算就可以得到）。
因为权重总是 0-1 之间的数字，所以 32bits float 的精度远超所需，我们也并不需要浮点数。所以用 16bits [0,65535) 甚至 8bits (0,255] 来表示 0-1 的权重也够了。
所以，蒙皮一般至少占用 64bit 的定点数据 （4+4 bytes) 。
如果想进一步压缩，就需要一些复杂的技巧了。这两天读了几篇关于动画蒙皮数据压缩的 paper ，挺受启发的。
首先是这一篇 Vertex-Blend Attribute Compression 。
它给我最大的启发是：其实，每个顶点所受骨头影响的组合是很有限的。这也非常符合自觉，因为，顶点总是受空间位置上附近一些骨头的影响。空间位置相近的顶点，所受骨头影响的组合几乎是相同的，不同的只是权重比。
我们完全可以预处理一张表，记录该模型所有顶点的骨头索引组合，然后，在顶点上只需要保存表的序号，这样就可以大大压缩索引组合的数据。按论文中的数据看，一个一万多顶点的模型，组合数只有一千左右。也就是用 10bits 左右就能完整保存骨头组合信息。
我们可以创建固定大小的表，如果模型使用的组合数量超过了表的固定尺寸，就可以把一些不重要的组合去掉，归到最接近的表项上即可。
对于权重信息，也有压缩的余地。因为，骨头是次序无关的。如果我们总是按次序排列骨头，让权重从小到大，那么就有可能进一步的压缩数据。
以四根骨头为例，因为只需要实际储存三根骨头的权重，这三个 0-1 之间的数字实际上可以看成是一个边长为 1 的立方体上的一个点。如果权重一定是从小到大排列，则其实这个点一定落在一个只有立方体 1/6 大的一个四面体上。对这些点重新排列，就可以节省下 log2 (6) bits 。如果把骨头数量扩展到 N ，则能省下 log2(N!) bits 。
如果我们用 10bits 保存索引，22bits 保存三个权重分量，就可以用 32bits 保存完整的顶点蒙皮信息了。
Permutation Coding for Vertex-Blend Attribute Compression 这篇 paper 进一步扩展了上面的方法。
允许每个顶点上的骨头数量是不定的。如果使用 64bits 数据，最多可以支持到 13 根骨头。骨头数量越多，就牺牲越多的精度；反之，如果骨头只有一两根的话，就最大限度的提高精度。
作者在 github 上公开的代码 ，写的清晰易懂。
本文转自： https://blog.codingnow.com/2022/04/vertex_blend_attribute_compression.html
本站仅做收录，版权归原作者所有。