下一代的 3D Tiles 前瞻
原文：Introducing 3D Tiles Next, Streaming Geospatial to the Metaverse
原文發佈時間：2021年11月10日
閱讀本文前，需要有足夠的 3D Tiles 1.0 基礎、glTF 規範基礎、CesiumJS 基礎。
譯者概述
3D Tiles Next 自官方有想法以來，我就一直在跟蹤，無奈年關將至，業務繁忙，現在才着手閱讀和學習。
3D Tiles Next 下文會簡稱 Next，而現行的 3D Tiles 1.0 則簡稱 1.0，因爲官方暫時沒把下一代正式稱爲 2.0.
從組織方式來說，Next 在 Tileset 和 瓦片文件層級均做了優化，Tileset 新建了多項擴展，瓦片文件則直接使用 glTF 格式，不再使用舊的 b3dm、i3dm、pnts、cmpt.
從性能考量來說，Next 引入新的空間索引規則，叫做 Implicit Tilling，即隱式瓦片分割，並介紹了一種空間分割算法：S2。
從領域需求來說，Next 強化了元數據、屬性數據的組織，創建了 3D Metadata Specification（三維元數據規範）及相關的擴展。
此次更新不小，除了 Cesium 原班人馬外，還有一個三維大佬 Don McCurdy 在後期添磚加瓦。
除了數據規範本身的更新，前端運行時 CesiumJS 在 1.87.1 版本終於公測了 Next，並提供了新的 glTF 數據加載架構 —— ModelExperimental，以及更友好的自定義着色器 API —— CustomShader。
1. 綜述
3D Tiles Next，指的是一組 3D Tiles 擴展項。這些擴展項主要體現在三個方面的增強：
- 結構化的元數據
- 空間索引性能
- glTF 生態集成
官方關於元數據的限定詞是
semantic，即語義化的，我覺得“結構化”可能更好一些。
如下圖所示：
2. 元數據的增強
鑑於需求的急劇擴張，3D Tiles 擴充了元數據方面的功能。在 3D Tiles Next 中，引入一些元數據方面的擴展項。主要特點有：
- 元數據的編碼方式更友好，可以用二進制，也可以寫入 JSON；
- 層級擴充，可以是每紋理單元級別的元數據，也可以是每個瓦片級別的；
- 規範了元數據的格式。
與 1.0 規範使用 Batchtable（批次表）來存儲元數據的目的一致，Next 的元數據擴展依舊遵循了性能優勢：批量處理。
許多邏輯層面的三維要素（例如某個建築）及其元數據，在前端運行時（可以簡單認爲是 CesiumJS）預先被成組成批處理，以減小 CPU 的開銷。
元數據方面的擴展，分三個方面：
- 類型系統；
- 編碼方式；
- 領域相關的語義化規範，領域是指 BIM、CAD 等；
2.1. 元數據的類型系統
3D 元數據規範 定義了一套類型規範與數據的編碼方式。
3D Tiles 1.0 依賴於 JSON 本身有限制的基礎類型，而 Next 具備更豐富的類型支持，包括類、向量、矩陣等。
元數據的編碼方式可以有：
- 二進制格式；
- JSON 格式；
- 柵格格式。
具體細節要看規範。
2.2. 不同層級的元數據（像素級別樣式化渲染）
配合使用 3DTILES_metadata 和 EXT_mesh_features 兩個擴展項，下一代的 3D Tiles 可以在各個層級存儲元數據。這些層級可以是：
- Tileset（瓦片集）層級
- Tile / Tile ContentGroup（瓦片或瓦片組）層級
- Feature（三維要素）層級
- GPU 繪製實例層級
- Vertex（頂點）層級
- Texel（紋素）層級
如下圖所示：
紋素級別是最細的層級，允許元數據在如此細的粒度上變化。
例如，兩個三角形構成一個四邊形，作爲一個建築物的一側牆面，但是此時它僅僅是“兩個三角形”，在真實世界中牆面還可能會有窗的玻璃、磚的石頭的區別，在拾取識別時，就可以例用“紋素級別”的元數據來辨別什麼顏色是什麼物體。
下面是一個例子，對傾斜攝影數據使用紋素級別的元數據：
此處有分屏，左側的顏色就可以很明顯地區分出牆、窗戶、空調、屋頂等“實際物體”，而數據的三角面組織卻可以不用在意這些“實際物體”。
在右側，利用紋素級別的元數據，就可以完成窗戶單體的半透明處理。
2.3. 語義規範
除了層次足夠細緻，還要知道數據的含義，這就是所謂的“元數據的語義”，以便程序代碼知道怎麼進行交互編程。
例如，水泥地和草地的摩擦係數可以作爲元數據，影響車輛的行駛速度等。
各領域的專家可以根據有關擴展項來定製自己專業所需的元數據，譬如在土方施工中，將材料庫存、各項參數寫入元數據，方便代碼計算體積和麪積。
3. 空間索引增強：隱式瓦片分割
3D Tiles Next 在空間分割上做了優化，光線追蹤、近鄰搜索這些空間分析、模擬功能從此受益。
在 1.0 中，空間分割體現在 tileset.json 文件中的每個 Tile 的定義，這些定義包括 BoundingVolume（空間範圍體）、瓦片文件的模型以及其下一級的子瓦片等。
據官方介紹，3D Tiles 1.0 的空間分割方式可以自由搭配選擇，不用侷限於傳統 2D 地圖的四叉樹分割。需要注意，子瓦片的空間範圍要小於父瓦片的空間範圍。
下面是 1.0 中介紹的三種空間分割樹結構，依次爲 KD樹、鬆散四叉樹、八叉樹：
3D Tiles Next 引入了一個新的擴展：3DTILES_implicit_tiling，它主要的作用是引入一種預先知曉規則的空間分割規則，使得無需顯式記錄瓦片的空間範圍體。這樣，就可以隨機訪問單個或任意多個瓦片了，這樣有益於：
- 單服務器或跨服務器的大規模模擬計算，尤其是 K-最近鄰 和範圍查詢；
- 基於光追，或者說，基於射線的計算，因爲統一的索引結構可以提高空間索引的性能；
- 局部數據更新，例如某塊區域的建築需要更新
城市級別的流式數據、建築區域中隨時間更新的數字孿生變化、飛行器的變化等，這些例子都將受益於上述所說的瓦片隨機訪問機制，而無需走原來的自頂向下的 LOD 層級訪問機制。
上圖表明，城市中的人羣大規模模擬得以實現，主要是因爲隱式空間索引機制，可以高效率地進行鄰近瓦片的空間查詢。
隱式瓦片分割機制，可以簡潔地呈現 Tileset（瓦片集）的空間數據結構，包括：
- 四叉樹或八叉樹；
- RootTile（根瓦片）的幾何誤差（geometricError）和空間範圍體（BoundingVolume），以支持全局或局部的 Tileset；
- 瓦片的可見性，這樣可視化引擎（CesiumJS）只需請求存在的瓦片，減輕網絡壓力；
- 莫頓 z 序曲線（Morton z-order curve）存儲了瓦片的其他信息；
- 模板式 URI，這樣可以根據 URI 的規律，快速隨機訪問想要的瓦片而不需要再次自頂向下遍歷整個 Tileset
上面這張圖，左邊是 tileset.json 的大致示意，右邊則是四級空間分割及其莫頓 Z 序曲線的顯示效果。
與 1.0 中顯式指定空間分割的瓦片相比，隱式分割還可以減小 tileset.json 的體積，降低網絡壓力。
但是與網絡壓力相比較，隱式瓦片分割的真正威力在於運行時可以隨機訪問瓦片，而且這些瓦片的空間分割規則是統一的。
除了空間檢索性能上的考量，隱式瓦片分割還有一個意圖，就是希望與傳統 2D GIS 的 CDB、WMTS、TMS 等規範集成實現。
空間分割算法：S2
3D Tiles Next 引入一項 3DTILES_bounding_volume_S2 擴展，它能與隱式瓦片、顯式瓦片一起使用，定義新的空間範圍體。
S2 分割是一種比四叉樹更好的空間分割，這種分割方式基於一個立方體，它在北極、南極附近的瓦片會比較“薄”，失真較小。同一級別的瓦片的尺寸是接近的。
筆者注：這個算法不太瞭解，需要閱讀更多資料。
上圖爲 WGS84 橢球面上的 S2 Hilbert（希爾伯特）曲線。
4. 在三維“圖層”中使用複合內容
傳統 2DGIS 會把同類數據放進同一個容器中，這個容器叫做“圖層”，比如高速公路圖層、POI圖層、建築圖層等，這樣可以統一樣式設置。
使用 3DTILES_multiple_contents 擴展可以在一組 Tile 中定義“三維圖層元數據”，然後將對應的三維數據綁定至這個組來實現“三維圖層”、“數據與元數據的連接”。
5. 與 glTF 技術生態集成
在 3D Tiles 中使用 3DTILES_content_gltf 擴展，Tile 對象可以直接引用 .gltf 或 .glb 文件，而不是使用舊的 b3dm、i3dm 瓦片文件。
這樣 3D Tiles 就可以直接利用 glTF 社區的成果，例如驗證工具、轉換工具等。
3D Tiles Next 利用到 glTF 的地方有：
- 3D Tiles 在瓦片層級直接使用 glTF 作爲三維數據；
- 將 glTF 直接用於點雲格式；
- 更好利用了 glTF 的擴展項。
5.1. 直接使用 glTF（b3dm 與 i3dm 升級）
有閱讀 3D Tiles 1.0 規範的朋友知道，b3dm 和 i3dm 瓦片文件是內嵌了 glTF 的二進制格式數據的。
上圖展示了 1.0 和 Next 的瓦片文件設計區別，1.0 中最具代表性的 b3dm 瓦片文件由頭部元數據（b3dm Header）、批次表（BatchTable）和具體模型數據（glTF）塊構成，而 Next 則直接使用 glb 文件，且使用了 glTF 的 EXT_mesh_features 擴展來替代批次表。
使用 3DTILES_content_gltf 這個 3D Tiles 擴展，瓦片就可以直接引用 gltf 或 glb 文件。如果瓦片中存在邏輯要素信息，則可以在 gltf/glb 中啓用 glTF 的擴展：EXT_mesh_features.
但是如果是 i3dm，比如一個樹模型要繪製多次（即實例繪製的方式），那麼就使用 glTF 擴展 EXT_mesh_gpu_instancing 來實現，以替代 i3dm 瓦片。EXT_mesh_features 也可以跟這個擴展一起使用，來記錄每個被繪製後的實例的屬性數據，如下圖所示：
官方希望直接使用 glTF 的意圖是可以更好地與其他行業的數據進行合作，以提高 3D Tiles 的模型兼容性。
5.2. 點雲與 glTF（pnts 升級）
上圖是某個城市的 100 億個點的點雲數據。
在 1.0 中，點雲數據是使用 pnts 格式的文件存儲的，包括 FeatureTable（要素表）、Batch Table（批次表），並可以帶 draco 壓縮。
在 Next 中，點雲也可以使用 glTF 格式的文件，使用 glTF 中的 EXT_meshopt_compression 擴展即可實現一些運行時（CesiumJS）方面的樣式化、過濾，甚至是點雲的元數據等。總的來說，Next 對點雲這種格式的數據：
- 將點雲的幾何數據存儲在 glTF 本身
- 元數據（屬性數據）通過 EXT_mesh_features 實現
- 頂點和法線數據的壓縮通過 EXT_meshopt_compression 來實現。
如下圖所示。
在最終敲定 Next 規範之前，官方還希望使用不同的壓縮方式來補充 EXT_meshopt_compression 這個擴展如何進行點雲壓縮，包括 Esri LEPCC 和 Google Draco 等方式。
5.3. 繼承 glTF 的擴展項（紋理壓縮）
由於 Next 對瓦片文件的更新替換，不再使用 b3dm、i3dm、pnts 瓦片文件，因此功能上的更新基本上都是 glTF 的擴展。
3D Tiles Next 依舊會使用 glTF 的 KTX 2.0 和 下一代 PBR 材質等擴展。
KTX 2.0 是用來支持紋理數據的跨 GPU 傳輸、運行時壓縮，減少內存、帶寬等，以提升硬件效能，畢竟通過無人機或者衛星獲取的圖像的體積可不小。
下一代 PBR 召集了世界 PBR 專家來集思廣益，將 glTF 的材質表現提升到一個新的高度。
6. 後續進度
從發文時間起，之後的幾個月將完成規範的設計。
目前的進度有：
- 起草了 3D Tiles 與 glTF 相關的擴展項：
- 開發者相關的資源，pdf、示例數據、博客等；
- 在 [email protected] 以上的例子實現
- ...
7. 譯者注
下一代的 3D Tiles 目前沒有定名爲 3D Tiles 2.0，而是暫時以擴展項的方式推進。
它解決了一部分 1.0 中的問題，例如把元數據從舊的瓦片文件中的 BatchTable、FeatureTable 拆分出來，便於數據庫實現；拆出來元數據後，剩下的三維數據可以直接利用 glTF 格式，而 glTF 格式本身又是可以把紋理、幾何分開存儲的。總之，新設計的靈活性非常強。
除了數據方面的問題，還提出了新的空間切分算法 —— 隱式瓦片，這個擴展旨在提高前端瓦片剔除和渲染的性能。
總之，現在的狀態就是“請灑潘江，各傾陸海云爾”。