Cesium原理篇：3D Tiles（2）数据结构

      上一节介绍3D Tiles渲染调度的时候，咱们提到目前Cesium支持的Cesium3DTileContent目前支持以下类型：

• Batched3DModel3DTileContent

• Instanced3DModel3DTileContent

• PointCloud3DTileContent

• Composite3DTileContent

      其中Composite3DTileContent是复合数据，PointCloud3DTileContent是只包含FeatureTable和BatchTable的点云数据（从官方给的数据结构来看，我没有亲自测试）。本节主要以Batched3DModel3DTileContent和Instanced3DModel3DTileContent两种类型，介绍一下3DTiles的数据结构和核心技术点。

渲染

      结合上一节，先给出一个流程图，建议大图边看边思考。其中红线是代表状态变化。TileContent是一个抽象概念，具体是它的继承类Batched3DModel或Instanced3DModel来完成具体的功能，而每个具体的Content会根据本身的数据结构的差别而有所差异。

 

      3D Tiles也是基于状态，从UNLOADING开始，经过一系列的request，完成最初的数据加载过程，结束LOADING状态，进入Pocessing过程，也就是数据解析。数据解析完后进入READY状态，经过selectTile，最终调用Content对应的update方法，构造最终的drawcommand，加入渲染队列。固然，若是有须要释放的Tile，则在unloadTiles中处理。细心的人会发现Pocessing和Ready状态。最终调用的都是update方法。这里解释一下：3D Tiles中主要的数据部分就是glTF，而glTF也是基于状态管理的，不管是glTF的解析仍是构造DrawCommand，只是state不一样，都是在update方法中完成的。如上图，这里也用橙色箭头作了说明。

      如上给出了一个相对完整的过程，Content的内容主要是glTF，这块咱们以前也介绍过，因此下面主要集中在b3dm中BatchTable和FeatureTable。

Batched3DModel3DTileContent

      先看看数据结构的大概布局：

 

      如上，一个header头，用来讲明该数据的类型，布局和具体数据内容。看一下body部分，glTF，之前介绍过。因此，只剩下batchTable了。若是你看看Cesium之Batch篇，你会发现，其实Cesium很早就已经在用batchTable概念了。

      在这里，Cesium3DTileBatchTable和以前的BatchTable在思路上都是同样的，都是将属性值保存到纹理中来来使用。但Cesium3DTileBatchTable提供了一个规范的流程，让用户经过表达式的方式，很容易的建立出这张tile_batchTexture这里。

 

      如上是batchtable的内容，以及3d tiles给出的文档信息，其实batchtable就是一个json对象。同时，batchTable会根据该json的长度（id个数）建立一张对应的tile_batchTexture，用于存储对应的属性。同时，有多少个id就有有多少个对应的Cesium3DTileFeature对象，这能够认为是batchtable的访问器，以id为惟一标识负责batchtable的读写操做。

      有了数据以及数据的读写方法，就须要提供如何读写的规范，这就是Cesium3DTileStyle类的责任。目前默认指定根据json指定颜色，好比根据json对象中的高度值，实现一个根据高度值指定对应颜色的范围分段效果。固然，若是你知道如何修改shader，那你能够修改代码建立本身须要的映射关系，实现对应的效果。

 

      如图，从字面意义来看，指定了范围分段的规范，用到了Height属性，根据conditions中对应的Height区间映射到对应的颜色。咱们用肉眼看懂了，那代码是如何完成这个语义解析呢？

 

 

      如上是这个语义解析树的类结构，也是解析过程的一个示意图，最终每个条件都封装为一个statement，实现本身的判断标准。

      每次遍历树上全部statements，找到知足条件的Node。对比时先看左边Node节点的left，所用的属性为Height，这样，经过feature对应id找到batchTable的Height值，知足条件则获取对应的color：purple，不知足就继续。

      前面提到feature至关于一个访问器，获取该值后，直接传到batchtable对应的batchValues，其中这就是该纹理对应的imageData。Feature对这个读写操做进行了属性封装，方便用户的调用。

Instanced3DModel3DtileContent

      仍是先看看Cesium给出的布局结构：

 

      batchTable，glTF这些都是已有的内容，让咱们眼前一亮的是featureTable，Cesium提供了Cesium3DTileFeatureTable来封装。

      占是一个具体的featureTable内容。不难理解这个数据的实例化内容就是Position，Cesium经过ModelInstanceCollection来实现Model的实例化，咱们以前在Cesium之Instance中介绍过。这里咱们重点看看Position实例化矩阵的推导原理，强化一下理解的深度。

      如上是对应的Shader和相关的uniform片断。灰选部分是相机的视图矩阵，而rtcTransform则是中心点(_center)对应的矩阵，czm_instanced_model是传入的实例化矩阵，czm_instanced_nodeTransform不讨论，是父子节点之间相对位置对应的矩阵。根据Shader的公式，咱们不可贵出，a_position是相对模型中心点的相对位置，而czm_instanced_model则是当前单个模型的中心点对应模型集合中心点的矩阵。

      查看了一下Instanced3DModel3DTileContent实例化对应矩阵的计算过程，数据存储时仍是每个模型中心点的经纬度信息，在内部转成相对集合中心点的相对矩阵。

      关于Content就介绍到这，结合上一篇，应该能对3DTile有一个全面的了解。下次以我的的经验来谈一下3D Tile好和很差的部分，看成完结篇。