支持的数据结构
目前Cesium支持的Cesium3DTileContent目前支持如下类型：
Batched3DModel3DTileContent
Instanced3DModel3DTileContent
PointCloud3DTileContent
Composite3DTileContent
其中Composite3DTileContent是复合数据，PointCloud3DTileContent是只包含FeatureTable和BatchTable的点云数据（从官方给的数据结构来看，我没有亲自测试）。
本节主要以Batched3DModel3DTileContent类型，介绍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
数据结构大概布局如下
在这里，Cesium3DTileBatchTable和之前的BatchTable在思路上都是一样的，都是将属性值保存到纹理中来来使用。但Cesium3DTileBatchTable提供了一个规范的流程，让用户通过表达式的方式，很容易的创建出这张tile_batchTexture这里。
batchtable结构
如上是batchtable的内容，以及3d tiles给出的文档信息，其实batchtable就是一个json对象。同时，batchTable会根据该json的长度（id个数）创建一张对应的tile_batchTexture，用于存储对应的属性。同时，有多少个id就有有多少个对应的Cesium3DTileFeature对象，这可以认为是batchtable的访问器，以id为唯一标识负责batchtable的读写操作。
有了数据以及数据的读写方法，就需要提供如何读写的规范，这就是Cesium3DTileStyle类的责任。目前默认指定根据json指定颜色，比如根据json对象中的高度值，实现一个根据高度值指定对应颜色的范围分段效果。当然，如果你知道如何修改shader，那你可以修改代码创建自己需要的映射关系，实现对应的效果。
解析
如上是这个语义解析树的类结构，也是解析过程的一个示意图，最终每一个条件都封装为一个statement，实现自己的判断标准。
每次遍历树上所有statements，找到满足条件的Node。对比时先看左边Node节点的left，所用的属性为Height，这样，通过feature对应id找到batchTable的Height值，满足条件则获取对应的color：purple，不满足就继续。
前面提到feature相当于一个访问器，获取该值后，直接传到batchtable对应的batchValues，其中这就是该纹理对应的imageData。Feature对这个读写操作进行了属性封装，方便用户的调用。
结束，以上是
Batched3DModel3DTileContent解读
最后，借鉴‘法克鸡丝’大佬的源码分析
