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好和不好的部分，当作完结篇。