Cesium原理篇:3D Tiles(2)数据结构

时间:2022-01-16 05:05:05

      上一节介绍3D Tiles渲染调度的时候,我们提到目前Cesium支持的Cesium3DTileContent目前支持如下类型:

  • Batched3DModel3DTileContent

  • Instanced3DModel3DTileContent

  • PointCloud3DTileContent

  • Composite3DTileContent

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

渲染

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

 Cesium原理篇:3D Tiles(2)数据结构

      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


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

 Cesium原理篇:3D Tiles(2)数据结构

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

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

 Cesium原理篇:3D Tiles(2)数据结构

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

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

 Cesium原理篇:3D Tiles(2)数据结构

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

 

Cesium原理篇:3D Tiles(2)数据结构

 

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

Cesium原理篇:3D Tiles(2)数据结构

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

Cesium原理篇:3D Tiles(2)数据结构

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

Cesium原理篇:3D Tiles(2)数据结构

Instanced3DModel3DtileContent

      还是先看看Cesium给出的布局结构:

 Cesium原理篇:3D Tiles(2)数据结构

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

Cesium原理篇:3D Tiles(2)数据结构

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

Cesium原理篇:3D Tiles(2)数据结构

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

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

      关于Content就介绍到这,结合上一篇,应该能对3DTile有一个全面的了解。下次以个人的经验来谈一下3D Tile好和不好的部分,当作完结篇。

Cesium原理篇:3D Tiles(2)数据结构