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. 由于精度的差異，傾斜攝影數據與三維場景的套合可能存在一定的偏差。