深度科普文：细数倾斜摄影数据的缺点

1. 引言

写这篇文章的起因是最近遇到一个使用倾斜摄影数据应标的三维可视化项目，业主认为倾斜摄影数据加载很卡，要求能浏览场景的时候能立刻显示出当前的场景最精细的模型，如下图1所示。其实这个问题遇到的次数还真不少，作为乙方尝试去解答这个问题是一种进退两难的煎熬，因此在这里忍不住吐槽一二。

2. 问题

2.1 问题的答案

先说一下笔者的结论，这个要求对于倾斜摄影数据来说是不可能实现的：

1. 倾斜摄影数据的加载并不是卡，卡是性能问题，卡住了画面就会一动不动。实际上正常的倾斜摄影数据加载起来一点都不卡，浏览起来也非常流畅。
2. 倾斜摄影数据的问题是其实是加载很慢，很难一下子加载到最精细的模型。但对业主来说，是不太了解这些的，只能直观的表达这就是很卡。
3. 加载很慢的问题是没办法解决的，这里面的逻辑是这样的：
   1. 如果硬件资源（CPU、内存、GPU、显存等）允许，我们当然希望能一次性加载到内存/显存空间中进行渲染显示，这样只会在预加载数据的时候卡一次，渲染画面浏览操作的时候就完全不会卡。
   2. 但是这个方式对于倾斜摄影数据来说不可能的。一个倾斜摄影数据通常有上百G的数据量，但是目前还没有上百G的内存和显存，即使有GPU也不一定能保证渲染如此大数据量的画面不会卡。
   3. 为了解决这个问题，就诞生了一种名为多分辨率层次结构（Hierarchical Level of Detail, HLoD）的技术，具体来说就是将三维模型数据划分为多个层次，每个层次包含不同详细程度的模型；同时在渲染端根据观察者的位置和视角，动态选择最适合的模型细节，从而在保持高性能的同时提供高质量的视觉效果。
   4. 在三维图形渲染中为了保证流畅的性能，需要在1秒中渲染60次画面，专业说法就是要达到60帧。换算一下也就是渲染一次画面（简称为每一帧）最多只能1/60秒的时间。数据需要从磁盘中获取，假设磁盘IO的效率是每秒60M，那么每一帧能处理的数据就只能是1M大小。
   5. 很显然，在真正可视化的时候，每一帧能处理的数据几M大小相对于整体的上百G数据实在太小了，一定会有一个逐渐加载的过程的，这就是总是会显得加载很慢的原因。

2.2 业主的疑惑

那么为什么总是有业主希望倾斜摄影数据能马上加载出来，不要有中间逐渐加载的过程呢？因为这本来就是传统的三维模型工作流的优点和特性。在传统的三维模型工作流中，通过3DMax等建模工具将模型创建完成之后，渲染端只需要在程序启动的时候预加载一次就可以了，之后的模型数据就常驻在内存/显存中，后续整个渲染流程就完全不会卡，更不存在什么逐渐加载的过程。

很多人，尤其是干摄影测量的，就会对业主的这个要求感到疑惑，觉得倾斜摄影数据就是这样要逐渐加载的啊，有什么问题呢？其实当然有问题，对业主来说已经习惯了传统的三维模型工作流了，你现在引入了更有技术含量的倾斜摄影技术，还有什么HLoD的可视化技术，这个加载快的优点应该保留吧？总不能你技术升级了，反而还让用户的交互感受下降了，那算什么高新技术呢？

这样来看，业主的要求也是有道理的，作为乙方唯一有问题就是不应该随便拿倾斜摄影数据这种做三维可视化项目有很大缺陷的数据来应标，导致自己陷入了一种难以自证的困境：如果你觉得倾斜摄影数据更好，那为什么加载很慢？如果倾斜摄影数据不好，那为什么要用比较差的数据方案来应标？

3 缺点

我说倾斜摄影数据是一种缺陷非常大的数据，可能很多人尤其是摄影测量从业人员可能会不太服气。但是其实数据生产是数据生产，可视化项目是可视化项目，是两个不同维度的东西。倾斜摄影数据很多被人认为是习以为常的特性，放在可视化项目中是很难被接受的。

3.1 建模问题

倾斜摄影数据最大的问题就是难以表达突变的、尖锐的特征，只对平滑的特征才有比较好的表达。具体来说，像树木、广告牌、电线杆这些或蓬松的，或细长，或薄型的结构建建模效果总是一言难尽，如下图2所示树木的建模效果：

我知道，国内有很多建模软件都宣称可以将广告牌、电线杆甚至塔吊都建模出真实的效果；确实，只要提升足够的分辨率、或者混合Lidar点云建模、甚至补充使用AI技术补充细节，也许真的可以将这些要素都复原出来，但是有的问题总归是不能避免的，例如物建筑物表面不平整的问题，如果你做过倾斜摄影数据单体化，就一定明白我说的是什么：

其实这些问题从原理上来说都是同一个问题，都是三维重建算法导致的。简单来说，三维重建的时候使用的输入要素是有限的，就一定会产生插值误差或者过拟合的问题，如果是重建地形问题不是很大，但是要重建复杂的、充满了突变要素的地表模型，就一定会导致平面边缘模糊或产生多余的起伏的问题。确实，是可以通过增加分辨率的办法让三维建模的输入要素更多，从而使得建模更加准确，但是如此高标准的倾斜摄影建模，又有谁能应用的起呢？至少在公共领域是看不到这样的倾斜摄影建模数据的。

3.2 语义化问题

搞倾斜摄影搞到最后，各大数据生产商也都发现了，一定要解决语义化的问题。笔者也不知道语义化这个词怎么来的，大约意思就是说倾斜摄影数据就是一张皮，你是不知道这张皮上面哪个部分是属于哪个建筑物的。这也就意味着倾斜摄影数据不能与实际的业务关联，只能做做可视化的展示工作。

要解决语义化的问题，首先就必须实现倾斜摄影数据的单体化。具体来说，就是将倾斜摄影数据上具有具体意义的部分单独提取出来，形成独立的、精确的三维模型。这一过程使得每个单独的对象（如一栋楼、一座桥等）能够被单独编辑、查看、分析和应用，也可以赋予具体的业务属性，从而实现了语义化。关于倾斜摄影的单体化，笔者的文章《倾斜单体化模型技术实现》中有详细的论述。

在笔者看来，将倾斜摄影数据进行单体化不仅解决了语义化的问题，最重要的是规避了上一小节中提到的建模问题：在一个倾斜摄影数据中，表达地形的部分可以直接使用DEM数据替代，树木、广告牌、电线杆这些突变的尖锐的地图要素又表达不好，剩下的就只有一些建筑物的表达还有可视化价值了，那就干脆将这些建筑物单体化出来，反而更有实用价值。

3.3 可视化效果问题

很多人将倾斜摄影数据称为“实景”，将倾斜摄影数据称为基于真实的物理建模。毕竟是友商，当时笔者并未做过多的争论，现在细想起来其实是有问题的。确实，笔者承认倾斜摄影数据确实很真实，但是这种真实仅仅只是照片那种真实，与三维图形渲染集中基于真实的物理光影效果渲染的模型其实是有很大差距的。如下图4和图5所示，图4是纹理图片上的水面效果，图5是通过三维特效实现的水面效果，你觉得哪边更加真实呢？

倾斜摄影数据就是这样，它的真实性，所有的光线反射、阴影全部都固化到纹理图片上了。这意味着你不可以像调整三维效果一样调整它，强行调整它就只会得到很奇怪很不真实的效果，你的可视化效果的上限就这样被定死了。基于真实的渲染是一个很复杂的问题，相机拍摄的照片也只是一种逼近而已，倾斜摄影数据的真实感上限是远远比不上传统的三维模型工作流的。传统的三维模型工作流在进行渲染端之后，可以借助于渲染引擎的物理光照计算，获得更为真实的渲染效果。另一个最现实的例子就是，你是觉得倾斜摄影数据更真实，还是《黑悟空》里面的场景更真实？

3.4 地理套合问题

所有的资料都宣称倾斜摄影数据具有亚米级别甚至于厘米级别的精度。我当然相信这个说法，但是这么高级别的精度用到三维可视化项目上，是符合国家数据安全要求的吗？即使不考虑这个问题，倾斜摄影数据一般要与地形数据进行套盒，但是实际上由于精度不一致的问题，两者的套合效果并不好。以目前的解决方案来说，都是调整倾斜摄影数据的高度，保证大概能贴到地面即可。但是对于有的倾斜摄影数据来说，这样的做法并不严密，有的地方都贴到地下面去了，有的地方离地面还有点距离。

4. 结论

最后其实还想讨论一下倾斜摄影数据的调度问题，不过这个问题就太复杂了，有机会就放在后面再介绍吧。总结一下本文的内容，那就是在使用倾斜摄影数据进行三维可视化项目的应标的时候一定要慎重，它具有一下几个缺点：

1. 无法保持在传统的三维模型工作流中数据只加载一次的优点，而是需要一边渲染一边加载，这可能并不满足业主对于实时性的要求。
2. 目前通用的倾斜摄影技术的建模算法对于突变的、尖锐的特征的表达并不太好，例如树木、广告牌、电线杆等；建筑物的表达也存在不平整的问题。
3. 倾斜摄影数据的可视化效果固化在纹理图片上，无法通过三维渲染技术进一步提升真实的效果。
4. 由于精度的差异，倾斜摄影数据与三维场景的套合可能存在一定的偏差。