原創，轉載請規范注明出處：https://www.cnblogs.com/onsummer/p/13252896.html
我的git地址：github.com/onsummer

B3dm，Batched 3D Model，成批量的三維模型的意思，

傾斜攝影資料（例如osgb）、BIM資料（如rvt）、傳統三維模型（如obj、dae、3dMax制作的模型等），均可創建此類瓦片，

瓦片檔案二進制布局（檔案結構）

① 檔案頭：占28位元組（byte）

位于b3dm檔案最開頭的28個位元組，是7個屬性資料：

其中，

byteLength = 28 + featureTableJSONByteLength + featureTableBinaryByteLength + batchTableJSONByteLength + batchTableBinaryByteLength + glb的位元組長度

② 要素表

回顧上篇，我說的是

要素表，記錄的是整個瓦片渲染相關的資料，而不是渲染所需的資料，

那么，b3dm瓦片中的要素表會記錄哪些資料呢？

全域屬性

什么是全域屬性？即對于瓦片每一個三維模型（或BATCH、要素）或者直接對當前瓦片有效的資料，在b3dm中，要素表有以下全域屬性：

注意，如果glb模型并不需要屬性資料，即要素表和批量表有可能是空表，那么 BATCH_LENGTH 的值應設為 0 .

*要素屬性

對于每個模型（BATCH、要素）各自獨立的資料，在b3dm中沒有，

我們回憶一下要素表的定義：與渲染相關的資料，

b3dm瓦片與渲染相關的資料都在glb中了，所以b3dm并不需要存盤每個模型各自獨立的資料，即不存在要素屬性，

在i3dm、pnts兩種瓦片中，要素屬性會非常多，

全域屬性存在哪里？

全域屬性存盤在 要素表的JSON中，見下文：

JSON頭部資料

由上圖可知，檔案頭28位元組資料之后是要素表，要素表前部是 長達 featureTableJSONByteLength 位元組的二進制JSON文本，利用各種語言內置的API可以將這段二進制資料轉換為字串，然后決議為JSON物件，

例如，這里決議了一個b3dm檔案的 要素表JSON：

{
    "BATCH_LENGTH": 4
}

那么，此b3dm瓦片就有4個模型（4個要素，或4個BATCH），其 batchId 是0、1、2、3.

要素表的二進制本體資料

無，

注：

當要素表的 JSON 資料以參考二進制體的方式出現時，資料才會記錄在要素表的二進制本體資料中，此時JSON記錄的是位元組偏移量等資訊，

但是在b3dm瓦片中，要素表只需要JSON就可以了，不需要自找麻煩再參考二進制資料，因為BATCH_LENGTH 和 RTC_CENTER 都相對好記錄，一個是數值，一個是3元素的陣列，

在下面的要介紹批量表中，就會出現 JSON 資料參考二進制體的情況了，在 i3dm 和 pnts 瓦片中，要素表 JSON就會大量參考其二進制體，

③ 批量表

批量表記錄的是每個模型的屬性資料，以及擴展資料（擴展資料以后再談），

要素表和批量表唯一的聯系就是 BATCH_LENGTH，在 i3dm 中叫 INSTANCE_LENGTH，在 pnts 中叫 POINTS_LENGTH，

這很好理解，要素表記錄了有多少個模型（BATCH、要素），那么批量表每個屬性就有多少個值，

JSON頭部資料

先上一份批量表的JSON看看：

{
    "height" : {
        "byteOffset" : 0,
        "componentType" : "FLOAT",
        "type" : "SCALAR"
    },   
    "geographic" : {
        "byteOffset" : 40,
        "componentType" : "DOUBLE",
        "type" : "VEC3"
    },
}

這個批量表的JSON有兩個屬性：height、geographic，字面義即模型的高度值、地理坐標值，

height 屬性通過其 componentType 指定資料的值型別為 FLOAT，通過其 type 指定資料的元素型別為 SCALAR（即標量），

geographic 屬性通過其 componentType 指定資料的的值型別是 DOUBLE，通過其 type 指定資料的元素型別為 VEC3（即3個double數字構成的三維向量），

byteOffset ，即這個屬性值在 二進制本體資料 中從哪個位元組開始存盤，

從上表可以看出，height 屬性跨越 0 ~ 39 位元組，一共40個位元組，

通過 FeatureTableJSON 可以獲取 BATCH_LENGTH 為10，那么就有10個模型，對應的，這 40 個位元組就存盤了10個 height 值，查相關資料得知，FLOAT型別的資料位元組長度為 4，剛好 4 byte × 10 = 40 byte，即 height 屬性的全部資料的總長，

geographic 屬性也同理，VEC3 代表一個 geographic 有3個 DOUBLE 型別的數字，一個 DOUBLE 數值占 8byte，那么 geographic 一共資料總長是：

type × componentType × BATCH_LENGTH = 3 × 8byte × 10 = 240 byte.

事實上，兩個屬性的總長是 40 + 240 = 280 byte，與 b3dm 檔案頭中的第七個屬性 batchTableBinaryByteLength = 280 是一致的，

二進制本體資料

二進制本體資料即批量表中每個屬性的順次存盤，

能不能不寫二進制本體資料？

可以，如果你覺得資料量比較小，可以直接把資料寫在 BatchTableJSON 中，還是以上述兩個資料為例：

{
    "height": [10.0, 20.0, 15.0, ...], // 太長了不寫那么多，一共10個
    "geographic": [
        [113.42, 23.10, 102.1],
        [111.08, 22.98, 24.94],
    	// 太長不寫
    ]
}

但是，讀者請一定注意這一點：同樣是一個數字，二進制的JSON文本大多數時候體積會比二進制資料大，因為JSON文本還包括括號、逗號、冒號等JSON文本必須的符號，對于屬性資料相當大的情況，建議使用 JSON參考二進制本體資料的組織形式，此時JSON充當的角色是元資料，

注意：對于屬性的值型別是 JSON 中的 object、string、bool 型別，則必須存于 JSON 中，因為二進制體只能存 標量、234維向量四種型別的數字資料，

④ 內嵌的glb

本部分略，對glb資料感興趣的讀者可自行查閱 glTF 資料規范，

關于兩大資料表如何與glb每一個頂點進行關聯的，在前篇也有簡略介紹，可以參考官方的說明：

https://github.com/CesiumGS/3d-tiles/tree/master/specification/TileFormats/Batched3DModel#binary-gltf

⑤ 位元組對齊與編碼端序

JSON二進制文本對齊

FeatureTableJSON、BatchTableJSON的二進制文本，最后一個位元組相對于整個b3dm檔案來說，偏移量必須是8的倍數，

如果不對齊，必須用二進制空格（即 0x20）填夠，

你問我為啥不對起始偏移量也要求 8byte 對齊？因為 FeatureTableJSON 之前是28byte的 檔案頭，為了湊齊8倍數對齊，檔案頭和 FeatureTableJSON 還要塞4個位元組填滿，那就有點多余了，

末尾對齊，即 (28 + ftJSON長)能整除8，(28 + ftTable長 + btJSON長)能整除8.

資料體的起始、末尾對齊

二進制資料體，無論是要素表、批量表，首個位元組相對于b3dm檔案的位元組偏移量，必須是8的倍數，結束位元組的位元組偏移量，也必須是8的倍數，

如果不滿足，可以填充任意資料位元組滿足此要求，

特別的，二進制資料體中，每一個屬性值的第一個數值的第一個位元組的偏移量，相對于整個b3dm檔案，必須是其 componentType 的倍數，如果不滿足，則必須用空白位元組填滿，

例如，上述 height 屬性所在的批量表二進制資料體，理所當然位于批量表JSON之后，而批量表的JSON又是8byte對齊的，假設批量表的資料體起始位元組是800，那么 height 的第一個值起始位元組就是 800，由于 height 屬性的 componentType 是 FLOAT，即 4位元組，800 ÷ 4 能整除，所以沒有問題，

但是，假如 換一個屬性，其 componentType 是 BYTE，即 1位元組，那么假設第二個屬性的 componentType 是 DOUBLE，即 8位元組，就會出現 第二個屬性的第一個值起始偏移量是810，810 ÷ 8 并不能整除，必須補齊 6個空白位元組，以滿足第二個屬性第一個值的起始偏移量是 810+6 = 816位元組，

編碼端序

要素表、批量表的二進制資料，無論是JSON還是資料體，均使用小端序編碼（LittleEndian），

⑥ 擴展資料（extensions）與額外補充資訊（extras）

其實，無論是要素表，還是批量表，都允許在JSON中存在擴展資料，以擴充當前瓦片模型的功能，而并不是單一的一個一個模型順次存盤在瓦片檔案、glb中，

有關擴展資料，在以后會專門出一篇博客介紹，

標籤：GIS

上一篇：關于Append和ObjectLoader性能對比

下一篇：3dTiles 資料規范詳解[4.2] i3dm瓦片二進制資料檔案結構