Cesium源码解析五（Quantized-Mesh(.terrain)格式文件在CesiumJS和UE中加载情况的对比）

快速导航

Cesium源码解析一（搭建开发环境）
Cesium源码解析二（terrain文件的加载、解析与渲染全过程梳理）
Cesium源码解析三（metadataAvailability的含义）
Cesium源码解析四（metadata元数据拓展中行列号的分块规则解析）
Cesium源码解析五（Quantized-Mesh(.terrain)格式文件在CesiumJS和UE中加载情况的对比）

1.前言

  自从开始做 terrain 地形文件的管理，就总是会遇到在 CesiumJS 和 UE 中同时适配的问题。经过一段时间的尝试，总算找到了规律，特此来记录一下。

2.terrain文件的元数据标准格式

  本文涉及的内容，只有理解了元数据，才能真正明白其中的奥妙。关于元数据，我们在第四篇，Cesium源码解析四（metadata元数据拓展中行列号的分块规则解析） 进行了非常详细的解释，有兴趣的可以移步查看。
  因此我们在这里，就不详细展开了。直接给出结论，元数据会出现在三个地方：

1. layer.json 中的 available 参数
2. 0/1/0.terrain 和 0/0/0.terrain 的 metadata 参数
3. 第10级所有的瓦片的 metadata 参数

3.元数据的作用

  元数据的主要作用是，首先是构建四叉树，然后是决定了去不去请求新的 terrain 切片。

4.元数据对CesiumJS和UE的不同影响

  其实 UE 中用的也是 Cesium 官方出的插件，名字叫做 Cesium for Unreal Engine。虽然同源，却有截然不容的表现，我们依次来看。

4.1 UE中地形会影响影像的加载

  当元数据在所代表的 terrain 文件不存在时，CesiumJS 中不会报错，且也不影响影像图层的加载。但在 UE 中会影响影像图层的加载。即，这种情况下，在 CesiumJS 中，随着层级的放大，能够请求更高层级的影像切片，但在 UE 中，影像切片就停留了在那一层，不会去请求更高层级的了。
  举个例子，我们的数据是这样的：
影像数据有18级： 0 1 2 …18
terrain数据有10级：0 1 2 …10
第10级的terrain的元数据向下记录了四层

注意此时的情况，第10级向下记录了四层，但是那四层数据实际上并不存在

当在 CesiumJS 中缩放到第11级时，地形仍在10级，但影像到了11级
当在 CesiumJS 中缩放到第12级时，地形仍在10级，但影像到了12级
当在 UE 中缩放到第11级时，地形仍在10级，影像也在10级
当在 UE 中缩放到第12级时，地形仍在10级，影像也在10级

注意此时对CesiumJS并没有影响，但在UE中明显不正常，影像没有往下分。

4.2 UE中对元数据的要求不一定非得是标准格式

  这里值的一提的是，我们是用 github 上的 CesiumTerrainBuilder 来生成 terrain 的，但是这个工具是有 bug 的，它生成的数据，只是在 layer.json 中写了元数据，并没有在 0/1/0.terrain 和 0/0/0.terrain 的元数据中写入，也并没有在第10级的切片中写入。因此我们按照第三篇的介绍，修改了这个工具。碍于公司相关要求，这个工具没法放到外网上来。
  现在我们来说说在 UE 中另一种可用的元数据的组织形式。那就是每一块 terrain 瓦片的元数据，都记录着这这一块瓦片对应的下一级的四块瓦片的行列号范围。什么？你问为什么是四块？那是因为这是四叉树啊。

但是注意，这种形式无法在CesiumJS中使用，CesiumJS中必须使用标准格式。

5.总结

  有很多人估计都是使用 CesiumLab 提供的工具来生成 terrain 的，并没有关心过这里面的原理。因此本文算是抛砖引玉吧，因为CesiumTerrainBuilder 是用 C++ 写的，本人水平太渣，不会写 C++ ，因此只负责搞理论，具体的修改是由写 C++ 的同事负责的。有兴趣的同学可以试一试，回见~