原創(chuàng)。轉(zhuǎn)載請(qǐng)規(guī)范注明出處：https://www.cnblogs.com/onsummer/p/13252896.html
我的git地址：github.com/onsummer

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

傾斜攝影數(shù)據(jù)（例如osgb）、BIM數(shù)據(jù)（如rvt）、傳統(tǒng)三維模型（如obj、dae、3dMax制作的模型等），均可創(chuàng)建此類瓦片。

瓦片文件二進(jìn)制布局（文件結(jié)構(gòu)）

① 文件頭：占28字節(jié)（byte）

位于b3dm文件最開頭的28個(gè)字節(jié)，是7個(gè)屬性數(shù)據(jù)：

其中，

byteLength = 28 + featureTableJSONByteLength + featureTableBinaryByteLength + batchTableJSONByteLength + batchTableBinaryByteLength + glb的字節(jié)長(zhǎng)度

② 要素表

回顧上篇，我說(shuō)的是

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

那么，b3dm瓦片中的要素表會(huì)記錄哪些數(shù)據(jù)呢？

全局屬性

什么是全局屬性？即對(duì)于瓦片每一個(gè)三維模型（或BATCH、要素）或者直接對(duì)當(dāng)前瓦片有效的數(shù)據(jù)，在b3dm中，要素表有以下全局屬性：

注意，如果glb模型并不需要屬性數(shù)據(jù)，即要素表和批量表有可能是空表，那么 BATCH_LENGTH 的值應(yīng)設(shè)為 0 .

*要素屬性

對(duì)于每個(gè)模型（BATCH、要素）各自獨(dú)立的數(shù)據(jù)。在b3dm中沒有。

我們回憶一下要素表的定義：與渲染相關(guān)的數(shù)據(jù)。

b3dm瓦片與渲染相關(guān)的數(shù)據(jù)都在glb中了，所以b3dm并不需要存儲(chǔ)每個(gè)模型各自獨(dú)立的數(shù)據(jù)，即不存在要素屬性。

在i3dm、pnts兩種瓦片中，要素屬性會(huì)非常多。

全局屬性存在哪里？

全局屬性存儲(chǔ)在 要素表的JSON中，見下文：

JSON頭部數(shù)據(jù)

由上圖可知，文件頭28字節(jié)數(shù)據(jù)之后是要素表，要素表前部是 長(zhǎng)達(dá) featureTableJSONByteLength 字節(jié)的二進(jìn)制JSON文本，利用各種語(yǔ)言內(nèi)置的API可以將這段二進(jìn)制數(shù)據(jù)轉(zhuǎn)換為字符串，然后解析為JSON對(duì)象。

例如，這里解析了一個(gè)b3dm文件的 要素表JSON：

{
    "BATCH_LENGTH": 4
}

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

要素表的二進(jìn)制本體數(shù)據(jù)

無(wú)。

注：

當(dāng)要素表的 JSON 數(shù)據(jù)以引用二進(jìn)制體的方式出現(xiàn)時(shí)，數(shù)據(jù)才會(huì)記錄在要素表的二進(jìn)制本體數(shù)據(jù)中，此時(shí)JSON記錄的是字節(jié)偏移量等信息。

但是在b3dm瓦片中，要素表只需要JSON就可以了，不需要自找麻煩再引用二進(jìn)制數(shù)據(jù)，因?yàn)?code>BATCH_LENGTH 和 RTC_CENTER 都相對(duì)好記錄，一個(gè)是數(shù)值，一個(gè)是3元素的數(shù)組。

在下面的要介紹批量表中，就會(huì)出現(xiàn) JSON 數(shù)據(jù)引用二進(jìn)制體的情況了。在 i3dm 和 pnts 瓦片中，要素表 JSON就會(huì)大量引用其二進(jìn)制體。

③ 批量表

批量表記錄的是每個(gè)模型的屬性數(shù)據(jù)，以及擴(kuò)展數(shù)據(jù)（擴(kuò)展數(shù)據(jù)以后再談）。

要素表和批量表唯一的聯(lián)系就是 BATCH_LENGTH，在 i3dm 中叫 INSTANCE_LENGTH，在 pnts 中叫 POINTS_LENGTH。

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

JSON頭部數(shù)據(jù)

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

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

這個(gè)批量表的JSON有兩個(gè)屬性：height、geographic，字面義即模型的高度值、地理坐標(biāo)值。

height 屬性通過其 componentType 指定數(shù)據(jù)的值類型為 FLOAT，通過其 type 指定數(shù)據(jù)的元素類型為 SCALAR（即標(biāo)量）。

geographic 屬性通過其 componentType 指定數(shù)據(jù)的的值類型是 DOUBLE，通過其 type 指定數(shù)據(jù)的元素類型為 VEC3（即3個(gè)double數(shù)字構(gòu)成的三維向量）。

byteOffset ，即這個(gè)屬性值在 二進(jìn)制本體數(shù)據(jù) 中從哪個(gè)字節(jié)開始存儲(chǔ)。

從上表可以看出，height 屬性跨越 0 ~ 39 字節(jié)，一共40個(gè)字節(jié)。

通過 FeatureTableJSON 可以獲取 BATCH_LENGTH 為10，那么就有10個(gè)模型，對(duì)應(yīng)的，這 40 個(gè)字節(jié)就存儲(chǔ)了10個(gè) height 值，查相關(guān)資料得知，F(xiàn)LOAT類型的數(shù)據(jù)字節(jié)長(zhǎng)度為 4，剛好 4 byte × 10 = 40 byte，即 height 屬性的全部數(shù)據(jù)的總長(zhǎng)。

geographic 屬性也同理，VEC3 代表一個(gè) geographic 有3個(gè) DOUBLE 類型的數(shù)字，一個(gè) DOUBLE 數(shù)值占 8byte，那么 geographic 一共數(shù)據(jù)總長(zhǎng)是：

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

事實(shí)上，兩個(gè)屬性的總長(zhǎng)是 40 + 240 = 280 byte，與 b3dm 文件頭中的第七個(gè)屬性 batchTableBinaryByteLength = 280 是一致的。

二進(jìn)制本體數(shù)據(jù)

二進(jìn)制本體數(shù)據(jù)即批量表中每個(gè)屬性的順次存儲(chǔ)。

能不能不寫二進(jìn)制本體數(shù)據(jù)？

可以。如果你覺得數(shù)據(jù)量比較小，可以直接把數(shù)據(jù)寫在 BatchTableJSON 中，還是以上述兩個(gè)數(shù)據(jù)為例：

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

但是，讀者請(qǐng)一定注意這一點(diǎn)：同樣是一個(gè)數(shù)字，二進(jìn)制的JSON文本大多數(shù)時(shí)候體積會(huì)比二進(jìn)制數(shù)據(jù)大。因?yàn)镴SON文本還包括括號(hào)、逗號(hào)、冒號(hào)等JSON文本必須的符號(hào)。對(duì)于屬性數(shù)據(jù)相當(dāng)大的情況，建議使用 JSON引用二進(jìn)制本體數(shù)據(jù)的組織形式，此時(shí)JSON充當(dāng)?shù)慕巧窃獢?shù)據(jù)。

注意：對(duì)于屬性的值類型是 JSON 中的 object、string、bool 類型，則必須存于 JSON 中，因?yàn)槎M(jìn)制體只能存 標(biāo)量、234維向量四種類型的數(shù)字?jǐn)?shù)據(jù)。

④ 內(nèi)嵌的glb

本部分略，對(duì)glb數(shù)據(jù)感興趣的讀者可自行查閱 glTF 數(shù)據(jù)規(guī)范。

關(guān)于兩大數(shù)據(jù)表如何與glb每一個(gè)頂點(diǎn)進(jìn)行關(guān)聯(lián)的，在前篇也有簡(jiǎn)略介紹?？梢詤⒖脊俜降恼f(shuō)明：

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

⑤ 字節(jié)對(duì)齊與編碼端序

JSON二進(jìn)制文本對(duì)齊

FeatureTableJSON、BatchTableJSON的二進(jìn)制文本，最后一個(gè)字節(jié)相對(duì)于整個(gè)b3dm文件來(lái)說(shuō)，偏移量必須是8的倍數(shù)。

如果不對(duì)齊，必須用二進(jìn)制空格（即 0x20）填夠。

你問我為啥不對(duì)起始偏移量也要求 8byte 對(duì)齊？因?yàn)?FeatureTableJSON 之前是28byte的 文件頭，為了湊齊8倍數(shù)對(duì)齊，文件頭和 FeatureTableJSON 還要塞4個(gè)字節(jié)填滿，那就有點(diǎn)多余了。

末尾對(duì)齊，即 (28 + ftJSON長(zhǎng))能整除8，(28 + ftTable長(zhǎng) + btJSON長(zhǎng))能整除8.

數(shù)據(jù)體的起始、末尾對(duì)齊

二進(jìn)制數(shù)據(jù)體，無(wú)論是要素表、批量表，首個(gè)字節(jié)相對(duì)于b3dm文件的字節(jié)偏移量，必須是8的倍數(shù)，結(jié)束字節(jié)的字節(jié)偏移量，也必須是8的倍數(shù)。

如果不滿足，可以填充任意數(shù)據(jù)字節(jié)滿足此要求。

特別的，二進(jìn)制數(shù)據(jù)體中，每一個(gè)屬性值的第一個(gè)數(shù)值的第一個(gè)字節(jié)的偏移量，相對(duì)于整個(gè)b3dm文件，必須是其 componentType 的倍數(shù)，如果不滿足，則必須用空白字節(jié)填滿。

例如，上述 height 屬性所在的批量表二進(jìn)制數(shù)據(jù)體，理所當(dāng)然位于批量表JSON之后，而批量表的JSON又是8byte對(duì)齊的，假設(shè)批量表的數(shù)據(jù)體起始字節(jié)是800，那么 height 的第一個(gè)值起始字節(jié)就是 800，由于 height 屬性的 componentType 是 FLOAT，即 4字節(jié)，800 ÷ 4 能整除，所以沒有問題。

但是，假如 換一個(gè)屬性，其 componentType 是 BYTE，即 1字節(jié)，那么假設(shè)第二個(gè)屬性的 componentType 是 DOUBLE，即 8字節(jié)，就會(huì)出現(xiàn) 第二個(gè)屬性的第一個(gè)值起始偏移量是810，810 ÷ 8 并不能整除，必須補(bǔ)齊 6個(gè)空白字節(jié)，以滿足第二個(gè)屬性第一個(gè)值的起始偏移量是 810+6 = 816字節(jié)。

編碼端序

要素表、批量表的二進(jìn)制數(shù)據(jù)，無(wú)論是JSON還是數(shù)據(jù)體，均使用小端序編碼（LittleEndian）。

⑥ 擴(kuò)展數(shù)據(jù)（extensions）與額外補(bǔ)充信息（extras）

其實(shí)，無(wú)論是要素表，還是批量表，都允許在JSON中存在擴(kuò)展數(shù)據(jù)，以擴(kuò)充當(dāng)前瓦片模型的功能，而并不是單一的一個(gè)一個(gè)模型順次存儲(chǔ)在瓦片文件、glb中。

有關(guān)擴(kuò)展數(shù)據(jù)，在以后會(huì)專門出一篇博客介紹。