3dTiles 資料規範詳解[4.2] i3dm瓦片二進位制資料檔案結構

i3dm，即Instanced 3D Model，例項三維模型的意思。

諸如樹木、路燈、路邊的垃圾桶、長椅等具有明顯重複特徵的資料。這類資料用得較少（笑，現在都喜歡搞BIM、傾斜攝影、精模、白模等）

我的git地址：github.com/onsummer
轉載請規範化轉載。出處：@秋意正寒https://www.cnblogs.com/onsummer/p/13252897.html
目錄：https://www.cnblogs.com/onsummer/p/12799366.html

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

與 b3dm 一致，檔案頭多了個屬性。

1. 檔案頭：32byte

i3dm的檔案頭有8個屬性，前7個與b3dm是一樣的。

其中，前7個和b3dm意義一樣，不做解釋。

第8個，gltfFormat只有兩個值：0和1.

0，則位於 i3dm 瓦片檔案最後的 gltf 內容是一個 uri，指向gltf的資料內容（可能是Base64 DataURL，也可能是其他地方的地址，筆者沒見過...）

1，則位於 i3dm 瓦片檔案最後的 gltf 內容是 二進位制的 glb，大多數情況見的是這個。

預設情況，gltf 是 y 軸朝上，3dTiles 是z軸朝上，需要座標轉換。

2. 要素表

在上篇，有介紹到要素表存在全域性屬性和要素屬性。在 i3dm 中，這對概念就能得到很好的解釋。

① 要素表的全域性屬性

第一第二個能與 b3dm 中的BATCH_LENGTH和RTC_CENTER類比來理解，就不解釋了。

最後一個屬性指示當前 i3dm 瓦片的座標軸朝向。

下列要著重介紹這個所謂的QUANTIZED_VOLUME，即量化空間範圍體。

量化空間範圍體

這個詞“量化空間範圍體”是我自己意譯的。

每個瓦片，都有它自己的空間範圍，為了節約資料佔用，可以使用相對座標來記錄每個 instance 的位置，也即記錄全域性屬性中的RTC_CENTER屬性。

但是，即便用了相對座標，instance 的座標值仍然是FLOAT型別，佔 4位元組。

假設，存在一個矩形空間，它的左下角點的座標是(x, y, z)，將矩形空間按216216等分其 x、y、z 三個方向，定義矩形空間的三條邊長對應瓦片本身的座標空間的縮放比例為(ScaleX, ScaleY, ScaleZ)，如下圖所示：

這樣，被細分出來的每一個 “小矩形”，都有它自己在這個矩形空間的量化座標，因為 x、y、z 三個方向被分割成了216216塊，我們可以使用uint16型別的數值來記錄座標，這樣每個數字只佔了 16bit，也即 2byte，比FLOAT的4byte 小了一倍，對於頂點資料的壓縮十分具有價值。

那麼，如何將(16464, 2172, 63312)這個量化的座標映射回瓦片原本的座標呢？參考公式：

Position→=Scale∗PositionQuantized→65535+Offset→Position→=Scale∗PositionQuantized→65535+Offset→

即量化座標PositionQuantized各個座標分量乘上縮放因子（Scale / 65535），然後加偏移座標即可。

三個方向的縮放因子QUANTIZED_VOLUME_SCALE:float[3]和 偏移量QUANTIZED_VOLUME_OFFSET:float[3]作為全域性屬性寫在要素表JSON中。

如果這兩個全域性屬性未定義，則 逐要素屬性中的POSITION_QUANTIZED這個量化座標也不會存在，即使用原有的 float 型別座標記法。

需要注意的是，量化座標和普通座標只能二選一，如果都不存在，那麼這個 i3dm 瓦片就不會被渲染。

看到這，是否能理解“要素表的全域性屬性是對於整個瓦片檔案而言”這句話了呢？

② 要素表的(逐)要素屬性

當 i3dm 瓦片中逐個 instance 的POSITION被定義時，量化座標POSITION_QUANTIZED就不應存在，反之亦然。

接下來四個方向向量屬性（法線）NORMAL_UP、NORMAL_RIGHT和NORMAL_UP_OCT32P、NORMAL_RIGHT_OCT32P也是一對反依賴的逐要素屬性。

SCALE屬性定義了當前要素（instance或例項）對使用的 gltf 模型的縮放比例。

SCALE_NON_UNIFORM屬性與SCALE屬性差不多，只不過是在三個方向上分別不同的縮放比例。

BATCH_ID，是當前要素（instance或例項）的 id 號，將 要素 與 批量表中的屬性 二者聯絡起來。

個人覺得，應該叫INSTANCE_ID更合適一些？

預設方向

如果不給定要素屬性中與方向有關的向量時，每個例項的朝向有一個預設值：在WGS84橢球上，上方向指向正北，右方向指向正東。

③ 要素表的JSON

上述所有屬性全部會記錄在要素表的 JSON 中，對於 全域性屬性，其值記錄在 JSON 中，對於其要素屬性，因為要素（即instance）很多的時候寫在JSON中體積會變大，所以使用 JSON引用要素表二進位制資料體 的形式。

下列是一個要素表的JSON：

{
    INSTANCES_LENGTH : 4, // 有4個例項
    POSITION : {
        byteOffset : 0 // POSITION的值從ftBinary的第0位元組起開始計算
    }
}

讀者不妨回顧上一篇，b3dm的要素表JSON，並未出現有對要素表體引用的屬性，在這裡出現了：POSITION，它從要素表體的第 0 個位元組開始記錄資料。

而POSITION這個逐要素（例項、instance）屬性的定義，早已在上文提及，即三個FLOAT型別數字為一組，一共INSTANCES_LENGTH組的資料，記錄在要素表體。這是 instance 座標資料，寫在 JSON 中雖然沒問題，但是會造成空間浪費，以二進位制形式記錄會比較划算。

④ 要素表體

要素表JSON中引用的二進位制資料均順次記錄在此。

3. 批量表

批量表與 b3dm 的一致，均為 JSON 記錄屬性元資料，批量表體記錄屬性具體資料。此處不再舉例。

4. 要素舉例說明

此部分參考官方文件。

① 僅有POSITION的 i3dm 瓦片

var featureTableJSON = {
    INSTANCES_LENGTH : 4, // 有4個例項
    POSITION : {
        byteOffset : 0 // POSITION的值從ftBinary的第0位元組起開始計算
    }
};

var featureTableBinary = new Buffer(new Float32Array([
    0.0, 0.0, 0.0,
    1.0, 0.0, 0.0,
    0.0, 0.0, 1.0,
    1.0, 0.0, 1.0
]).buffer);

使用 JavaScript 語言記錄了 要素表JSON，以及要素表二進位制資料（以ES6 TypedArray 形式）。

② 使用量化位置與八進位制方向向量

var featureTableJSON = {
    INSTANCES_LENGTH : 4, // 有4個例項
    QUANTIZED_VOLUME_OFFSET : [-250.0, 0.0, -250.0],
    QUANTIZED_VOLUME_SCALE : [500.0, 0.0, 500.0],
    POSITION_QUANTIZED : {
        byteOffset : 0
    },
    NORMAL_UP_OCT32P : {
        byteOffset : 24
    },
    NORMAL_RIGHT_OCT32P : {
        byteOffset : 40
    }
};

var positionQuantizedBinary = new Buffer(new Uint16Array([
    0, 0, 0,
    65535, 0, 0,
    0, 0, 65535,
    65535, 0, 65535
]).buffer);

var normalUpOct32PBinary = new Buffer(new Uint16Array([
    32768, 65535,
    32768, 65535,
    32768, 65535,
    32768, 65535
]).buffer);

var normalRightOct32PBinary = new Buffer(new Uint16Array([
    65535, 32768,
    65535, 32768,
    65535, 32768,
    65535, 32768
]).buffer);

var featureTableBinary = Buffer.concat([positionQuantizedBinary, normalUpOct32PBinary, normalRightOct32PBinary]);

規定了全域性屬性QUANTIZED_VOLUME_OFFSET和QUANTIZED_VOLUME_SCALE，規定了量化座標POSITION_QUANTIZED、八進位制上方向和右方向向量NORMAL_UP_OCT32P、NORMAL_RIGHT_OCT32P在要素表體中的起始偏移值。

於是，使用三個TypedArray構造的Buffer物件，再拼接在一起，即要素表體featureTableBinary。

5. 位元組對齊與編碼端序

與b3dm裡寫的一致，可以回看：https://www.cnblogs.com/onsummer/p/13252896.html

6. 擴充套件（extensions）和額外資訊（extras）

同樣，這部分內容與b3dm篇章內介紹的一致，會在後續文章內介紹。