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天多了就重新实现了整个过