新聞資訊

BIM模型輕量化,你懂么?

2018/12/10 16:02:09 人評論

輕量化是已經是BIM業界人所共知的一個概念,雖然至今沒有任何嚴謹的學術或者理論定義,但是這個概念已經幾乎成為了行業的標準。它的大意是說,一個適用用于瀏覽器端渲染的模型數據,包括幾何數據和行業數據,必然可以做的很小,如果和原建模軟件的原始模型文件比較的話,如果做到1/4那是及格標準,做到1/10,乃至1/20之一是優秀。今天我們將討論下這個概念下具體的技術實現方案和背后的計算機圖形學理論,并且希望得出一個對整個行業有參考價值的結論。

縱觀現在國內幾十種BIM的產品,以及結合我們對近30年計算機圖形理論的資料挖掘,我們認為輕量化并不是一個準確的定義,絕對的輕量化在無論產品的數據流上還是在理論基礎上都沒有太多可實現性。我們同時認為,輕量化這個概念應該更正為文件壓縮,并且于現在的通用文件壓縮連接起來,畢竟在實質上,它們是完全相同的。

本文會先對從技術理論出發,介紹可以支撐實現“輕量化”的四個圖形學技術方向,并且在實際應用過程中產生的工程問題,最后會給出一個綜合的輕量化實現框架,以及給出理論上上輕量化可以做到最小壓縮比。

定義

在討論輕量化的可行技術方案之前,我們需要對輕量化進行一個定義和概念厘清。本文所探討的輕量化,指對三維建筑模型模型,例如Revit,IFC等文件中三維幾何數據部分的數據壓縮。本文針對的輕量化不涉及任何其他非三維幾何數據,包括紋理圖片、材質信息、建筑BIM信息、二維圖形信息以及軟件特有的附加信息。很多平臺產品將自己的純三維幾何數據大小和帶有眾多信息的原模型大小相對比,得出自己輕量化程度高的結論是非常不科學的。

我們需要對三維幾何信息進行進一步定義。這里的三維信息特指三維三角形網格(triangular mesh)或者三維線網格(polyline mesh)。每一個mesh由一個頂點數組和一個索引數組組成。頂點數組中每一個頂點一定包含position,即三個32bit IEEE754 floating number,分別對應頂點的x, y, z坐標,可能包含normal,即三個32bit IEEE754 floating number,可能包含紋理坐標UV,即兩個32bit IEEE754 floating number,可能包含頂點顏色,即四個8bit byte,分別對應RGBA四個通道。針對三角形網格,因為考慮渲染效率,一定采用頂點法線(vertex normal),而不是面法線(face normal)。索引數組為一個unsigned int 16的數組,元素個數為3 * 三角形數量或者2 * 線段數量。

除了定義mesh,我們進一步定義輕量化的應用場景。輕量化僅指進輕量化程序處理后用于保存和網絡傳輸的數據量可以壓縮到比原始三維網格的數據量小。在進行渲染前,輕量化的數據可能會解壓縮以便是適配于GPU渲染API的需要,解壓縮的數據量可能會增大,甚至比原先的三維網格數量量更大,這是為了渲染效率優化的考慮。本文所討論的輕量化僅針對優化存儲優化和傳輸優化,并不針對渲染的優化。同時,我們認為因為渲染的API的接口規范已給定,渲染時實現100%還原度的無損數據壓縮是不存在的,雖然本文最后對這類應用情況也提出了一種可行性方案。

技術方向

輕量化的技術方向大致可以分為Instancing,Compression,LOD和Parameterization。下文對四個技術方向以及其落地分別進行探討。

Instancing

Instance,多實例是已經非常普遍的渲染技術[2]。它的原理是針對同樣的幾何物體,只保存一份幾何數據,通過在渲染管線中分別繪制若干次,且每次應用不同的幾何變化和材質信息得到在同一幀多個類似幾何物體的渲染效果,見圖1。用實際的例子說,如果要繪制很多相同的桌子,我們只需要使用一份桌子的幾何數據,然后繪制多編,每一遍把桌子放在不同的位置即可。目前的渲染管線已經完全將instancing放在了硬件管線中執行,大大節約了GPU內存的開銷和CPU的計算開銷(主要指發起一個drawcall的驅動使用CPU資源)[1, 3]。WebGL 1.0中可以通過使用ANGLE_instance_arrays[3]就擴展實現這個功能,在WebGL 2.0中已經有原生API支持,即gl.drawElementsInstanced。

圖1 Instancing示例

對應輕量化的Instancing表達,已經有一定的研究[4,5]。研究的主要解決問題,如何在一個場景中,對幾何體進行一一對比,如果兩個幾何體是同一個幾何體,那么只需要實際保存一份幾何數據,將另外一個幾何體壓縮為一個空間變化和材質信息。判斷兩個幾何體是否相同往往從附加在幾何體上的語義出發,例如兩個幾何體是不是都標記為一張桌子,或者直接從mesh相似度出發。純幾何的算法是非常具有挑戰性的,因為單純的內存比較顯然在大多數情況下不適用,只要索引數組略有變化或者一個簡單的平移變換,這種比較就失效了。現在業界應用比較多的是Hausdorff距離[6],即計算兩個mesh之間的最小歐式距離。這個距離算法一樣對簡單的旋轉無能無力。

另一方面在建筑建模中,我們發現大多數的建模軟件已經內置了Instancing的功能。一個物體如果在場景中重復出現多次,在模型文件中它的幾何數據只保留了一份,每一個實例壓縮為了一個4x4空間變換矩陣。這樣的發現告訴我們,在BIM的數據流中想通過instancing來減少幾何數據的大小已經不太現實,源文件已經在這個方面做到了最好。

綜上所述,在實際的生產環境中,利用Instancing來減少原始文件的尺寸,效果不會太好。

壓縮

壓縮的概念就很好理解,就是和普通的文件壓縮類似。有兩種方向,第一種是幾何無關的,例如直接用將模型數據進行gzip壓縮后保存,因為瀏覽器原生支持gzip解壓[7],在傳輸過程還是gzip壓縮數據,而在應用層已經為解壓后的模型數據,根據我們經驗,針對上文中提及的幾何數據,gzip的壓縮率在2:1,即能壓縮到原始數據一半的大小。第二種方向是幾何相關的,比如Google的Draco庫[8],Khronos的Open3DGC[9]。Draco的公開資料中并沒有提及它的具體算法,但是它的壓縮率是驚人的,見圖2。對于Open3DGC,它在一定程度上利用了quantization的方法,是一種有損壓縮。雖然他們加入了針對幾何信息更好的壓縮,但是本質上還是一種壓縮算法,需要在載入到GPU前將數據解壓縮。


圖2 Draco的壓縮率和壓縮表現


圖3 Open3DGC的壓縮率

壓縮是目前在輕量化中實用價值最高的方法,原因是它完全對于渲染透明,且在服務器端保存的幾何數據量大幅度減少,所需要的無非是一些計算性能的開銷,例如Draco解壓一個100MB左右的文件需要1秒左右的CPU時間。

LOD

Level-of-Detail(LOD)[11, 12],一個渲染加速技術,對于離相機原的物體采取比離近的物體精度低的多的幾何數據,甚至一個billboard來表達。這樣在一個幀內就能大大減少vertex數量,減輕渲染管線的計算量,見圖4。LOD某種程度上可以會被誤認為一種簡化mesh模型的技術容易把LOD混同輕量化來談,這是一種認識誤區,正如前面所述,LOD是一種渲染加速技術,它不但不能減少文件保存時和傳輸時的尺寸,還是需要增加文件尺寸的。例如圖4中,除了原始的最左邊的模型,模型處理程序還需要構建出右邊三個簡化模型,將其傳輸到客戶端用于渲染加速。額外的三個簡化模型大大增加了模型的數據尺寸。


圖4 Level-of-Detail本質上是根據相機距離選區不同復雜度的集合模型渲染

但是也有通過quantization方法,在不增加文件尺寸的基礎上提供了LOD技術[13](圖5)。它把模型的定點坐標的floating number全部轉換為normalized整形,然后依靠cutting off來實現downsampling。這是一個非常巧妙的辦法,唯一的開銷是在vertex shader中需要將normalized floating number展開。


圖5 Pop Buffer利用quantization來做LOD

LOD雖然不能直接降低模型的幾何數據大小,但是依據LOD的層級可以實現模型幾何數據的增量傳輸(progressive loading),也就是先傳輸低層級的幾何數據且顯示,最后再傳輸那些更加細致的幾何數據。如果用戶允許一定程度上的幾何細節損失,LOD也可以成為一種輕量化方法。對于模型簡化的算法可以參考[14, 15, 16]。另一個非常類似的研究方向是mesh streaming,更多的應用于大規模地形模型的渲染。

Parameterization

參數化這個做法就是將mesh轉成nurbs或者其他參數表達方式。這個技術本來是在逆向工程中使用,從激光掃描的點云中恢復參數曲面用來車床加工[20, 21, 22]。對于參數易表達的面,比如球體,這種方式大大減少了數據量。但是對于建筑來說,大多數面片都是平面,并不能減少太多數據量,甚至在有些情況曲面消耗的存儲空間比mesh更大,比如帶很多trim的曲面。何況GPU并不支持參數曲面的實時繪制。

還有兩種類似參數化的方法,分別是remeshing即重新mesh[23],見圖6和subdividision 曲面細分[24],見圖7。前者將mesh重新采樣做成一個新的mesh,后者將一個曲面細分,生成一個更加復雜的曲面,實質上是生成一個由原先曲面作為控制點的b-spline surface。理論上,我們只要找到一個和現有mesh幾何相近但是更簡化的表達,就達到了壓縮的目的,但是這樣做并不容易,原因還是建筑模型中大多數的幾何體并不適用于細分曲面。


圖6 Remeshing


圖7 細分曲面

但是參數化表達并無不可取之處,對于幾種特殊的情況,參數化表達可以達到非常好的效果。比如管道等利用extrusion操作生成的物體結構,見圖8。這樣的掃描體完全可以用一條路徑加一個橫截面來表達,如果橫截面為一個方便公式表達的形狀,例如圓形,那么數據壓縮的效果會更加明顯。為了進一步減輕客戶端將這種參數表達的形體展開為mesh的工作量,我們可以將path中的采樣點預先計算出來。


圖8 Extrusion

一個可行性數據壓縮框架

上文已經總結了可用于壓縮的四個基本方向,我們認為并不存在一個適用于普遍場景的“輕量化”方案。一個相對可行性方案也是Modelo采用的是

保存原建模文件中的instancing信息

如果原建模文件中有NURBS曲面(b-rep),控制它的網格細分力度,取得效果和文件體積平衡

對于extrusion物體進行參數化,將其壓縮所成line strip和一個橫截面

采用Google Draco對其進行壓縮

采用gzip將其壓縮

對于一般場景,這個方案最終的壓縮率幾乎取決于第四步Draco的壓縮表現,這也是為什么我們認為“輕量化”的更應該稱之為“幾何數據壓縮”的原因。只有對于極少數的場景,例如可以簡化的管道,第三步就可以發揮極大的作用,大大降低文件尺寸,但是這步的工程實現難度也很大,需要考慮很多細節,這里也不一一闡述了。

———

寫在最后,我們總結了現有可以提供“輕量化”支持的圖形技術,并逐一從工程上分析了它們的可行性,我們堅持認為“輕量化”并不是嚴謹科學的概念,我們應該稱其為網格(幾何數據)壓縮,類似于紋理壓縮一樣。在這樣的定義下開展研究和開發,才能找對正確的方向。