3dTiles 數據規範詳解[3] 內嵌在瓦片文件中的兩大數據表
- 2020 年 7 月 6 日
- 筆記
- 3D, 3dtile, 3dtiles, b3dm, batchtable, Cesium, featuretable, i3dm
轉載請聲明出處：全網@秋意正寒
零、本篇前言
說實話，我很糾結是先介紹瓦片的二進制數據文件結構，還是先介紹這兩個重要的表。思前想後，我決定還是先介紹這兩個數據表。
因為這兩個表不先給讀者灌輸，那麼介紹到瓦片的二進制數據文件結構時，就滿嘴「晦澀難懂」啦。
數據與模型
上文介紹到，瓦片的三維模型實際上是由gltf承擔起來的（作為glb格式嵌入到瓦片二進制文件中），那麼，除了模型數據，肯定模型自己本身也有屬性數據的。
就比如，門有長寬高、密度、生產日期等信息，樓棟模型有建築面積、樓層數等信息。
所以，「屬性數據」 和 「模型」 是如何產生聯繫的呢？
早在我的博客《聊聊GIS數據的四個分層與GIS服務》中有提及，只需把模型的幾何數據作為一個屬性，寫入屬性數據中，即把屬性數據和幾何數據並列，就可以了。
但是，在3dTiles中，模型數據是以glb的形式嵌入在瓦片文件中的（點雲直接就寫xyz和顏色信息了），模糊了二維中「要素」的概念，而且gltf規範看起來並沒有所謂的「要素」的概念，僅僅是對GPU友好的vertex、normal、texture等信息。
如何讓gltf模型的每一個模型，甚至每一個三角面，甚至每一個頂點打上「我屬於哪個模型」的印記呢？我們本篇稍稍晚一些介紹。
再回憶一個重要的 3dTiles 理念：
3dTiles 規範本身不包含模型數據的定義，它僅僅記錄模型變成瓦片後的空間組織關係、模型與其屬性數據之間的關係。
所以，3dTiles 規範在瓦片二進制數據文件中，使用了兩個重要的表來記錄這種 」模型與屬性「 的聯繫：
- FeatureTable（要素表）
- BatchTable（批量表）
瓦片二進制數據文件的大致位元組布局結構
上一篇簡單提過，瓦片引用的二進制文件有4種，即：b3dm、i3dm、pnts、cmpt。
除去cmpt這個複合類型不談，前三種的大致布局見上圖。
每一種瓦片二進制數據文件都有一個記錄該瓦片的文件頭信息，文件頭包括若干個因瓦片不同而不太一致的數據信息，緊隨其後的是兩大數據表：FeatureTable（我翻譯其為：要素表）、BatchTable（我翻譯其為：批量表）。
這兩個表既然是二進制的數據，儘管它名字裡帶「表」，但是卻不是二維表格，它更多的是一些 鍵值 信息。
關於不同瓦片二進制文件的這兩個表的結構，在後續博文會詳細介紹。
一、記錄渲染相關的數據：FeatureTable，要素表
在 b3dm 瓦片中，要素表記錄這個批量模型瓦片中模型的個數，這個模型單體在人類邏輯上不可再分。
（在房屋級別來看，房子並不是單體，構造它的門、門把、窗戶、屋頂、牆等才是模型單體；但是在模型殼子的普通表面建模數據中，房子就是一個簡單的模型）
要素表還可以記錄當前瓦片的中心坐標，以便gltf使用相對坐標，壓縮頂點坐標數字的數據量。
官方給的定義是：
要素表記錄的是與渲染有關的數據。
直球！聽不懂！
我來「翻譯」一下好了：
要素表，記錄的是整個瓦片渲染相關的數據，而不是渲染所需的數據。
渲染相關，即有多少個模型，坐標是相對的話相對於哪個中心，如果是點雲的話顏色信息是什麼以及坐標如何等；
渲染所需，例如頂點信息、法線貼圖材質信息均有glb部分完成。
我們以pnts（點雲瓦片）舉例，它的要素表允許有兩大類數據（看不懂沒關係，之後的博客還會繼續介紹四種瓦片文件的結構）：
- 點屬性：記錄每個點雲點的信息
| 屬性名 | 數據類型 | 描述 | 是否必須 |
|---|---|---|---|
| POSITION | float32 * 3 | 直角坐標的點 | 是，除非下面的屬性存在 |
| POSITION_QUANTIZED | uint16 * 3 | 量化的直角坐標點 | 是，除非上面的屬性存在 |
| RGBA | uint8 * 4 | 四通道顏色 | |
| RGB | uint8 * 3 | RGB顏色 | / |
| RGB565 | uint16 | 有損壓縮顏色，紅5綠6藍5，即65536種顏色 | / |
| NORMAL | float32 *3 | 法線 | / |
| NORMAL_OCT16P | uint8 * 2 | 點的法線，10進制單位向量，有16bit精度 | / |
| BATCH_ID | uint8/uint16(默認)/uint32 | 從BatchTable種檢索元數據的id | / |
- 全局屬性：記錄整個點雲瓦片的信息
| 屬性名 | 數據類型 | 描述 | 是否必須 |
|---|---|---|---|
| POINTS_LENGTH | uint32 | 瓦片中點的數量。所有的點屬性的長度必須與這個一樣。 | 是 |
| RTC_CENTER | float32 * 3 | 如果所有點是相對於某個點定位的，那麼這個屬性就是這個相對的點的坐標。 | / |
| QUANTIZED_VOLUME_OFFSET | float32 * 3 | 量化偏移值（不知道是什麼） | 與下面的屬性必須同時存在 |
| QUANTIZED_VOLUME_SCALE | float32 * 3 | 量化縮放比例（不知道是什麼） | 與上面的屬性必須同時存在 |
| CONSTANT_RGBA | uint8 * 4 | 為所有點定義同一個顏色 | / |
| BATCH_LENGTH | uint32 | BATCH_ID的個數 | 與點屬性中的BATCH_ID必須同時存在 |
簡略一瞥，可以看出點雲因為沒有使用gltf模型（也沒必要），把點雲要渲染到屏幕上所需的坐標、法線、顏色等信息寫在了要素表中。
如果還是不能理解何為「渲染相關」，那麼請閱讀後續四種瓦片文件格式的詳細介紹，相信你會有所收穫——有可能是我表達比較菜。
要說明一個「業界黑話」：
在一個瓦片中，一個三維要素（GIS中的通常叫法）= 一個模型（圖形學、工業建模叫法） = 一個BATCH（3dtiles叫法）
然後，我向讀者隆重介紹要素表的簡單結構，因為要素表、批量表都是以 二進制 形式存儲，所以了解每一種瓦片的二進制數據布局十分重要。
要素表的結構：JSON描述信息+要素表數據體
要素表緊隨在若干個位元組的文件頭後，它本身還可以再分為 二進制的JSON文本頭 + 二進制的數據體。
如下圖所示：
有迫不及待的讀者希望更進一步了解要素表了，不要急，後續篇章一定展開，例如如何讀取要素表和其中的數據等。
接下來，是另一個數據表：批量表。
二、記錄屬性數據：BatchTable，批量表
如果把批量表刪除，那麼3dTiles數據還能正常渲染。
是的，批量表就是所謂的模型屬性表，批量表中每個屬性數組的個數，就等於模型的個數，因為有多少個模型就對應多少個屬性嘛！
（嘿嘿，其實也有例外的情況，我們到後續聊3dtiles數據規範的擴展能力時，再把這個坑填上，不然怎麼說3dtiles很靈 [keng] 活 [die] 呢）
批量表相對比較自由，只要能與模型對得上號，想寫啥就寫啥。
批量表中的屬性數據 ↔ 模型的關聯
假定讀者在閱讀此 3dtiles 博客之前，已經對 gltf 數據規範有一定的了解。
gltf 數據有三層邏輯：Node ← Mesh ← Primitive。
其中，Primitive 即 gltf 數據規範中最小的圖形單位，其頂點定義由其下的 attributes 對象下 POSITION 屬性來尋找訪問器（Accessor），從而獲取到數據。
{
...
"meshes": [
{
"primitives": [
{
"attributes": {
"POSITION": 0,
"TEXTURE_0": 2
...
},
"indices": 1,
"mode": 4,
"material": 0
}
]
}
],
...
}
獲取到 POSITION 、indices 對應的訪問器、緩存視圖、緩存文件後，即可獲取 gltf 模型的所有頂點，即幾何模型，即三維要素的幾何數據。
現在問題來了，如何將這些頂點 「打」 上一個印記呢？就像檢疫的豬肉一樣，打個印記，說明豬是健康的。
Cesium團隊在設計 3dtiles 規範的時候充分利用了 gltf 規範的特點：開源。因此，每一個 primitive 被在其 attributes 中添加了額外的訪問器：_BATCHID。
它與 POSITION 等沒什麼兩樣，同樣會佔用一部分數據。聰明的讀者應該能想到了，如果每一個頂點都有一個所謂的 _BATCHID 對應，那麼我隨便給個點，我不就知道這個點的 _BATCHID，從而就知道這個點屬於哪一個 BATCH 了嗎？
翻翻前面的 「黑話」，GIS的讀者更容易關聯起來：
一個 BATCH （即三維要素）用自己的 BATCHID 與幾何數據一一對應，屬性數據也與這個 BATCHID 一一對應，由傳遞關係，那麼三維的幾何數據 (gltf) 也就能和 屬性數據 (批量表) 一一對應了。
不過遺憾的是，並不是所有的瓦片都有 gltf 模型，例如pnts瓦片。
所以這個 幾何 與 屬性 兩大數據如何關聯，在之後的博文再具體問題具體分析。
關於這個模型和屬性的關聯，在b3dm瓦片的博文中要重點介紹。
批量表的結構：JSON描述信息+批量表數據本體
與 要素表 很像，批量表也是由： 二進制的JSON文本頭 + 二進制的數據體 構成的。如下圖所示：
關於兩個表的更深層次的數據內容，例如如何承載模型與模型之間的邏輯關係，如何記錄使用 Google 壓縮算法的模型數據，那就是後續文章的內容了。
三、結語
本篇沒有特定的數據作為說明，寫得不太好，因為是第一次嘗試用自己的語言表達這兩大數據表，謀篇布局能力不太行，還請讀者包涵。
這兩個數據表真正的內容，還要等到接下來的四篇對瓦片二進制文件的重點介紹中，才能細細講完，本篇僅僅作為接下來四篇博客的 「總結」，也可以說是 「介紹」。
附：CesiumJS API 如何查詢瓦片的批量表
我們通常在Cesium中使用 點擊 事件，來獲取一個 BATCH，即三維要素。在Cesium API中，這個被叫做：Cesium3DTileFeature。
那麼，這個 Cesium3DTileFeature 就能訪問到它自己的批量表中的屬性數據：
const handler = new Cesium.ScreenSpaceEventHandler(viewer.canvas);
handler.setInputAction(function(movement) {
let feature = scene.pick(movement.endPosition);
if (feature instanceof Cesium.Cesium3DTileFeature) {
let propertyNames = feature.getPropertyNames();
let length = propertyNames.length;
for (var i = 0; i < length; ++i) {
let propertyName = propertyNames[i];
console.log(propertyName + ': ' + feature.getProperty(propertyName));
}
}
}, Cesium.ScreenSpaceEventType.LEFT_CLICK);
用到了 Cesium3DTileFeature.getPropertyNames() 方法獲取批量表中所有屬性名，用了 Cesium3DTileFeature.getProperty(string Name) 來獲取對應屬性名的屬性值。更多 API 見官方文檔。
