3DTiles效率优化—采用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 |
原文来自: https://bingqixuan.github.io/2019/02/22/3DTiles%E6%95%88%E7%8E%87%E4%BC%98%E5%8C%96%EF%BC%882%EF%BC%89%E2%80%94%E2%80%94%20%E9%87%87%E7%94%A8Draco%E5%8E%8B%E7%BC%A9%E6%A8%A1%E5%9E%8B/
WEBGL学习网 » 3DTiles效率优化—采用Draco压缩模型总结