轉載請宣告出處:全網@秋意正寒
零、本篇前言
說實話,我很糾結是先介紹瓦片的二進制資料檔案結構,還是先介紹這兩個重要的表,思前想后,我決定還是先介紹這兩個資料表,
因為這兩個表不先給讀者灌輸,那么介紹到瓦片的二進制資料檔案結構時,就滿嘴“晦澀難懂”啦,
資料與模型
上文介紹到,瓦片的三維模型實際上是由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,
"primitives": [
{
"attributes": {
"POSITION": 0,
"_BATCHID": 3,
"TEXTURE_0": 2
...
},
"indices": 1,
"mode": 4,
"material": 0
}
]
它與 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 見官方檔案,
轉載請註明出處,本文鏈接:https://www.uj5u.com/qiye/782.html
標籤:GIS
