基于分页数据结构的倾斜摄影模型加载为什么会卡的思考

现在发现很多在生产、应用倾斜摄影的上下游，好像有很多上游并不清楚自己应该产出一份什么样的倾斜模型数据，下游也不清楚自己应该拿到一份什么样的数据
总是会被人问"倾斜模型太大了，几十个G，加载太卡了，有什么办法能让它变小点"、"倾斜模型我要做顶层构建要做轻量化，你们软件支持吗"等，其实通过这些需求疑问已经能看出对于问题的产生原因出现了错误认知
希望通过阅读本文能够对倾斜摄影为什么会卡这个问题有更清晰的认知，这样解决问题才可以针对性解决

省流版

数据生产阶段带来的问题，最好能够在数据生产阶段解决，除非真的没辙了，不然后续优化的成本代价会很高，且效果一定不如重走前序流程

1. 倾斜摄影模型没有什么体积过大问题，当前的数据组织形式就是为了解决单一模型太大而无法加载的问题，50GB、500GB就想着减小体积，那Google加载全美国的实景模型它该减少到多少体积？所以卡顿问题不在这个模型文件整体大不大，也就进而衍生所谓的网格简化、轻量化技术用来减小体积的正确性思考
2. 数据生产时候的跑图建模前请务必分析计算一下地块，1km*1km的倾斜摄影，一个按100米边长切割成100块，一个按10米边长切割成10000块，从文字上就能感受到加载一万块更吃力，边长要设置成一个合理的范围100~300米，这才是数据加载卡顿的一个主要原因
3. 二次修模的时候尤其是手工单体模型替换，这也是造成效率问题的第一大原因
   1. 美术出模型要合批，除非特殊项目需求，一个模型分出来几百个子节点Box是不合理的
   2. 手工单体模型要么不要挂到倾斜摄影里面，如果要挂，一定要切片分LOD后再合并到倾斜摄影模型里
4. 如果2、3两个问题解决了，不优化也是没有问题的，锦上添花 的操作就是使用一些压缩(注意区分与轻量化的网格简化概念的不同，这里是接近无损压缩，不会降低精度)算法降低单文件体积，如果3DTiles就可以用 “纹理压缩”、"Draco几何压缩"这两个技术，如果是OSGB就可以用 “纹理压缩”、“zlib几何压缩” 来加快单文件网络传输的速度
5. 当遇到极端情况时，那种几百公里倾斜摄影，合理的地块划分都是几千个地块，那么我们可以选择使用顶层构建，只有几百个地块完全不用考虑这个手段，加载完全没问题

详细版

概述

目前主流开源免费的支持数字地球级别大场景渲染平台一共两个：Cesium、OsgEarth(下称OE)，其中OE是C端平台、Cesium是B端平台。

如果我们希望在基于Cesium和OE的相关项目上应用倾斜摄影数据，一般来说会遵循以下五个步骤(第三、四步有可能会被裁剪，视具体需求而定)

1. 影像采集：使用无人机拍摄需要三维建模的倾斜图像集；
2. 跑图建模：通过采集的场景影像集进行自动跑图建模获得基础分页模型；
3. 二次修模：一般来说因倾斜拍摄的技术限制以及项目业务场景的一些需求，需要对上一步的基础分页模型进行二次加工；
4. 效率优化：为了能够在后续项目应用里获得更好地表现，很多情况下也会选择进行一次数据优化；
5. 应用加载：项目具体业务功能代码加载；

接下来将以这五个点进行分析，从原理深入了解怎么做才能让倾斜摄影正确的、更好的应用在后续实景三维项目中

影像采集

这个点暂不在本文讨论范围之列，因为这个属于外场施工，且对后续数据实际使用影响不大，主要就是一套优秀的无人机软硬件系统、一位优秀的无人机操作手，
就可以得到一份好的原始倾斜影像数据。

跑图建模

从这一步开始,如果处理不恰当将会对后续的数据应用产生极大的影响！ 在这一步完成的最核心的工作就是使用倾斜建模软件将上一步采集的场景倾斜影像集处理成分页数据模型如3DTiles、OSGB格式。

要想对后续影响降到最低，则需要满足几个要素：

1. 需要一款成熟地处理软件；
2. 需要一台性能极高的电脑；
3. 需要正确地理解分页数据格式性能瓶颈后再设置模型生成参数；

当前国内外相关成熟生产软件不在少数，如CC(context capture)、大疆、smart3D等，高性能电脑更不必说了。因此第一二两点无论服务提供团体规模大小，只要做相关业务了就基本都能满足要求。

但是第三点，很可惜目前发现不少从业者，无论是生产还是应用者并没有过多的关心这一方面，前序流程秉承着相信"后人"的智慧，其实这样是有很大风险的，因为后人也不一定知道。

倾斜摄影模型由于使用的分页技术，因此后续加载平台时不关心你模型整体到底多大，反正是分级分块加载的，例如Google Earth实景图层直接就是一个城市一个城市加载。分页技术的性能瓶颈是在于一级节点即地块文件夹数量，同样的一份1km*1km的数据，一个按100米边长切割成100块，一个按10米边长切割成10000块，从文字上就能感受到加载一万块更吃力，即使它们是相同的数据，一个合理的地块数量切割可以节约非常多的后期优化成本。

再例如5km*5km的数据，按100m边长切割，就是2500块，但是如果我们以150米边长切割约是1100块，地块数直接少一半，也会减轻很大的性能负担。

1. 上文叙述的"分页技术"可以简单理解为"OSGB/3DTiles格式"，但需要明确这两个格式不等同于分页技术，他们只是支持分页数据的一种存储格式而已
2. 为了让本文不至于显得冗长难以阅读，更具体详细的解释及分析，另开篇分页数据格式的原理及加载性能瓶颈分析

总结来说，这一步比较容易忽略，但又很重要的就是要设置一个合理地块切割边长，一般在100~300米之间，具体区间内高还是低，就需要结合拍摄精度，生成精度以及电脑性能综合情况来确定了，没有固定公式，不过确定的是要想办法将输出地块控制在合理范围之内。

二次修模

二次修模结果目前在应用端如果出问题，听到最多的就是"修完模这模型怎么这么卡"，那么我们就要从具体修了什么来分析了

目前修模比较热点的工作需要有以下几个：

1. 单体化(含单体模型替换)
2. 水面破损修饰
3. 路面平整(含地形平整)
4. 建筑立面修饰
5. 悬浮物删除
6. 纹理修饰
7. 破洞修补
8. 区域压平

一般来说如果不涉及到数据结构的变更主要是数据的增加，不会出现说编辑完之后就变卡了，尤其是数据如果是在删减的，例如删除悬浮物、区域压平，这是在减数据，只会让效率变高。至于3、4、6点只是修改部分网格的顶点位置与纹理，也不会造成什么影响，至于2、7涉及到了部分网格点的增加，但是水面、破洞面增加是很有限的且一般都是直接作用于网格拓扑，也不会带来额外性能开销。

就剩下第一点的单体化了，从很多用户提出的这类性能优化需求分析统计来看，基本所有问题也就是出在这里

1. 制作的这个单体模型的时候不符合要求
   1. 如果后续这个单体模型不需要对某一部件做交互的，从建模软件导出的时候应该尽可能合并节点网格、合并纹理
   2. 模型应充分考虑项目应用需求精度，要时刻想方设法的让模型尽可能小

   这对美术有很强的功底要求，需要清楚了解实际项目得加载平台对于模型的需求，构建出模型只是第一步，输出一个好模型考验得就是美术硬实力了

   同样一个模型，有无优化在最终得结果上差别可能是成倍的帧数差！

2. 把制作的单体模型合到分页模型里面太随意
   1. 想要替换的区域单体手工模型应该要做切片然后分级LOD后再挂到倾斜摄影上，不然不要简单的挂到根节点或高精层级的子节点上

   一份手工单体模型可能会几十上百MB大小，直接挂载到根节点上，会被后续渲染平台当成倾斜摄影的根节点瓦片常驻一次性加载，如果是B端平台很容易无法加载这么大的模型而直接崩溃

   即使挂载到高精层级的子节点上，是避开了一开始加载压力过大问题，但同样也绕不开视角到达那个单体手工模型层级的时候，同样会一次性加载该模型导致巨幅卡顿甚至崩溃的情况

效率优化

提到效率优化那么就得从后续渲染平台加载效率为什么会出问题来切入分析(仅针对Cesium、OSG、OE平台)

1. 同时渲染的 点 太多，GPU渲染性能不达标
2. 同时渲染的 节点 太多，CPU遍历的时候花了太多时间，且GPU频繁状态切换

点太多指的是一次性让显卡渲染几千万上亿个点达到了硬件性能极限；

节点太多指的是，假设有一个模型有1万个点，按理说这个点很少了，渲染应该是没有压力的，但是如果把它分成了2500个子节点，每个由4个点组成的独立多边形节点模型，再渲染，那么同样会导致巨幅卡顿的情况出现，这就是节点太多

我们回到倾斜摄影数据源来看它是不是也是这两个问题

1. 倾斜摄影动辄几十G上百G，乍一看点巨多，不过倾斜摄影最核心的一个技术应用是分页加载技术，这个技术就是为了解决这里一个超大模型点太多，
   纹理太多太大无法一次性加载的问题，所以无论体积多大它都被分页技术的实现切成了一个个小块，然后每次只加载合适范围合适精度大小的模型。

   因此在Cesium/OSG/OE这类平台加载分页数据，50GB也好，500GB也好，体积从来不是影响效率的问题，这已经被分页数据技术所解决了，
   参考Google Earth加载的是整个国境的实景图层，那该有多大，仍然可以流畅加载。

2. 再看节点太多问题，这个从分页技术原理来看，通过切割地块以及分级LOD解决了单一模型太大无法加载的问题，由于切割地块就产生了很多地块节点(Tile文件夹)，这个的确是有可能存在这个问题的，所以也是上面在说跑图建模阶段的时候，要求合理的划分地块的主要原因

   如果地块划分是一个比较合理的范围，这个优化也没有那么高优先级，渲染平台也在进步，硬件性能也在进步，即使1000+的地块数量也是扛得住的流畅渲染的

再回到二次修模所提地不要简单把手工单体替换模型很简单的挂到根节点上的原因就更清晰了，它同时增多了地块节点数量，也让一次性加载的模型顶点巨幅增加，以这种形式实现地单体模型替换，几乎百分百会导致后续变卡

综合来说，如果跑图建模以及二次修模都是以上述正确的形式操作，到了效率优化这边就很简单明了了

1. 不用关心体积，对于整体体积轻不轻量化不会出现显著差别，单纯的文件体积大或者小不是基于分页结构的倾斜摄影模型的问题
2. 当无论如何都无法降低的地块数量，才需要优化，但以咱们当前的市场情况，也很难遇到那种以300米合理划分都会达到大几千个地块的情况，简单算一下，这种情况都是几百公里的倾斜摄影，万一真有那么我们可以用 “顶层构建”
3. 还有一个是当倾斜摄影以Web数据服务形式进行使用的时候，我们想办法加速一下网络流送速度即可，那就是压缩传输，如果3DTiles就可以用 “纹理压缩”、"Draco几何压缩"这两个技术，如果是OSGB就可以用 “纹理压缩”、“zlib几何压缩”

总之按正确的流程操作下来的倾斜摄影，是不需要做多少优化的，优化属于锦上添花，如果是因"跑图建模"以及"二次修模"的不合理实现所导致的加载问题，一般情况下优化是无法解决那些问题的。

应用加载

略

加载偏代码层面了，不在此处叙述，考虑是否有价值另开篇，本文主要是分析倾斜摄影在这些平台上的应用流程及可能的不正确操作而导致的效率问题分析

生产力工具推荐

一款新出的倾斜摄影模型处理软件：灵易智模-OPEditor，主要针对 “二次修模” 和 “效率优化” ，当前还在公测免费阶段可以白嫖