3DTiles 1.0 数据规范详解[6] 优缺点以及与I3S比较（完）
此处介绍的，是 3DTiles 1.0（不含 next），以及 i3s 1.7
1. 相同点
均将三维模型通过转换的手段细碎化，使得局部加载压力降低，渲染性能有了提高的可能性。
均使用树结构这种空间索引类型进行原始模型空间上的分割，允许使用常见的树结构。
二者在树的末梢，又叫叶子节点，也即真正承载三维数据的文件中，均使用了面向 GPU 友好的格式。
均为开源三维数据格式标准。
均使用 json + 二进制 的组合方式，对细碎化后的数据文件进行组装。
2. 不同点
开闭性
i3s 虽然格式开放，但是加载过程是封闭的（ArcGIS JsAPI不开源）
可扩展性
i3s 存在设计冗余，json 描述文件的字段非常丰富，但没有留下扩展余地；3dtiles 在 json 描述文件的设计上较为简单，使用扩展项来扩充新功能
资源解耦
i3s 在叶子节点（称作 Node）的数据文件设计中做到了几何、非几何、纹理的解耦合，可分别优化；3dtiles 在叶子节点（称作 Tile）的数据文件设计中使用了开源三维数据标准 glTF 2.0；
物理存储
i3s 支持 slpk 这种 zip 格式的单文件打包，也支持 RESTful 访问（官方在 ArcGIS DataStore 中使用了 CouchDB）；3dtiles 目前最广泛的实现仍旧是离散文件的静态伺服
版本演进
i3s 社区版本与 OGC 版本不同步，目前社区版已推进到 1.8，而 OGC 版本是 1.1；3dtiles 则一致
非空间属性数据
3dtiles 对瓦片中三维对象的属性数据设计一般，不推荐将大量属性写入瓦片文件中；i3s 在设计上就支持 RESTful，可承载大量属性数据（非几何）
内容区分
i3s 整份数据集的名称是“场景图层（scenelayer）”，而 3dtiles 则是“瓦片集（tileset）”，二者在数据类型区分层级不同，i3s 的类型界定层级是整个场景图层，而 3dtiles 则是具体到某一个瓦片。
结构描述
虽然都使用 JSON 描述数据集，但是存储的位置却不尽一样。i3s 在整个图层有一份独立的 JSON，在每一个 node 还单独分离了各自的 JSON 描述文件；3dtiles 则不管瓦片数据集还是瓦片的描述 JSON，统一集中在入口文件。
坐标系统
3dtiles 仅支持唯一的三维笛卡尔坐标系，其参考椭球为 WGS84，其坐标系编码为 EPSG:4979；i3s 可以是任意的坐标系，但是调度方式受限于 ArcGIS JsAPI，不知道其原理。
3. 优点
3DTiles 1.0
在 b3dm 和 i3dm 瓦片中充分继承了 glTF 的优点，并且自己也可以通过扩展的方式来增补新的功能；
内容组织非常灵活，性能上限取决于数据生产工具编写人员的能力。
坐标系组织灵活，允许开发者使用转换矩阵统一转换至 EPSG:4979 坐标系下
i3s
每一个资源均有完备的 json 定义，充分考虑到了各种情况；
在 1.7 版本中，空间索引在物理文件上使用了 nodePage 来存储，提高索引速度；
叶子节点（也即 node）内容的组织上，充分解耦合了几何、非几何属性数据、纹理、要素逻辑构成等，以便分别优化；
规范原生支持 RESTful，配合 CouchDB 存储有利于语义化寻找特定资源；
有专门的 BIM 类型场景图层，ArcGIS JsAPI 应该是针对这种局部且细碎的模型有专门优化；
支持多种坐标系定义；
资源文件有 gzip 压缩，几何资源文件还可以进一步使用 draco 压缩编码并 gzip 再次压缩减小体积。
在 1.7 版本，因为增加了 nodePage 机制，索引性能有明显提升。
4. 缺点
3DTiles 1.0
JSON 中元数据较少；
瓦片文件嵌合了几何、属性、纹理等所有信息，对带宽压力大的服务器/客户端来说，请求稍大的瓦片比较费力；
JSON 入口文件过于灵活，若将主入口文件设计得过大而不做 external tileset 的拆分，受制于 Cesium.js 的读取机制，会白白浪费索引性能。
i3s
没有留有可供扩展的定义；复杂层级的模型组织不支持。
3DTiles 系列断断续续写了一年，就写到这里，1.0 标准包括瓦片数据集各种对象的定义、瓦片文件的格式、两个扩展项已全部解读完毕，或有疏漏，欢迎交流。
即将开启第二阶段：3D Tiles Next
