轉(zhuǎn)載請聲明出處：全網(wǎng)@秋意正寒

零、本篇前言

說實話，我很糾結是先介紹瓦片的二進制數(shù)據(jù)文件結構，還是先介紹這兩個重要的表。思前想后，我決定還是先介紹這兩個數(shù)據(jù)表。

因為這兩個表不先給讀者灌輸，那么介紹到瓦片的二進制數(shù)據(jù)文件結構時，就滿嘴“晦澀難懂”啦。

數(shù)據(jù)與模型

上文介紹到，瓦片的三維模型實際上是由gltf承擔起來的（作為glb格式嵌入到瓦片二進制文件中），那么，除了模型數(shù)據(jù)，肯定模型自己本身也有屬性數(shù)據(jù)的。

就比如，門有長寬高、密度、生產(chǎn)日期等信息，樓棟模型有建筑面積、樓層數(shù)等信息。

所以，“屬性數(shù)據(jù)” 和 “模型” 是如何產(chǎn)生聯(lián)系的呢？

早在我的博客《聊聊GIS數(shù)據(jù)的四個分層與GIS服務》中有提及，只需把模型的幾何數(shù)據(jù)作為一個屬性，寫入屬性數(shù)據(jù)中，即把屬性數(shù)據(jù)和幾何數(shù)據(jù)并列，就可以了。

但是，在3dTiles中，模型數(shù)據(jù)是以glb的形式嵌入在瓦片文件中的（點云直接就寫xyz和顏色信息了），模糊了二維中“要素”的概念，而且gltf規(guī)范看起來并沒有所謂的“要素”的概念，僅僅是對GPU友好的vertex、normal、texture等信息。

如何讓gltf模型的每一個模型，甚至每一個三角面，甚至每一個頂點打上“我屬于哪個模型”的印記呢？我們本篇稍稍晚一些介紹。

再回憶一個重要的 3dTiles 理念：

3dTiles 規(guī)范本身不包含模型數(shù)據(jù)的定義，它僅僅記錄模型變成瓦片后的空間組織關系、模型與其屬性數(shù)據(jù)之間的關系。

所以，3dTiles 規(guī)范在瓦片二進制數(shù)據(jù)文件中，使用了兩個重要的表來記錄這種 ”模型與屬性“ 的聯(lián)系：

• FeatureTable（要素表）
• BatchTable（批量表）

瓦片二進制數(shù)據(jù)文件的大致字節(jié)布局結構

上一篇簡單提過，瓦片引用的二進制文件有4種，即：b3dm、i3dm、pnts、cmpt。

除去cmpt這個復合類型不談，前三種的大致布局見上圖。

每一種瓦片二進制數(shù)據(jù)文件都有一個記錄該瓦片的文件頭信息，文件頭包括若干個因瓦片不同而不太一致的數(shù)據(jù)信息，緊隨其后的是兩大數(shù)據(jù)表：FeatureTable（我翻譯其為：要素表）、BatchTable（我翻譯其為：批量表）。

這兩個表既然是二進制的數(shù)據(jù)，盡管它名字里帶“表”，但是卻不是二維表格，它更多的是一些 鍵值 信息。

關于不同瓦片二進制文件的這兩個表的結構，在后續(xù)博文會詳細介紹。

一、記錄渲染相關的數(shù)據(jù)：FeatureTable，要素表

在 b3dm 瓦片中，要素表記錄這個批量模型瓦片中模型的個數(shù)，這個模型單體在人類邏輯上不可再分。

（在房屋級別來看，房子并不是單體，構造它的門、門把、窗戶、屋頂、墻等才是模型單體；但是在模型殼子的普通表面建模數(shù)據(jù)中，房子就是一個簡單的模型）

要素表還可以記錄當前瓦片的中心坐標，以便gltf使用相對坐標，壓縮頂點坐標數(shù)字的數(shù)據(jù)量。

官方給的定義是：

要素表記錄的是與渲染有關的數(shù)據(jù)。

直球！聽不懂！

我來“翻譯”一下好了：

要素表，記錄的是整個瓦片渲染相關的數(shù)據(jù)，而不是渲染所需的數(shù)據(jù)。

渲染相關，即有多少個模型，坐標是相對的話相對于哪個中心，如果是點云的話顏色信息是什么以及坐標如何等；

渲染所需，例如頂點信息、法線貼圖材質(zhì)信息均有glb部分完成。

我們以pnts（點云瓦片）舉例，它的要素表允許有兩大類數(shù)據(jù)（看不懂沒關系，之后的博客還會繼續(xù)介紹四種瓦片文件的結構）：

• 點屬性：記錄每個點云點的信息

• 全局屬性：記錄整個點云瓦片的信息

簡略一瞥，可以看出點云因為沒有使用gltf模型（也沒必要），把點云要渲染到屏幕上所需的坐標、法線、顏色等信息寫在了要素表中。

如果還是不能理解何為“渲染相關”，那么請閱讀后續(xù)四種瓦片文件格式的詳細介紹，相信你會有所收獲——有可能是我表達比較菜。

要說明一個“業(yè)界黑話”：

在一個瓦片中，一個三維要素（GIS中的通常叫法）= 一個模型（圖形學、工業(yè)建模叫法） = 一個BATCH（3dtiles叫法）

然后，我向讀者隆重介紹要素表的簡單結構，因為要素表、批量表都是以 二進制 形式存儲，所以了解每一種瓦片的二進制數(shù)據(jù)布局十分重要。

要素表的結構：JSON描述信息+要素表數(shù)據(jù)體

要素表緊隨在若干個字節(jié)的文件頭后，它本身還可以再分為 二進制的JSON文本頭 + 二進制的數(shù)據(jù)體。

如下圖所示：

有迫不及待的讀者希望更進一步了解要素表了，不要急，后續(xù)篇章一定展開，例如如何讀取要素表和其中的數(shù)據(jù)等。

接下來，是另一個數(shù)據(jù)表：批量表。

二、記錄屬性數(shù)據(jù)：BatchTable，批量表

如果把批量表刪除，那么3dTiles數(shù)據(jù)還能正常渲染。

是的，批量表就是所謂的模型屬性表，批量表中每個屬性數(shù)組的個數(shù)，就等于模型的個數(shù)，因為有多少個模型就對應多少個屬性嘛！

（嘿嘿，其實也有例外的情況，我們到后續(xù)聊3dtiles數(shù)據(jù)規(guī)范的擴展能力時，再把這個坑填上，不然怎么說3dtiles很靈 [keng] 活 [die] 呢）

批量表相對比較自由，只要能與模型對得上號，想寫啥就寫啥。

批量表中的屬性數(shù)據(jù) ? 模型的關聯(lián)

假定讀者在閱讀此 3dtiles 博客之前，已經(jīng)對 gltf 數(shù)據(jù)規(guī)范有一定的了解。

gltf 數(shù)據(jù)有三層邏輯：Node ← Mesh ← Primitive。

其中，Primitive 即 gltf 數(shù)據(jù)規(guī)范中最小的圖形單位，其頂點定義由其下的 attributes 對象下 POSITION 屬性來尋找訪問器（Accessor），從而獲取到數(shù)據(jù)。

{
    ...
    "meshes": [
       {
           "primitives": [
               {
                   "attributes": {
                       "POSITION": 0,
                       "TEXTURE_0": 2
                       ...
                   },
                   "indices": 1,
                   "mode": 4,
                   "material": 0
               }
           ]
       } 
    ],
    ...
}

獲取到 POSITION 、indices 對應的訪問器、緩存視圖、緩存文件后，即可獲取 gltf 模型的所有頂點，即幾何模型，即三維要素的幾何數(shù)據(jù)。

現(xiàn)在問題來了，如何將這些頂點 “打” 上一個印記呢？就像檢疫的豬肉一樣，打個印記，說明豬是健康的。

Cesium團隊在設計 3dtiles 規(guī)范的時候充分利用了 gltf 規(guī)范的特點：開源。因此，每一個 primitive 被在其 attributes 中添加了額外的訪問器：_BATCHID。

"primitives": [
    {
        "attributes": {
            "POSITION": 0,
            "_BATCHID": 3,
            "TEXTURE_0": 2
            ...
        },
        "indices": 1,
        "mode": 4,
        "material": 0
    }
]

它與 POSITION 等沒什么兩樣，同樣會占用一部分數(shù)據(jù)。聰明的讀者應該能想到了，如果每一個頂點都有一個所謂的 _BATCHID 對應，那么我隨便給個點，我不就知道這個點的 _BATCHID，從而就知道這個點屬于哪一個 BATCH 了嗎？

翻翻前面的 “黑話”，GIS的讀者更容易關聯(lián)起來：

一個 BATCH （即三維要素）用自己的 BATCHID 與幾何數(shù)據(jù)一一對應，屬性數(shù)據(jù)也與這個 BATCHID 一一對應，由傳遞關系，那么三維的幾何數(shù)據(jù) (gltf) 也就能和 屬性數(shù)據(jù) (批量表) 一一對應了。

不過遺憾的是，并不是所有的瓦片都有 gltf 模型，例如pnts瓦片。

所以這個 幾何 與 屬性 兩大數(shù)據(jù)如何關聯(lián)，在之后的博文再具體問題具體分析。

關于這個模型和屬性的關聯(lián)，在b3dm瓦片的博文中要重點介紹。

批量表的結構：JSON描述信息+批量表數(shù)據(jù)本體

與 要素表 很像，批量表也是由： 二進制的JSON文本頭 + 二進制的數(shù)據(jù)體 構成的。如下圖所示：

關于兩個表的更深層次的數(shù)據(jù)內(nèi)容，例如如何承載模型與模型之間的邏輯關系，如何記錄使用 Google 壓縮算法的模型數(shù)據(jù)，那就是后續(xù)文章的內(nèi)容了。

三、結語

本篇沒有特定的數(shù)據(jù)作為說明，寫得不太好，因為是第一次嘗試用自己的語言表達這兩大數(shù)據(jù)表，謀篇布局能力不太行，還請讀者包涵。

這兩個數(shù)據(jù)表真正的內(nèi)容，還要等到接下來的四篇對瓦片二進制文件的重點介紹中，才能細細講完，本篇僅僅作為接下來四篇博客的 “總結”，也可以說是 “介紹”。

附：CesiumJS API 如何查詢瓦片的批量表

我們通常在Cesium中使用 點擊 事件，來獲取一個 BATCH，即三維要素。在Cesium API中，這個被叫做：Cesium3DTileFeature。

那么，這個 Cesium3DTileFeature 就能訪問到它自己的批量表中的屬性數(shù)據(jù)：

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 見官方文檔。