3dTiles 數據規範詳解[2] Tileset與Tile

轉載請聲明出處：全網@秋意正寒 http://www.javashuo.com/article/p-xugyfwqx-mh.html

1、一個簡單的3dTiles數據示例

上圖是一份 3dTiles數據集在文件夾內的樣子，層層打開可得如下特色：

• 入口文件是 tileset.json
• 各級瓦片用文件夾（目錄）來組織

3dTiles 數據目前的具體文件實現，是一些零散的文件。

數據集的名稱與所在文件夾的名稱並沒有關係，數據集的名稱寫在入口文件中。

3dTiles至少有一個 tileset.json 文件，做爲整個數據集的入口。它是一個 json 文件，描述了整個三維瓦片數據集，它記錄的是上一節說起的「邏輯信息」，還包括一些其餘的元數據。而「屬性信息」、「嵌入的gltf模型」 則位於各個二進制瓦片文件中，這些二進制文件則由 tileset.json 中的瓦片中的 uri 來引用。

瓦片是什麼？

瓦片，屋頂上的瓦片。古時候，蓋房子，屋頂不能一次澆築完工，也沒有特定的「屋頂」零件，因此只好一片片瓦片蓋上去（我瞎掰的）。

瓦片切割了三維數據，容許三維數據進行細分。咱們都知道網速是有限的，在加載超大規模的三維模型數據時，不可能把一個模型所有下載下來再渲染，那樣等待的時間太慢了，可是一點一點出現，視野範圍外的「瓦片」則乾脆就不下載、渲染，性能、視覺都有提升。這就是瓦片的設計優勢。

傳統的二維地圖瓦片，叫作 WMTS 或 TMS，這個 "T" 就是 Tile 的意思。

如今，你只要知道，3dTiles就是把空間進行切塊，每一個塊叫作 「tile」，也即瓦片。至於怎麼切的——待會介紹 tileset.json 時，會隆重介紹樹結構。

瓦片只有兩種狀況：葉子瓦片，非葉子瓦片。根瓦片也是非葉子瓦片。非葉子瓦片和葉子瓦片有什麼區別呢？主要就是葉子瓦片不會再有孩子了（樹結構的知識哈，不懂的建議去學習數據結構中的樹）。

瓦片包含什麼內容呢？本篇稍微靠後再仔細瞭解瓦片。

如今，咱們先認識一下，描述整個 3dTiles 數據集的入口文件，也叫作三維瓦片數據集 —— tileset.json：

2、Tileset——(三維)瓦片數據集

一般，一個三維瓦片數據集（以後簡稱：一個3dtiles數據）的入口就是那個」tileset.json「，至於這個文件的名稱可不能夠改，暫時未做測試。

如今，咱們先來研究研究 這個入口文件記錄了哪些信息，拿一份最簡單的 3dtiles數據來舉例，該數據只有一個根瓦片（root），根瓦片再無子瓦片。

root對象中有一個content，內有uri屬性，其就記錄了根瓦片的二進制數據文件的URL，這個URL是個相對路徑，相對於 tileset.json 文件。

① 頂級屬性概覽

經過上面介紹，3dTiles數據的入口文件是一個名叫 tileset.json 的文件，而一般來講，這個json必須存在如下幾個頂級對象：

• asset
• root
• geometricError

因爲本人學識有限，目前不太清楚 geometricError 的精確含義，只知道這個數值的大小能控制 LOD 的顯示隱藏，且這個數值父級瓦片必定比子級瓦片大。

asset 對象，記錄了整個數據集的聲明和歸屬數據，相似於數據聲明，能在此寫入 version、tilesetVersion 等屬性，固然也能夠像上方的例子同樣，寫入生成工具、gltf朝向等信息。

root 對象，即這個數據集的根瓦片，每一個3dTiles數據集必須有一個 root 對象。

至於 tileset.json 中其餘的頂級對象，請查閱官方文檔：點我

② root瓦片及其children

樹結構對於三維空間數據的組織有很大的優點。3dTiles在空間上容許數據集使用以下幾種樹結構：

• 四叉樹
• 八叉樹
• KD樹
• 格網結構

四叉樹容許使用傳統的均勻四叉樹，也容許使用鬆散四叉樹等變種（例如，容許子節點，即子瓦片容許存在空間範圍重疊）。

上圖爲兩個子瓦片在空間上存在部分重疊，照顧到了建築物不可能嚴格切分的特色。

四叉樹對在高度上不太好切分的數據比較適合，而若是追求極致的空間分割和分級（例如點雲數據），那麼八叉樹更合適。

八叉樹也容許使用各類變種。

kd樹比較難理解，在此不做展開，這也是一種有趣的空間結構分割的數據結構。

格網結構的樹容許瓦片存在多個子瓦片：

一般出如今傾斜攝影數據上，可是這會致使網絡請求過多的問題。

③ 座標系統

咱們能夠用簡單的兩位數、三位數：經緯度，還有一個高度來標識地球表面附近的任何一個點。經緯度的範圍不超過三位數，而用米做單位的空間直角座標系來描繪地球，數字太大，很差記憶。

在GIS中，WGS84就是一個用經緯度來標識空間座標的「地理座標系，Geographic Coordinate System」。

因爲歷史上對地球測量的技術不一樣，科學家制造了多個長半軸短半軸不太同樣的「橢球」，來模擬地球的形狀。目前，最具表明性的就是兩個以地球質心爲中心的橢球體：

• WGS84橢球體
• 中國國家2000橢球體（即CGCS2000）

基於橢球體，咱們容許有多種不一樣的座標系定義，WGS84座標系其實並不太嚴謹。基於WGS84橢球（長短半軸等信息自行查詢哈），可使用球面座標度量，即經緯度，還有一個從質心射向橢球面上的點的「橢球高度」射線，來記錄第三維高度數據。

介紹了那麼多，3dTiles其實採用的是WGS84橢球，可是並未採用經緯度記錄數據：由於相對於精細三維模型來講，經緯度不足以提供足夠精確的空間分割（要照顧圖形顯示問題）。因此，一樣是那個形狀，3dTiles使用了同一個WGS84橢球，可是更方便計算的座標：空間直角座標。

用經緯度記錄數據的WGS84座標系，WKID是4326，用地心爲座標原點的空間直角座標來記錄數據的座標系，WKID是4979.

3dTiles 用的就是4979座標系。

3、Tile——構成3dtiles的成員：瓦片

一般，瓦片對象會引用一個二進制的瓦片數據文件（也有例外，往下拉一點會說）：

在1.0 版本的規範中，瓦片所引用的二進制的瓦片數據文件，有四種類型：

類型	英文名稱	文件後綴名
批量三維模型	Batch 3D Model	b3dm
實例三維模型	Instance 3D Model	i3dm
點雲	PointCloud	pnts
複合模型	Component	cmpt

這些不一樣的瓦片對應了些什麼數據呢？本篇只貼一張各類數據類型的截圖和信息對比表：

瓦片類型	對應實際數據
b3dm	傳統三維建模數據、BIM數據、傾斜攝影數據
i3dm	一個模型屢次渲染的數據，燈塔、樹木、椅子等
pnts	點雲數據
cmpt	前三種數據的複合（容許一個cmpt文件內嵌多個其餘類型的瓦片）

關於這些二進制瓦片數據文件的數據結構如何，下一篇開始會詳細展開。

如今，咱們關注一下，瓦片對象的職能，也就是，它記錄了啥信息：

這是一個children下的第一個瓦片，觀察不可貴知，與root瓦片其實在屬性上長得如出一轍。

瓦片對象都有以下屬性：

• boundingVolume：空間範圍框，容許有box、sphere、region三種範圍框，可是隻能定義一種
• geometricError：幾何偏差
• content：瓦片內容，uri屬性引用二進制瓦片數據文件。
• 其餘屬性：viewerRequestVolume、transform

沒錯，瓦片對象記錄的就是瓦片的元數據，真正瓦片的本體數據在content所引用的二進制文件中。

瓦片還能夠再引用 3dTiles 數據集！

我一再強調3dTiles十分靈活。

Tile不只僅能夠在其uri屬性中引用 諸如 .b3dm、.i3dm、.pnts等二進制瓦片數據文件，還能夠再引用一個 3dTiles！

這是一份從osgb傾斜攝影數據轉換而來的3dtiles數據，清晰可見在root瓦片的第一個child瓦片中，引用了另一個json文件。這證實了兩件事：

• 3dTiles的文件名能夠不是tileset.json
• 3dTiles容許套娃

原則上，只要被引用的子一級3dtiles 不循環引用父級3dtiles，那麼就OK（規範如是說）。

它真的很靈活！

---

下一節將展現二進制瓦片文件中的相當重要的一部分：兩大數據表。