i3dm，即

Instanced 3D Model

诸如树木、路灯、路边的垃圾桶、长椅等具有明显 重复 特征的数据。这类数据用得较少（笑，现在都喜欢搞BIM、倾斜摄影、精模、白模等）

瓦片文件二进制布局（文件结构）

与 b3dm 一致，文件头多了个属性。

1. 文件头：32byte

i3dm的文件头有8个属性，前7个与b3dm是一样的。

magic

"i3dm"

version

byteLength

featureTableJSONByteLength

featureTableBinaryByteLength

batchTableJSONByteLength

batchTableBinaryByteLength

gltfFormat

其中，前7个和b3dm意义一样，不做解释。

第8个，

gltfFormat

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

假设，存在一个矩形空间，它的左下角点的坐标是

(x, y, z)

(ScaleX, ScaleY, ScaleZ)

这样，被细分出来的每一个 “小矩形”，都有它自己在这个矩形空间的量化坐标，因为 x、y、z 三个方向被分割成了 \(2^{16}\) 块，我们可以使用

uint16

FLOAT

那么，如何将

(16464, 2172, 63312)

\(\vec{Position} = Scale * \displaystyle\frac{\vec{PositionQuantized}}{65535} + \vec{Offset}\)

即量化坐标

PositionQuantized

Scale / 65535

三个方向的缩放因子

QUANTIZED_VOLUME_SCALE:float[3]

QUANTIZED_VOLUME_OFFSET:float[3]

如果这两个全局属性未定义，则 逐要素属性中的

POSITION_QUANTIZED

需要注意的是，量化坐标和普通坐标只能二选一，如果都不存在，那么这个 i3dm 瓦片就不会被渲染。

看到这，是否能理解“要素表的全局属性是对于整个瓦片文件而言”这句话了呢？

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

up

up

当 i3dm 瓦片中逐个 instance 的

POSITION

POSITION_QUANTIZED

接下来四个方向向量属性（法线）

NORMAL_UP

NORMAL_RIGHT

NORMAL_UP_OCT32P

NORMAL_RIGHT_OCT32P

SCALE

SCALE_NON_UNIFORM

SCALE

BATCH_ID

INSTANCE_ID

默认方向

如果不给定要素属性中与方向有关的向量时，每个实例的朝向有一个默认值：在WGS84椭球上，上方向指向正北，右方向指向正东。

③ 要素表的JSON

上述所有属性全部会记录在要素表的 JSON 中，对于 全局属性，其值记录在 JSON 中，对于其要素属性，因为要素（即instance）很多的时候写在JSON中体积会变大，所以使用 JSON引用要素表二进制数据体 的形式。

下列是一个要素表的JSON：

{
INSTANCES_LENGTH : 4, // 有4个实例
POSITION : {
byteOffset : 0 // POSITION的值从ftBinary的第0字节起开始计算
}
}

读者不妨回顾上一篇，b3dm的要素表JSON，并未出现有对要素表体引用的属性，在这里出现了：

POSITION

而

POSITION

FLOAT

INSTANCES_LENGTH

④ 要素表体

要素表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篇章内介绍的一致，会在后续文章内介绍。