谈谈3D Tiles(3):个人总结

个人结论:目前,在演示层面,3D Tiles问题不大,但项目应用上就不够成熟了,所以问问自己,你是想吃瓜呢还是想吃螃蟹?

好的方面

数据规范

我非常喜欢glTF的整体设计,概括有四点:第一,数据块(Buffer)连续,保证了读写性能;第二,提供了视图(View)和访问器(Accessor)的概念,在不损失数据块完整性的前提下提供类型信息和读取规范,保证了兼容性;第三,逻辑层和数据层分离,两者尽量分离,比如用户想要增加一种风格,只会牵连到逻辑层的调整,不会影响数据层的读写,保证了独立性;第四,逻辑层,也就是业务层是JSON形式,保证了扩展性。

3D Tiles在逻辑层,也就是JSON部分增加了FeatureTable和BatchTable,以及LOD(tileset)概念,并对应提供了header(二进制存储)。从数据规范角度来看,继承了glTF优秀的部分,同时考虑了倾斜,点云,后续也会支持OSM,从数据类型的支持上也比较到位。

Cesium渲染调度

目前,WebGL技术+三维球开源框架+大数据渲染,如果拿这三个条件来过滤,除了Cesium并没有其他选择,所以这块要求不能太高。

在这个要求下,通过前两篇的介绍,Cesium在这块的框架设计很清晰,基于状态而不是事件驱动的方式来管理,简化了代码复杂度,在逻辑上没有明显的冲突。

在代码设计上,提供了RequestScheduler,管理请求队列的数量和优先级,debugShowContentBoundingVolume用来查看TileBounds,Cesium3DTileStyle可以通过表达式指定渲染风格,这些产品思路和技术细节都值得我们学习和借鉴的。

tileBounds效果,对开发人员很友好

风格表达式,提供可视化效果

欠佳

LOD

Cesium提供了Add和Replace两种LOD策略。我认为只需要Replace一种就足够了,Add是一个鸡肋,不能解决大数据下性能的问题,而Cesium偏偏对Replace支持的不好。整个树结构自始至终都完整保留,卸载时只会删除数据内容,节点属性信息仍然存在。另外删除逻辑过分简单,某些浏览方式下应该会有闪烁问题。

刚才提到节点的属性信息是初始化一次性加载,如果数据量很大,比如城市级别,这个tileSet会很大很复杂,这点在设计上有点耿直。

数据规范

这个真的是成也萧何败萧何。首先,glTF是针对单个模型的情况,强调数据的完整性,独立性。但3D Tiles是一个树关系,每个Tile只是其中的一个Node。打个比方,一棵树上,节点是叶子,但现在节点对应的是一颗小树。所以,站在3D Tiles的角度,glTF有很多过度设计的部分。比如shader,animation,scenemanager等,还有纹理部分,不能说做不到纹理公用,但确实在设计上没有体现。

在渲染调度上,3D Tiles和glTF都是基于状态,你可以想象,虽然在代码逻辑上清晰,但在运行时上,对浏览器来说是一个负担。明明一次性能做好的事情,非要分成好几个任务,还美其名曰敏捷。我觉得一个Tile的解析尽可能在两个Promise,一个Workers搞定,不拖累主线程,事情也做的干净利索。

FeatureTable实例化的存储设计没有问题,Cesium对应的接口欠妥,要么提供清晰通用的规范,要么只关心存储结构,让用户自己扩展实现实例化部分的Render。

作为一个大数据的数据规范,glTF可以提供压缩机制,当然Web端解析性能的损耗需要评估,个人认为压缩的收益太大而无法拒绝。

可用性

缺少免费好用的生成工具,并没有形成一个成熟的解决方案。基于大数据的扩展能力也很少,只有单体化和实例化,属性查询这些基本能力。不知道是否支持2.5维场景,如果能支持,那就牛了。

总体感觉3D Tiles推出的有点仓促,很多地方还需要打磨,感觉战略压力大于实际价值,属于占坑行为。希望后续能够大力推动,能够早日有成熟的完整方案和高级功能。

开源

有感于最近的一些亲身经历,也看了看threejs,Openlayers,Leaflet,Echart等项目,也在思考这些优秀的开源项目之所以优秀,到底有没有一些共性。

就用两句话来概括:所谓的开源(或规范),不是把自己的东西拿出去,而是把别人的东西拿进来。当我们把一个东西放到github上开源,我们以为这个工作到此结束了,其实它才刚刚开始。

最后,又想到了论语里面的那句“君子务本,本立而道生“,就算从人的角度,对上面两句话的解释吧。

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

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

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

扫码关注云+社区