下一代的 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、示例資料、部落格等；
- 在 CesiumJS@1.87.1 以上的例子實現
- ...
7. 譯者注
下一代的 3D Tiles 目前沒有定名為 3D Tiles 2.0，而是暫時以擴充套件項的方式推進。
它解決了一部分 1.0 中的問題，例如把後設資料從舊的瓦片檔案中的 BatchTable、FeatureTable 拆分出來，便於資料庫實現；拆出來後設資料後，剩下的三維資料可以直接利用 glTF 格式，而 glTF 格式本身又是可以把紋理、幾何分開儲存的。總之，新設計的靈活性非常強。
除了資料方面的問題，還提出了新的空間切分演算法 —— 隱式瓦片，這個擴充套件旨在提高前端瓦片剔除和渲染的效能。
總之，現在的狀態就是“請灑潘江，各傾陸海云爾”。