前端 3DTiles 效率优化（2）—— 采用 Draco 压缩模型

Draco 是一个用于网格压缩的 glTF 扩展，它是谷歌开发的一个开源库，用于压缩和解压缩 3D 网格，以显著减少 3D 内容的大小。它可以压缩顶点位置、法线、颜色、纹理坐标和任何其他一般的顶点属性，提高了在 web 上传输 3D 内容的效率和速度。

这意味着更小的文件大小和更快的流，特别是在使用 3D Tiles 的情况下，当需要新的 Tiles 或新的层次细节时，3D Tiles 经常会流传输新的 glTF 模型。

Khronos glTF Draco 压缩扩展

glTF 现在有了KHR_draco_mesh_compression扩展，它支持加载包含经过 Draco 压缩几何图形的 buffer。从 Cesium1.44 开始，Cesium 通过利用谷歌的 [开源 JavaScript 解压库，来支持加载用 Draco 压缩数据的 glTF 资产。

使用压缩后的网格可以减少 glTF 模型的文件大小，这意味着这些资产占用更少的空间，可以下载更少的数据，流传输速度更快。为了说明差异，我们使用Draco 编码器压缩了以下文件，所有属性的默认压缩级别为 7。

这是 glTF 2.0 Draco 压缩后的 Ceisum 运奶车模型与 glTF2.0 Cesium 牛奶车模型的比较，两者都包含纹理和动画。

Draco 压缩后的	未压缩的	文件
2.1 KB	2.2 KB	CesiumMilkTruck.gltf
14.0 KB	107 KB	0.bin
418 KB	418 KB	CesiumMilkTruck.png

由于扩展只压缩几何形状，因此纹理负载 (CesiumMilkTruck.png) 保持相同的大小 (418kb)。而且对 JSON 元数据.gltf 文件的影响也很小 (2.1 KB vs. 2.2 KB)。

接下来，这里是 glTF 2.0 Draco 压缩的越野车模型与 glTF2.0越野车模型的比较，后者是一个几何形状更复杂的网格。

Draco 压缩后的	未压缩的	文件
281 KB	375 KB	Buggy.gltf
0.824 MB	7.39 MB	Buggy0.bin

我们看到一个更小的.gltf 文件 (824 KB 对 391 KB)，因为每个图元只需要更少的 JSON 元数据，以及一个小得多的.bin 文件，主要就是因为可以使用该扩展来压缩大量的几何图形。

Cesium 3D Tiles

在使用 3D Tiles 时，Cesium 经常会发出网络请求，并传输新的 3D 内容。现在，可以使用 Draco 扩展压缩每个 tile 的 glTF 内容，使其用更少的数据以更快的速度传输。下面，我们使用 glTF 2.0 将 12.8 GB 包含 110 万个纽约市建筑的 City GML 数据处理成 3D tileset, Draco 压缩级别为 5。

压缩方式	文件总大小
用 Gzip 压缩的 glTF 2.0	738 MB
用 Draco 压缩的 glTF 2.0	179 MB
同时用 Gzip 和 Draco 压缩的 glTF 2.0	149 MB

在加载时间方面，虽然在执行加载和编译 Draco 模块 Web 程序集时，我们会在一开始受到很小的影响，但之后所有的 tile 都会比没有 Draco 压缩时更快地进行流处理和解压缩。下面是使用仅使用 gzip 压缩的 glTF 2.0 与使用 Draco 压缩和 gzip 的 glTF 2.0 的 tileset 的总加载时间的比较。*

gzip 压缩的 glTF2.0	Draco 压缩 +gzip 的 glTF2.0

瓦片集大小：738 MB	瓦片集大小：149 MB
加载时间：18.921s	加载时间：10.548s

* 动图以 2 倍的速度加速以供演示

性能优化

Cesium 对 Draco 解码的实现利用了 Web Assembly 的异步解码和 GPU 上的去量化，这意味着并行解码多个模型 (或部分模型)，以及更少的总体内存使用。

并行解压缩

Cesium 利用 Web Worker 并行解码多个 mesh。对于 3D Tiles，这意味着多个瓦片可以同时进行流处理和解码。此外，mesh 的每个图元 (或部分) 都可以单独解码，以便更快地解码复杂模型。我们可以检索编码 buffer 的每一段，并将数据传递给不同的 worker，以便在将 mesh 呈现给主线程所需的数据返回之前并行地异步解码。

在浏览器的支持下，我们加载并编译解码模块 Web Assembly 二进制文件，并在多个 worker 之间共享它，这进一步提高了解压缩的速度，而不是使用纯 JavaScript 解决方案。

GPU 的去量化

Cesium 还在 GPU 上解码一些属性，在主线程之外解码，使用更少的内存。顶点属性通常存储为 32 位浮点数，如位置属性数据，可以解码为量化的 16 位整数值。此外，对于单位向量的属性，如法线，我们可以将其解码为oct-encoded的数据。

在 GPU 上解码时，我们跳过 Draco 解码器模块中的量化或八面体转换操作，而是检索和存储任何转换常量。较小的解码数据可以传递到 GPU 中，在渲染时在着色器中执行去量化或 oct 解码操作。这将导致更小的内存占用，无论是在 CPU 上运行的主应用程序线程中，还是在 GPU 上并行运行的主应用程序线程中。

当在 GPU 上执行前面提到的纽约 3d 模型数据的去量化时，大约在 GPU 上节省了 52% 的显存占用。与完全解码的 Draco 解码模块相比，文件大小没有区别,没有视觉质量的差异,不影响总加载时间。

比较项	Draco 普通压缩	Draco 在 GPU 上用去量化压缩
显存占用	119MB	57MB
瓦片总加载时间	7.45s	7.44s