区块链技术博客
www.b2bchain.cn

3dTiles 数据规范详解[6] 优缺点以及与I3S比较(完)求职学习资料

本文介绍了3dTiles 数据规范详解[6] 优缺点以及与I3S比较(完)求职学习资料,有助于帮助完成毕业设计以及求职,是一篇很好的资料。

对技术面试,学习经验等有一些体会,在此分享。

  • 1. 相同点
  • 2. 不同点
    • 开闭性
    • 可扩展性
    • 资源解耦
    • 物理存储
    • 版本演进
    • 非空间属性数据
    • 内容区分
    • 结构描述
    • 坐标系统


此处介绍的,是 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,统一集中在入口文件。

坐标系统

  • 1. 相同点
  • 2. 不同点
    • 开闭性
    • 可扩展性
    • 资源解耦
    • 物理存储
    • 版本演进
    • 非空间属性数据
    • 内容区分
    • 结构描述
    • 坐标系统


此处介绍的,是 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,统一集中在入口文件。

坐标系统

  • 1. 相同点
  • 2. 不同点
    • 开闭性
    • 可扩展性
    • 资源解耦
    • 物理存储
    • 版本演进
    • 非空间属性数据
    • 内容区分
    • 结构描述
    • 坐标系统


此处介绍的,是 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,统一集中在入口文件。

坐标系统

部分转自互联网,侵权删除联系

赞(0) 打赏
部分文章转自网络,侵权联系删除b2bchain区块链学习技术社区 » 3dTiles 数据规范详解[6] 优缺点以及与I3S比较(完)求职学习资料
分享到: 更多 (0)

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

b2b链

联系我们联系我们