3D模型的量化

NSDT工具推荐： Three.js AI纹理开发包 - YOLO合成数据生成器 - GLTF/GLB在线编辑 - 3D模型格式在线转换 - 可编程3D场景编辑器 - REVIT导出3D模型插件 - 3D模型语义搜索引擎 - AI模型在线查看 - Three.js虚拟轴心开发包 - 3D模型在线减面 - STL模型在线切割 - 3D道路快速建模

glTF 的 WEB3D_quantized_attributes 扩展提供了合理的压缩，几乎没有解压开销。 这完美地满足了Cesium中3D Tiles的需求，因为3D Tiles引擎经常根据视图下载新的tile。 量化 3D 模型文件意味着文件更小、下载速度更快、GPU 内存使用量更少且性能不会下降。

1、关于量化的一切

WEB3D_quantized_attributes 扩展基于 Jongseok Lee 等人的移动图形网格几何压缩。

通常，位置和法线等模型属性存储为 32 位浮点数。 量化采用这些属性并将它们存储为以最小值和最大值之间的比例表示的 16 位整数。 这意味着可以用一半的空间来存储属性数据！

解压缩是通过 GPU 上的顶点着色器中并行的简单矩阵乘法完成的。

2、Cesium 中的模型量化

量化最适合文件大小主要由可量化属性（例如位置和法线）组成的模型。 因此，具有复杂几何形状的文件往往受益最大。

为了说明这一点，我在glTF 示例模型存储库中包含了使用两个模型的概要。

2.1 双缸发动机

这是Okino Polytrans Software 向 glTF 示例模型存储库捐赠的一个复杂的几何模型。模型统计数据如下：

原始文件大小细分如下：

2.2 Cesium牛奶车

这是由 Cesium 团队捐赠给 glTF 示例模型存储库的纹理密集模型。模型统计数据如下：

原始文件大小细分如下：

正如预期的那样，具有更多几何体的模型从这种压缩中受益更多，但即使文件大小主要受纹理影响的模型也能从有效的免费压缩中受益。

数据没有一路缩小到 50% 的原因是因为二进制数据缓冲区的一部分是由无法量化的索引组成的。

将 gzip 应用于模型可以缩小量化和非量化文件大小之间的差距，但最终量化模型仍然比非量化模型具有大小优势，并且使用更少的 GPU 内存。

glTF JSON 本身的大小有一些细微的变化。 这是由于量化期间数据访问器的重构以及添加了一些支持量化的属性。 这些步骤是 gltf-pipeline 实现的结果。

gltf-pipeline 项目包含量化的开源实现，可用于压缩 glTF 模型。

2.3 与现有压缩的兼容性

我们已经在 Cesium 中使用了两种压缩法线和纹理坐标属性的技术。 使用 Zina H. Cigolle 等人的《独立单位向量的有效表示调查》中描述的技术对法线向量进行八进制编码。 这会将三个 32 位浮点数压缩为两个字节，压缩率约为 83%，因此这种方法优于法线量化。

另一种技术将表示纹理坐标的两个 32 位浮点数存储到单个 32 位浮点数中。 与量化一样，这也会导致大约 50% 的压缩，因此使用任何一种技术都可以得到类似的结果。

不幸的是，量化不能用于进一步压缩这些属性。 它只能应用于浮点属性，因此不能用于字节八进制编码的法线，即使纹理坐标压缩确实将其值存储到浮点数中，尝试在其之上应用量化会产生一些有趣的结果 。

发生这种情况有两个原因：第一是量化是一种有损压缩； 第二个是压缩纹理坐标不一定是线性映射的。 量化将产生接近原始值的解压缩值，但不一定是相同的值 [A]。

因此，我们的方法是量化位置、八进制编码法线以及量化或压缩纹理坐标[B]。

双缸发动机模型的八进制编码法线和量化属性的统计数据如下所示：

原始文件大小细分：

八进制编码法线所需的着色器修改确实增加了着色器的大小，但与整个模型的大小相比并不算多。

3、3D Tile中的模型量化

3D Tiles 是一种开放格式，用于流式传输大规模异构 3D 地理空间数据集。

借助 Cesium 对量化属性的支持，批量 3D 模型 (b3dm) 和实例 3D 模型 (i3dm) 图块格式中的 glTF 可以进行量化，以实现更快的下载和更少的 GPU 内存使用，而不会影响性能。

下面的基准测试和屏幕截图中使用的数据来自 CyberCity 3D 的华盛顿特区数据集。 缩放基准是缩放城市时每秒帧数的平均值，导致加载额外的图块，如下所示：

这里使用的模型已经对其法线进行了八进制编码，因此压缩表示仅量化模型位置的增益。

3.1 西北克利夫兰公园

下表显示了华盛顿特区西北克利夫兰公园的批处理 3D 模型的文件大小细分和压缩统计数据。这些文件被分为详细级别的层次结构。

对于在 Windows（Intel® Core™ i7-4980HQ 四核 @2.80GHz 和 AMD Radeon R9 M370X）上的 Chrome 51.0.2704.84 中运行的量化和非量化数据集，缩放基准在 10 秒内平均约为 52 FPS。

3.2 整个华盛顿特区数据集

整个华盛顿特区的数据集在这次运行中被量化。 为了简洁起见，我不会包含详细层次结构细分，仅包含总体统计数据。

对于量化和非量化数据集，缩放基准在 10 秒内平均约为 50 FPS。

因此，与各个模型一样，应用 gzip 确实使量化和非量化文件大小更接近，但城市数据集的文件大小仍然稳定地下降了约 10%，并且 GPU 内存使用量也减少了。 构建具有更复杂几何形状的模型似乎可以从压缩中受益更多。

这可以通过查看西北克利夫兰公园瓷砖来证实。 0/0/0.b3dm 压缩最多，而 2/0/0.b3dm 压缩最少。

2/0/0.b3dm 是一个具有非常简单房屋模型的社区，而 0/0/0.b3dm 具有更复杂几何形状的建筑物。

b3dm 图块包含一个在普通 glTF 中未找到的附加字段，即用于唯一标识每个建筑物的每个属性 uint16 批次 ID，该 ID 无法量化并且确实会影响整体文件大小。

4、结束语

这是对 glTF 和 Cesium 的 3D Tiles 实现的一个非常有前途的补充。 缩放基准不受量化的影响，并且在渲染中视觉上没有差异。 对于不断发展的 Cesium 和 3D Tiles 社区来说，其中一些大城市数据集的文件大小减少 10% 将是一个受欢迎的补充。

glTF WEB3D_quantized 属性的 Cesium 实现可以在 Cesium GitHub 存储库的 Model.js 中找到。

5、附录

A. 量化压缩纹理坐标

这是我们在Cesium中使用的纹理坐标压缩算法：

var x = textureCoordinates.x === 1.0 ? 4095.0 : (textureCoordinates.x * 4096.0) | 0;
var y = textureCoordinates.y === 1.0 ? 4095.0 : (textureCoordinates.y * 4096.0) | 0;
return 4096.0 * x + y

量化解码为接近原始值，但不一定完全相同。 这里的问题是，数字上接近的压缩纹理坐标在解压缩后不一定在空间上接近。 这会产生如上所示的扭曲。

B. 量化和纹理坐标压缩之间的权衡

理想情况下，量化和纹理坐标压缩可实现 50% 的压缩。 那么哪一个更好呢？

这最终成为一个很难回答的问题。 它们都是通过相当简单的 GPU 操作来解码的，因此解码性能应该是一个有争议的问题。 精度怎么样？

压缩将始终保留 12 位精度。 当前的量化实现不进行任何分块（将模型分割成多个量化部分以保持较高的精度），因此精度取决于被量化的区域。

如果纹理坐标覆盖单个正方形单元，则量化可保留 16 位精度，并且优于压缩。 在 256 个平方单位时，它们在 12 位精度下保持平衡，如果纹理坐标覆盖的区域比这个更大，则压缩在精度上领先。

实际上，对于大多数用例来说，任何一种都可能很好。

原文链接：Using Quantization with 3D Models

BimAnt翻译整理，转载请标明出处