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

posted @ 2021-11-16 03:33  岭南灯火  阅读(1965)  评论(2编辑  收藏  举报