osgb转json_CesiumLab--倾斜数据的终极优化方案

最后修改时间:2020-10-29 11:55:41

上个月去了客户那边实际感受了一下倾斜大数据(百G左右)的实际使用场景。客户的客户对当前的结果不满意,原因有几个:1,加载速度太慢,数据从不清晰到清晰要等待好久;2,崩溃的概率比较大。3,上层的点云数据很不好看。

经过现场分析,给出这样的临时解决方案:

1, V2版本生成的目录里pnts目录修改个名,那么就不会加载点云数据

2, 在服务端替换iis服务,使用nginx 发布静态服务,并且开启gzip压缩设置

V2版本生成的目录

这两个都是短期的方案,如此操作之后,果然是快了一些,因为zip压缩后,传输的数据能节省小一半,还是非常有必要的。

当然我也是发现了一些其他问题,比如在我们V2版本重建的顶层块里出现了一些超大的块,竟然达到13M左右,这种文件加载起来必然慢。这也意味着V2版本的重建对于较大数据来说还是有缺陷的。所以我当时也承诺了会优化处理方案。

从去年我都说了,我们不太愿意在倾斜处理上耗费时间过多,原因有二:1,现在的工具smart3d 等倾斜生产工具都可以直接输出3dtiles。2,还有一些开源或者其他转换工具也同时存在。 但是从我们lab的后台统计来看,倾斜处理的使用次数占到小一半左右,也就是这个处理依然是需求最大的,至少其他免费工具并没有给出很好的解决方案,还是期待我们的处理。

19年5月倾斜处理重写了V2的版本,也就是当前大家使用的版本,这个版本我们使用点云做了顶层块的合并处理,解决一些数据加载马赛克的问题,而且使用多线程优化加速了处理过程。这一版当然也是大家吐槽比较多的:1,点云的确不好看。2,多线程带来的是处理时的内存需求急剧增加 , 这块需要解释下0表示线程数=cpu核心数,每个核心处理一个Tile,会把这个Tile全部载入内存,但是对于精度较高的倾斜数据,一个Tile内的数据量都可能上G,纹理解压后再翻10倍左右,导致内存使用很夸张。当时为何这么做?是因为当时设计的时候,设想尽力去减小渲染批次,对于原来倾斜中的小数据块(几十K的数据,包含的小于1024*1024的纹理)会做合并处理,所以每个Tile都是完全读入内存再做处理。 现在看来,这一版还不是最完美方案,客户依然是不满意的。

所以上个月回来之后,再次重写倾斜处理V3(没办法就是喜欢推到重来),这次的设计目标和需求是: 1,处理过程没必要合并小数据块,加速数据载入数据, osgb 对应 b3dm的一对一转换(又恢复到V1版本的方案,迄今还不断有人问我要V1的处理程序,看来V2的却有点走弯路了)。2,对于顶层块的合并处理,并且输出结果一定是三角网(b3dm)。

针对第一条需求:

我们再也不必纠结整个Tile的载入到内存,转一个osgb,即可清空内存占用,这块我花费了1天多了就重新实现了整个过

你可能感兴趣的:(osgb转json)