原文：Introducing 3D Tiles Next, Streaming Geospatial to the Metaverse
原文釋出時間：2021年11月10日
目錄
下一代的 3D Tiles 前瞻譯者概述
1. 綜述
2. 中繼資料的增強
2.1. 中繼資料的類型系統
2.2. 不同層級的中繼資料（像素級别樣式化渲染）
2.3. 語義規範
3. 空間索引增強：隐式瓦片分割空間分割算法：S2
4. 在三維“圖層”中使用複合内容
5. 與 glTF 技術生态內建
5.1. 直接使用 glTF（b3dm 與 i3dm 更新）
5.2. 點雲與 glTF（pnts 更新）
5.3. 繼承 glTF 的擴充項（紋理壓縮）
6. 後續進度
7. 譯者注
閱讀本文前，需要有足夠的 3D Tiles 1.0 基礎、glTF 規範基礎、CesiumJS 基礎。
3D Tiles Next 自官方有想法以來，我就一直在跟蹤，無奈年關将至，業務繁忙，現在才着手閱讀和學習。
3D Tiles Next 下文會簡稱 <code>Next</code>，而現行的 3D Tiles 1.0 則簡稱 <code>1.0</code>，因為官方暫時沒把下一代正式稱為 <code>2.0</code>.
從組織方式來說，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 資料加載架構 —— <code>ModelExperimental</code>，以及更友好的自定義着色器 API —— <code>CustomShader</code>。
<code>3D Tiles Next</code>，指的是一組 3D Tiles 擴充項。這些擴充項主要展現在三個方面的增強：
結構化的中繼資料
空間索引性能
glTF 生态內建
官方關于中繼資料的限定詞是 <code>semantic</code>，即語義化的，我覺得“結構化”可能更好一些。
如下圖所示：
鑒于需求的急劇擴張，3D Tiles 擴充了中繼資料方面的功能。在 3D Tiles Next 中，引入一些中繼資料方面的擴充項。主要特點有：
中繼資料的編碼方式更友好，可以用二進制，也可以寫入 JSON；
層級擴充，可以是每紋理單元級别的中繼資料，也可以是每個瓦片級别的；
規範了中繼資料的格式。
與 1.0 規範使用 Batchtable（批次表）來存儲中繼資料的目的一緻，Next 的中繼資料擴充依舊遵循了性能優勢：批量處理。
許多邏輯層面的三維要素（例如某個建築）及其中繼資料，在前端運作時（可以簡單認為是 CesiumJS）預先被成組成批處理，以減小 CPU 的開銷。
中繼資料方面的擴充，分三個方面：
類型系統；
編碼方式；
領域相關的語義化規範，領域是指 BIM、CAD 等；
3D 中繼資料規範 定義了一套類型規範與資料的編碼方式。
3D Tiles 1.0 依賴于 JSON 本身有限制的基礎類型，而 Next 具備更豐富的類型支援，包括類、向量、矩陣等。
中繼資料的編碼方式可以有：
二進制格式；
JSON 格式；
栅格格式。
具體細節要看規範。
配合使用 3DTILES_metadata 和 EXT_mesh_features 兩個擴充項，下一代的 3D Tiles 可以在各個層級存儲中繼資料。這些層級可以是：
Tileset（瓦片集）層級
Tile / Tile ContentGroup（瓦片或瓦片組）層級
Feature（三維要素）層級
GPU 繪制執行個體層級
Vertex（頂點）層級
Texel（紋素）層級
紋素級别是最細的層級，允許中繼資料在如此細的粒度上變化。
例如，兩個三角形構成一個四邊形，作為一個建築物的一側牆面，但是此時它僅僅是“兩個三角形”，在真實世界中牆面還可能會有窗的玻璃、磚的石頭的差別，在拾取識别時，就可以例用“紋素級别”的中繼資料來辨識什麼顔色是什麼物體。
下面是一個例子，對傾斜攝影資料使用紋素級别的中繼資料：
此處有分屏，左側的顔色就可以很明顯地區分出牆、窗戶、空調、屋頂等“實際物體”，而資料的三角面組織卻可以不用在意這些“實際物體”。
在右側，利用紋素級别的中繼資料，就可以完成窗戶單體的半透明處理。
除了層次足夠細緻，還要知道資料的含義，這就是所謂的“中繼資料的語義”，以便程式代碼知道怎麼進行互動程式設計。
例如，水泥地和草地的摩擦系數可以作為中繼資料，影響車輛的行駛速度等。
各領域的專家可以根據有關擴充項來定制自己專業所需的中繼資料，譬如在土方施工中，将材料庫存、各項參數寫入中繼資料，友善代碼計算體積和面積。
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 等規範內建實作。
3D Tiles Next 引入一項 3DTILES_bounding_volume_S2 擴充，它能與隐式瓦片、顯式瓦片一起使用，定義新的空間範圍體。
S2 分割是一種比四叉樹更好的空間分割，這種分割方式基于一個立方體，它在北極、南極附近的瓦片會比較“薄”，失真較小。同一級别的瓦片的尺寸是接近的。
筆者注：這個算法不太了解，需要閱讀更多資料。
上圖為 WGS84 橢球面上的 S2 Hilbert（希爾伯特）曲線。
傳統 2DGIS 會把同類資料放進同一個容器中，這個容器叫做“圖層”，比如高速公路圖層、POI圖層、建築圖層等，這樣可以統一樣式設定。
使用 3DTILES_multiple_contents 擴充可以在一組 Tile 中定義“三維圖層中繼資料”，然後将對應的三維資料綁定至這個組來實作“三維圖層”、“資料與中繼資料的連接配接”。
在 3D Tiles 中使用 3DTILES_content_gltf 擴充，Tile 對象可以直接引用 <code>.gltf</code> 或 <code>.glb</code> 檔案，而不是使用舊的 <code>b3dm</code>、<code>i3dm</code> 瓦片檔案。
這樣 3D Tiles 就可以直接利用 glTF 社群的成果，例如驗證工具、轉換工具等。
3D Tiles Next 利用到 glTF 的地方有：
3D Tiles 在瓦片層級直接使用 glTF 作為三維資料；
将 glTF 直接用于點雲格式；
更好利用了 glTF 的擴充項。
有閱讀 3D Tiles 1.0 規範的朋友知道，<code>b3dm</code> 和 <code>i3dm</code> 瓦片檔案是内嵌了 glTF 的二進制格式資料的。
上圖展示了 1.0 和 Next 的瓦片檔案設計差別，1.0 中最具代表性的 <code>b3dm</code> 瓦片檔案由頭部中繼資料（b3dm Header）、批次表（BatchTable）和具體模型資料（glTF）塊構成，而 Next 則直接使用 <code>glb</code> 檔案，且使用了 glTF 的 <code>EXT_mesh_features</code> 擴充來替代批次表。
使用 3DTILES_content_gltf 這個 3D Tiles 擴充，瓦片就可以直接引用 gltf 或 glb 檔案。如果瓦片中存在邏輯要素資訊，則可以在 gltf/glb 中啟用 glTF 的擴充：EXT_mesh_features.
但是如果是 <code>i3dm</code>，比如一個樹模型要繪制多次（即執行個體繪制的方式），那麼就使用 glTF 擴充 EXT_mesh_gpu_instancing 來實作，以替代 i3dm 瓦片。EXT_mesh_features 也可以跟這個擴充一起使用，來記錄每個被繪制後的執行個體的屬性資料，如下圖所示：
官方希望直接使用 glTF 的意圖是可以更好地與其他行業的資料進行合作，以提高 3D Tiles 的模型相容性。
上圖是某個城市的 100 億個點的點雲資料。
在 1.0 中，點雲資料是使用 <code>pnts</code> 格式的檔案存儲的，包括 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 等方式。
由于 Next 對瓦片檔案的更新替換，不再使用 b3dm、i3dm、pnts 瓦片檔案，是以功能上的更新基本上都是 glTF 的擴充。
3D Tiles Next 依舊會使用 glTF 的 KTX 2.0 和 下一代 PBR 材質等擴充。
KTX 2.0 是用來支援紋理資料的跨 GPU 傳輸、運作時壓縮，減少記憶體、帶寬等，以提升硬體效能，畢竟通過無人機或者衛星擷取的圖像的體積可不小。
下一代 PBR 召集了世界 PBR 專家來集思廣益，将 glTF 的材質表現提升到一個新的高度。
從發文時間起，之後的幾個月将完成規範的設計。
目前的進度有：
起草了 3D Tiles 與 glTF 相關的擴充項：
3D 中繼資料規範
3D Tiles 擴充：3DTILES_metadata
glTF 擴充：EXT_mesh_features
3D Tiles 擴充：3DTILES_implicit_tiling
3D Tiles 擴充：3DTILES_bounding_volume_S2
3D Tiles 擴充：3DTILES_multipie_contents
3D Tiles 擴充：3DTILES_content_gltf
開發者相關的資源，pdf、示例資料、部落格等；
在 [email protected] 以上的例子實作
...
下一代的 3D Tiles 目前沒有定名為 3D Tiles 2.0，而是暫時以擴充項的方式推進。
它解決了一部分 1.0 中的問題，例如把中繼資料從舊的瓦片檔案中的 BatchTable、FeatureTable 拆分出來，便于資料庫實作；拆出來中繼資料後，剩下的三維資料可以直接利用 glTF 格式，而 glTF 格式本身又是可以把紋理、幾何分開存儲的。總之，新設計的靈活性非常強。
除了資料方面的問題，還提出了新的空間切分算法 —— 隐式瓦片，這個擴充旨在提高前端瓦片剔除和渲染的性能。
總之，現在的狀态就是“請灑潘江，各傾陸海雲爾”。