谈谈3D Tiles(1):渲染调度

Cesium在2016年3月份左右推出3D Tiles数据规范,在glTF基础上提供了LOD能力,定位就是Web环境下海量三维模型数据。虽然目前3D Tiles还是Beta阶段,有不少硬伤,但3D Tiles数据规范于2016年9月30日开始了OGC标准化进程,积极成分还是很大。

之前的glTF时分享了个人对二进制格式的一些想法和谨慎的态度。3D Tiles简单说就是具备LOD能力的glTF。有了数据首先是提供API可以渲染,保证用起来,下一步就要了解该数据规范的具体特点,比如倾斜,矢量,点云,OSM等支持情况,项目实施和风险评估等。最后,作为一个数据规范,从数据生产到深层次应用,需要时间沉淀出完善丰富的解决方案。

本文主要集中在渲染调度层面。看完本文可能会觉得思路很简单。在实际应用中有很多细节,比如浏览时各种操作的差异,并发量,内存和显存管理,异步传输和Workers线程等等各种调优。思路简单,但要把这些小细节打磨好就不容易了。本文只讲诗和远方,鞋里的沙子自己来处理吧。

先看看如何加载3D Tiles数据,如上所示,Cesium提供了Cesium3DTileset类来管理,主要负责Tile的调度。在Cesium中,3DTiles就相当于一个Primitive的位置。

3D Tile表述

当我们创建一个Cesium3DTileset后,每一个Tile对应一个Cesium3DTile。如上根节点是root,content是根节点对应的文件名,这里是parent.b3dm,四个子节点,子节点对应的文件名分别为ll.b3dm……。

如上,在获取JSON对象后,首先创建rootTile根节点,然后在while循环中,以广度优先的方式遍历这个树,每个节点都有一个parentTile属性绑定父节点(根节点除外),同时有一个children数组,保存该节点对应的所有子节点。

这样,在初始化阶段,Cesium3DTileset中就保存了该3DTiles树上的所有节点及关联,当然此时只是属性信息,并没有加载数据内容,所以内存上还是可以接受。这就相当于我们读书,都会先看这本书的目录,了解一个大概。但个人认为,第一,没必要,实际上只需要找到根节点,下面按需顺藤摸瓜就可以(JSON在搜索节点上很麻烦);第二,如果数据量很大的情况下,初次加载全部节点是一个性能瓶颈。这是3D Tiles目前设计上的不足。

Cesium3DTile中通过一个简单的Cesium3DTileContentFactory工厂模式,目前主要提供四种类型。根据当前数据的具体类型(Type)来创建对应的内容(Content),本篇不涉及这块。初始化结束后,和之前glTF或primitive一样,基于状态的驱动流程:

如上是调度管理的逻辑,四个函数的作用大概如下:

  • processTiles
    • 处理Tile对应的DrawCommand状态,判断一些半透明等渲染顺序
  • selectTiles
    • 请求具体的b3dm数据,不同Type根据对应的类来完成数据的下载,根据LOD策略决定哪些Tile进入渲染队列。
  • updateTiles
    • 当前帧状态下遍历这棵树,调用该Tile对应的Model::update,完成数据的解析最终构造出DrawCommand
  • unloadTiles
    • 判断当前Tiles数目是否超过上限,卸载多余的Tile

在selectTiles函数中,首先是下载Tile对应的数据内容(b3dm后缀),通过contentUnloaded标识来判断,如果根节点的数据还没有下载,则request,然后返回。

一个简单的request,里面的信息量其实也不小,调用对应Cesium3DTile和Content对应的request来下载数据,这这里Cesium专门封装了一个RequestScheduler类来管理并发,我们最后在介绍这个。这里注意,当该数据下载完成后,则添加到两个队列:processQueue和removeQueue。

在Key2中,就是一个LOD策略的实现,上图给出了追加的逻辑注释。Cesium目前支持两种方式Add追加和Replace替换两种方式。Add方式较为简单,是Tiles求并的思路,而Replace是覆盖的思路,较为复杂,因为要控制父子节点直接的可见不可见,从代码来看,Cesium在这一块处理的比较简单,应该会出现闪烁的效果,不知道是否有人可以证实这个推测是否正确?

UpdateTiles看上去就比较简单了,指定具体的Content..update,这个过程就是之前Pimitive和Model对应的update。

对于可以卸载的Tile,则满足条件后调用unloadContent,但个人觉得这块设计的还是有些疑虑。首先,设计的很不错,从Content到BatchTable,到Model,以及Texture都提供了destory方法,但纹理还是应该提供纹理管理器的概念,解决重用纹理的释放。

让我学到的一点就是RequestScheduler类,大概思路是规定每次并发的最大请求数,每一帧收集下载请求但并不发送该请求,在下一帧对请求队列排序(相机远近),然后再发送。实现的很巧妙,方便管理。毕竟在海量数据下,有这样一个Manager来控制是很有必要的。

问题比较大的地方是删除上(因为没有大数据测试,仅从代码逻辑猜测)。第一,update和select两个都是异步或者workers线程机制,在数据量比较大的情况下会有内存泄漏。第二,Replace队列无脑删除,并不是根据当前的范围和LOD,这个在设计上是一个很大的缺陷,只考虑了可见不可见,但没有优化删除策略。

总体来说,作为一个开源项目,3D Tiles迈出了很坚实的一步,数据规范设计的很优雅,基于glTF也降低了学习成本。同时Cesium提供了渲染3D Tiles的接口,稍显不足的就是还没有成熟的,免费的数据生成工具,可以从osg转为3d tiles,这是目前最大的瓶颈。简单说,Cesium目前提供了基本技术和规范,但并没有提供完整的解决方案,同时还缺少基于3D Tiles的丰富的扩展和应用。当然,我们不能对一个开源项目要求苛刻,而且我相信,也希望Cesium后续后慢慢完善,前面把路走踏实了,慢一点都可以接受,路遥知马力,踏踏实实做事情方能立本,本立而道生,在这个物欲横流的世界,这么简单的道理,其实并不简单。

原文发布于微信公众号 - LET(LET0-0)

原文发表时间:2017-03-05

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏吉浦迅科技

DAY49:阅读Arithmetic Functions和Bitwise Functions

reads the 32-bit or 64-bit word old located at the address address in global or...

1013
来自专栏Ceph对象存储方案

对象存储基础概念

对象存储诞生之初 谈到为什么要有对象存储,必须聊聊对象存储诞生之前的两大存储模型:块存储和文件存储。 块存储主要是将存储介质的空间整个映射给主机使用的,主机如果...

3784
来自专栏鸿的学习笔记

如何设计一个良好的流系统?(下)

在Streaming 101中,作者引入了窗口和时间的概念,在本文中,作者为了解决流处理系统无法精确的处理结果的问题,提出了下面三个概念:

241
来自专栏腾讯Bugly的专栏

Redex 初探与 Interdex:Andorid 冷启动优化

导语 早在去年10月份,facebook就发布了介绍redex的文章,这个据说可以直接对apk做处理,既提高启动性能,又可减少安装包的利器让安卓开发者们都心动不...

3735
来自专栏玩转全栈

flutter全局数据共享通知方案

让我们先抛开Flutter这个平台说话,如果让你实现数据共享,你能想到的基础方案有哪些。

38318
来自专栏熊二哥

快速入门系列--TSQL-01基础概念

    作为一名程序员,对于SQL的使用算是基础中的基础,虽然也写了很多年的SQL,但常常还是记不清一些常见的命令,故而通过一篇博文巩固相关的记忆,并把T-SQ...

1908
来自专栏GopherCoder

专栏:013:我要你知道实时票房.

1283
来自专栏chenssy

【死磕Sharding-jdbc】---分布式ID

传统数据库软件开发中,主键自动生成技术是基本需求。而各大数据库对于该需求也提供了相应的支持,比如MySQL的自增键。 对于MySQL而言,分库分表之后,不同表生...

872
来自专栏斑斓

MongoDB的数据建模

MongoDB是一种面向Document的NoSQL数据库,如果我们还是按照RDB的方式来思考MongoDB的数据建模,则不能有效地利用MongoDB的优势;然...

3096
来自专栏linux驱动个人学习

内存的分类

一:SDRAM SDRAM(Synchronous Dynamic Random Access Memory),同步动态随机存储器,同步是指 Memory工作需...

2954

扫码关注云+社区