CesiumLab--倾斜数据的终极优化方案
2020-03-06 14:51:17
3893次阅读
1个评论
最后修改时间:2021-01-19 11:53:12

上个月去了客户那边实际感受了一下倾斜大数据(百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天多就重新实现了整个过程,测试完效率惊人,这种急速处理方式下,70G数据(大约31w个osgb)仅需要2.5小时转换完毕,这个速度和拷贝一遍这个目录的时间差不多,也就是实际的耗时都是在硬盘io上,因为的确没做什么复杂运算,只是转个格式而已。内存占用非常小,在1G以下。


针对第二条需求:
   这个没有前面的 海量模型处理(关于海量模型处理的文章)的技术积累,还真做不了这个事情. 具体的三角网合并精简算法不再细说,我们只看下最终的重建效果:


  

测试数据约10平方公里,940+个 Tile, 70G左右


  

最顶层块的包围盒


  

下拉几级之后的包围盒


  

处理完成的目录,tile开头是原始osgb一对一得到目录,top是我们重建的顶层块目录


这个重建效果还是达到了初步的设想,这个数据重建顶层块的时间大约耗费了2.5小时,再加上转原始osgb,总计这块处理完成大约耗时5个小时左右。


数据处理到这里并没有结束,又发现了一个问题: 这个数据处理完毕之后,浏览一会之后,明显感觉cesium会卡顿, 很奇怪是内存中的tile并不多,经过仔细分析,虽然载入到内存中tile(调试面板里的Content Ready)数据量不多,但是总的Tile对象(调试面板里的Total)却达到了31w个。


    瓦片分析工具


这也是我以前忽略的问题,影响cesium的性能除了本身每个Tile的数据量之外,还有这个索引Tile的个数,因为cesium毕竟是js实现的引擎,每个Tie即便没有请求资源,但是也会创建js的Tie对象,Cesium的数据载入淘汰都需要对整颗索引树进行遍历,当索引过大,还是会严重影响性能。如果你手头有contextcapture导出的3dtiles,你会发现他的每个b3dm都对应了一个json,原本还挺鄙视这种做法,因为增加了额外的网络请求,现在看来,人家是故意而为之,所以经过修改,我们现在新版输出的json(海量模式下)会对目录里一个b3dm(非叶子节点)生成一个json。修改之后果然不卡了。(这个问题做了3dtiles转换一年多才发现,实在汗颜,当然主要问题还是缺少大的测试数据,一般的数据没有这么多块,自然也体会不到这个差异)


  

多json的生成


还有一个问题没有解决,就是倾斜的崩溃问题:
我们来估算下资源消耗,我们目前常见分辨率都是1920x1080屏幕,如果我们用256x256的影像切片铺满,最少大概需要32块,考虑我们视角位置不可能刚好是瓦片分隔处,所以常见的我们还要多显示一圈数据(7+7+4+4=22)。也就是平面四叉分隔下,一屏幕最少需要54块填满。我们换成倾斜数据,假设倾斜的显示精度和256x256的平面影像一致,但是倾斜是立体的,显示的时候必然依据和相机的距离精度递减,简单来估算,距离相机最近的是54个块,稍远一点是27个块,再远一点是14个 以此递减(实际计算是按照精度,而不是依据这种估算的)估算下来也就是最终最多显示100多个块(selected)是合理的。因为倾斜是金字塔数据,显示这屏数据的时候,我们还要创建它们的父块资源,那么实际访问的是200多块(visited)。


如果倾斜都是平面的,那么每块的纹理都是256x256,如果都是立方体,那么为了保持这个精度都是256x256x6,但是倾斜我们拍摄的主体一般都是室外建筑或者地形甚至工厂管道,并不是那么简单的几何体,它都有沟沟壑壑,如果每个三角形都是保持这种精度,那么纹理必要要大于 256x256x6,这种你分析下倾斜输出的osgb即可知道,高级别的数据里面大部分存储都是2048x2028的纹理,这种纹理一张就需要占用12M显卡资源,200多块就要占用接近2G的纹理资源。下来我们再考虑一层底图影像的资源(几百M),还有其他几何体资源(几百M)。所以数据精度稍高,显卡占用就超过3G,而一般低端显卡显存(或者移动端)就这么大点,不崩才怪。 而且很多人因为嫌倾斜不清晰,设置maximumScreenSpaceError为8(默认16)甚至更小,这会导致加载和显示数据再次翻倍,最终结果就是显存消耗更大,更容易崩溃.


    某视角下的资源消耗


频繁崩溃的原因如果定位了,那么解决方式也就明确了,减少数据资源消耗,尤其是纹理的资源消耗,这里有一个严重误区, 一张1024x1024的jpg硬盘大小 只有100K, 我们把它压缩到70K是不是就降低了显存消耗? 显卡并不能直接使用jpg格式去创建资源,也就是需要在cpu和内存里把jpg解压缩,这张图片解压缩后的大小是固定的也就是3MB,创建显存也就是占用3MB,所以显存只跟你图片分辨率有关系,而和你的图片格式甚至压缩参数没关系. 但是现代显卡为了解决这个问题,提出了若干种显卡能使用的压缩格式,最早也是最常见的就是 dxt,具体可以百度,但是这种方式的压缩率是固定的(8:1) 左右,也就是1024的图片压缩成dxt实际占用到 400K,这个反倒比jpg大不少,但是他真的是节省显卡资源. 我们lab的支持的几种纹理优化方式列表如下:


  

lab上的纹理格式


1, 默认 保留原始纹理格式(osgb里一般默认是jpg)


2, 减小总量 纹理格式输出为webp
最大的减小纹理传输数据量,比jpg压缩还会少20%,但是不减小显存消耗


3, 减小显存 纹理格式输出 ktx (实际是dxt压缩)
减小显存消耗,但是纹理存储数据量会增加到4倍左右


4, 综合优化 纹理格式输出crn (基于dxt之上的二次压缩)
减小显存消耗,纹理存储接近默认的方式


扯了这么多,估计没人愿意看,谁关心你错了多少次,熬了多少夜,只要结果,ok,满足你们,我们说下倾斜处理的结论:


    倾斜处理参数表


这张表对于实在看不明白的人 或者 懒得看的人一个最佳方式,根据你的数据以及网络方式选择 对应一行的处理参数。我们再逐个解释下:
1, 三角网压缩(draco)
draco压缩是一种非常高效的压缩方式,同一数据源,默认处理为70G,开启 draco压缩为37G 。但是注意压缩率并不是 70:37,因为draco 只针对顶点数据,这两个值还包含纹理数据(大约为30G),所以实际的压缩率为(70-30):(37-30)。 可见这个压缩率还是挺高的。
结论是:如果数据最终是公网发布的,那么还是要做下draco压缩,大大节省带宽(50%左右)。但是如果是本地局域网,可以不做压缩,因为压缩为有损压缩,数据质量会降,降低的不明显。
如果既要保证原始原始质量,又要公网发布,那么一定开起公网服务器的 gzip压缩,能节省(20%左右的带宽)


2, 纹理压缩方式
上述的70G数据,开起draco+webp之后为31G,也就是做了webp压缩,比原始不压缩的纹理小了6G, 原始为30G, 压缩率为 30:(30-6) 差不多相交默认(jpg)节省 16% 左右的纹理,这也是webp的优势。
如果数据总量较小的前提下,又是公网传输,我们只考虑传输效率,那么做下webp压缩,进一步提升数据加载速度。
如果数据总量较大,那么无论是否是公网传输,我们第一位考虑的就是系统稳定性,那么尽可能的节省资源,最好做crn压缩。
但是这块又有个比较尴尬的问题,crn的压缩实在是慢,1024*1024的crn的压缩速度在秒级,数据较大的情况下,这个处理速度的是个灾难,关于这个我们未来会给出解决方案,敬请期待。


3,海量模式(CesiumLab V2.2.0版本改为重建顶层)
海量模式其实做了两个事情:1,合并顶层块 + json分离。当然json分离我前面也提到了它的影响。下面我们主要说合并顶层块。
合并顶层块这个主要针对的Tile目录过多的情况下,一般大于8个还是有必要合并一下的,当然现在也见过一些倾斜生产的软件,输出的本身Tile个数不是太多,那么这种实际没必要合并。
如果顶层块太多,但是不合并,那么带来的问题就是顶层类似马赛克一样刷新显示,而且资源得到不释放,比如上述的示例数据有970块,假设这些块每个的纹理是1M(大约512*512)纹理,那么这个就是很可观的资源浪费。而且一旦显示顶层层级,cesium的command过多,也会很卡。
目前我们合并速度还是比较慢,大约合并重建一个块需要30s,比如上述970个Tile块,那么待合并的顶层块有1/3左右,也就是330多个块,那么需要的时间大约为 (330 * 30 s)=170分钟左右,这个速度未来我们也会优化,给出加速方案。


最后再说几个影响加载效率的关键参数:
1, maximumScreenSpaceError
这个参数默认是16,只要是lab输出的数据,我们已经考虑这个默认值了,所以一般情况下,不需要修改。


2,skipLevelOfDetail
这个参数默认值是 true,是Cesium在1.5x 引入的一个优化参数,这个参数在金字塔数据加载中,可以跳过一些级别,这样整体的效率会高一些,数据占用也会小一些。
但是带来的异常是:1) 加载过程中闪烁,看起来像是透过去了,数据载入完成后正常。2,有些异常的面片,这个还是因为两级LOD之间数据差异较大,导致的。
当这个参数设置false,两级之间的变化更平滑,不会跳跃穿透,但是清晰的数据需要更长,而且还有个致命问题,一旦某一个tile数据无法请求到或者失败,导致一直不清晰。
所以我们建议:对于网络条件好,并且数据总量较小的情况下,可以设置false,提升数据显示质量。


3, preferLeaves
这个参数默认是false,同等条件下,叶子节点会优先加载。但是Cesium的tile加载优先级有很多考虑条件,这个只是其中之一,如果skipLevelOfDetail=false,这个参数几乎无意义。所以要配合skipLevelOfDetail=true来使用,此时设置preferLeaves=true。这样我们就能最快的看见符合当前视觉精度的块,对于提升大数据以及网络环境不好的前提下有一点点改善意义。


4, maximumMemoryUsage

这个参数默认是512,也即是当几何体和纹理资源大于512MB的时候,Cesium就会淘汰掉当前帧中没有visited的所有块,这个值其实很小,也是cesium为了避免资源占用过高的一个保障,不过上述我们也估算过最差情况下,没有做纹理crn压缩的情况下,这个值很容易被超过,导致很多人误以为cesium的淘汰没有效果。这个值如果设置的过小,导致cesium几乎每帧都在尝试淘汰数据,增加了遍历的时间,也同时增加了崩溃的风险。这个值如果设置的过大,cesium的淘汰机制失效,那么容易导致显存超过显卡内存,也会导致崩溃。这个值应该处于最差视角下资源占用 和 显存最大量之间。

结论:这个参数要根据当前显卡显存来配置,如果我们场景只显示这一个倾斜数据,这个可以设置到显存的50%左右,比如我的显存是6G,这个可以设置到3000左右。那么既保证不超过显存限制,又可以最大利用显存缓存,配合crn压缩之后,这个几乎可以保证你第二次查看倾斜同一位置的时候,看不到加载过程,非常棒。


综上:倾斜大数据处理我基本说清楚了,还是要根据您的数据来。


    CesiumLab倾斜处理V3


这里依然保留V2版本程序,主要是避免日后支持麻烦,还有很多人总怀念过去,所以保留下来.


到这里CesiumLab对于倾斜的处理结果我觉得也到了最终的方案,不可能再出现Cesium加载的质的飞跃, 基本已经能保证你无论多大的倾斜,无论什么视角都是在30fps以上帧率运行了,而且不崩溃.


上周末又去了下客户现场,部署了我们最新处理的数据,客户还是挺满意的,系统再也没有因为资源耗尽而崩溃.


当然各位测试过程可能还是有各种各样的问题,那么请给我发数据,没有数据我解决不了问题。


收藏 0 0
    2021-04-30 23:01:56

    感谢博主

    回复 |  引用
共1条 1

登录 后评论。没有帐号? 注册 一个。

西部世界

VIP会员 工作人员
  • 0 回答
  • 0 粉丝
  • 0 关注