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

3dTiles 数据规范详解[5] 扩展求职学习资料

本文介绍了3dTiles 数据规范详解[5] 扩展求职学习资料,有助于帮助完成毕业设计以及求职,是一篇很好的资料。

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

  • 1 可扩展的格式
  • 2 官方当前的两种扩展
  • 3 以 “b3dm 类型的瓦片属性信息” 引入
    • 3.1 区分每一个顶点是谁
    • 3.2 不同模型要素有不同的属性怎么办
      • 3.2.1 属性:3DTILES_batch_table_hierarchy.classes
      • 3.2.2 属性:3DTILES_batch_table_hierarchy.instancesLength
      • 3.2.3 属性:3DTILES_batch_table_hierarchy.classIds
    • 3.3 虚要素:由多个实际的要素构成的属性


1 可扩展的格式

继承自 glTF 的可扩展性,3dTiles 在定义上也留下了可扩展的余地。包括但不局限于:优化几何数据的存储,扩展属性数据等。

2 官方当前的两种扩展

  • 层级属性
  • 点云的 draco 压缩

下面,将简单介绍这两个扩展。

3 以 “b3dm 类型的瓦片属性信息” 引入

b3dm 瓦片的属性信息写在批次表(batchtable) 中。b3dm 中每个独立的模型,叫做 batch,(等价于要素表中的要素)这个概念引申自图形编程,意思是“一次性向图形处理器(GPU)发送的数据”,即批次。一个 b3dm 瓦片有多少个 batch(有多少个要素),是由要素表的 JSON 表头中的 BATCH_LENGTH 属性记录的。

而批次表(batchtable)的每个属性数据长度,都与这个 BATCH_LENGTH 相等。

以上是 03 篇与 04 篇的回顾。

批次表记录属性数据是有缺陷的。

  • 第一,对字符串、布尔值等非数字型数据的支持较差,只能记录在批次表JSON头,二进制体无法记录非数字型数据;
  • 第二,也就是此扩展重点解决的问题,当 batch 之间存在逻辑分层、从属关系时,如何记录它们的层级属性数据的问题

3.1 区分每一个顶点是谁

此小节需要对 glTF 格式规范比较熟悉。知道“顶点属性”的概念,知道 WebGL 的帧缓存技术。

b3dm 瓦片内置的 glTF 模型中,每个 primitive 的 attribute,也即顶点属性中会加上一个新的属性,与 POSITIONUV0 等并列,叫做 _BATCHID

这样,通过 _BATCHID,使用 WebGL 中的帧缓存技术,在 FBO 上绘制 _BATCHID 的颜色附件,即可完成快速查询。

要素表通过 BATCH_ID 访问 批次表里的属性数据,几何数据(glTF 中的 vertex)通过 _BATCHID 绑定要素。

3dTiles 数据规范详解[5] 扩展

3.2 不同模型要素有不同的属性怎么办

假设有这么一块空间范围,归属在 0.b3dm 瓦片内,瓦片的 glTF 模型拥有两个 BATCH,即两个要素,为了方便观察,不妨具象化:

  • 空间范围 = 一个停车场

  • BATCH1 = 充电桩

  • BATCH2 = 电动汽车

如下图所示:

3dTiles 数据规范详解[5] 扩展

现在,我用一个简单的 JSON 来描述这两个要素的属性数据:

{   "Charger": {     "Price": 0.5,     "DeviceId": "abcdefg123"   },   "Car": {     "Brand": "Tesla",     "Owner": "Jacky"   } }

这样的数据不符合原生批次表的存储逻辑,即每个 batch 的属性名称应完全一致。

显然,充电桩的 Price(就是单价)、DeviceId 和车子的 Brand(品牌)、Owner 并不是一样的。

如果用这个扩展来表示,在批次表的 JSON 中将会是:

{   "extensions": {     "3DTILES_batch_table_hierarchy": {       // ...     }   } }

映入眼帘的是 extensions,它是一个 JSON,下面有一个 3DTILES_batch_table_hierarchy 的属性,其值也是一个 JSON:

{     "classes": [     { /* ... */ },     { /* ... */ }   ],   "instancesLength": 2,   "classIds": [0, 1] }

其中,classes 是描述每个分类的数组,这里有充电桩类、电动汽车类,详细展开电动汽车类:

[   { /* 电动汽车类,略 */ },   {     "name": "Car",     "length": 1,     "instances": {       "Brand": ["Tesla"],       "Owner": ["Jacky"]     }   } ]

每个 class 就记录了该类别下,所有模型要素的属性值(此处是 Brand 和 Owner),以及有多少个模型要素(length 值,此处是 length = 1 辆车)。

扩展:如果这个 b3dm 又多增加了一个电动汽车,那么这个 JSON 就应该变成下面的样子了

{   "name": "Car",   "length": 2, // <- 变成 2   "instances": {     "Brand": ["Tesla", "Benz"], // <- 加一个值     "Owner": ["Jacky", "Granger"] // <- 加一个值   } }

图示:

3dTiles 数据规范详解[5] 扩展

3.2.1 属性:3DTILES_batch_table_hierarchy.classes

classes 代表此 b3dm 内有多少个模型种类,这里有充电桩、汽车两类。

3.2.2 属性:3DTILES_batch_table_hierarchy.instancesLength

instancesLength 代表所有模型种类的数量和,这里每个种类都只有 1 个 batch(要素),加起来就是 2

instancesLength 和 b3dm 中要素表的 BATCH_LENGTH 并不是相等的。

当且仅当模型之间不构成逻辑层级时,这两个数字才相等。显然,此例中的 “充电桩”和“电动汽车”不构成逻辑分层、从属关系。

有关这一条,在 3.3 小节中的层级关系会详细展开。

3.2.3 属性:3DTILES_batch_table_hierarchy.classIds

classIds 是一个 classId 数组,每个数组元素代表每个 batch 的 分类 id,若两个 batch 是 classes 数组中的某个 class,那么它俩的 classId 是一样的。

这个数组去重后的 id 数量,就等于 classes 数组的长度。

例如,classIds: [0,0,0, 1,1],有 0、1 两个 classId,那么 classes 数组的长度就应该是 2.

3.3 虚要素:由多个实际的要素构成的属性

现在,换一个场景,假设有一块空间,上面有墙模型要素、窗模型要素、门模型要素、屋顶模型、楼板模型要素共 5 类,每个分类有 1、2、1、1、1 个模型要素,即

  • 1个墙模型要素
  • 2个窗模型要素
  • 1个门模型要素
  • 1个屋顶模型要素
  • 1个楼板模型要素

通过 3.2,很快得到扩展 JSON:

  • 1 可扩展的格式
  • 2 官方当前的两种扩展
  • 3 以 “b3dm 类型的瓦片属性信息” 引入
    • 3.1 区分每一个顶点是谁
    • 3.2 不同模型要素有不同的属性怎么办
      • 3.2.1 属性:3DTILES_batch_table_hierarchy.classes
      • 3.2.2 属性:3DTILES_batch_table_hierarchy.instancesLength
      • 3.2.3 属性:3DTILES_batch_table_hierarchy.classIds
    • 3.3 虚要素:由多个实际的要素构成的属性


1 可扩展的格式

继承自 glTF 的可扩展性,3dTiles 在定义上也留下了可扩展的余地。包括但不局限于:优化几何数据的存储,扩展属性数据等。

2 官方当前的两种扩展

  • 层级属性
  • 点云的 draco 压缩

下面,将简单介绍这两个扩展。

3 以 “b3dm 类型的瓦片属性信息” 引入

b3dm 瓦片的属性信息写在批次表(batchtable) 中。b3dm 中每个独立的模型,叫做 batch,(等价于要素表中的要素)这个概念引申自图形编程,意思是“一次性向图形处理器(GPU)发送的数据”,即批次。一个 b3dm 瓦片有多少个 batch(有多少个要素),是由要素表的 JSON 表头中的 BATCH_LENGTH 属性记录的。

而批次表(batchtable)的每个属性数据长度,都与这个 BATCH_LENGTH 相等。

以上是 03 篇与 04 篇的回顾。

批次表记录属性数据是有缺陷的。

  • 第一,对字符串、布尔值等非数字型数据的支持较差,只能记录在批次表JSON头,二进制体无法记录非数字型数据;
  • 第二,也就是此扩展重点解决的问题,当 batch 之间存在逻辑分层、从属关系时,如何记录它们的层级属性数据的问题

3.1 区分每一个顶点是谁

此小节需要对 glTF 格式规范比较熟悉。知道“顶点属性”的概念,知道 WebGL 的帧缓存技术。

b3dm 瓦片内置的 glTF 模型中,每个 primitive 的 attribute,也即顶点属性中会加上一个新的属性,与 POSITIONUV0 等并列,叫做 _BATCHID

这样,通过 _BATCHID,使用 WebGL 中的帧缓存技术,在 FBO 上绘制 _BATCHID 的颜色附件,即可完成快速查询。

要素表通过 BATCH_ID 访问 批次表里的属性数据,几何数据(glTF 中的 vertex)通过 _BATCHID 绑定要素。

3dTiles 数据规范详解[5] 扩展

3.2 不同模型要素有不同的属性怎么办

假设有这么一块空间范围,归属在 0.b3dm 瓦片内,瓦片的 glTF 模型拥有两个 BATCH,即两个要素,为了方便观察,不妨具象化:

  • 空间范围 = 一个停车场

  • BATCH1 = 充电桩

  • BATCH2 = 电动汽车

如下图所示:

3dTiles 数据规范详解[5] 扩展

现在,我用一个简单的 JSON 来描述这两个要素的属性数据:

{   "Charger": {     "Price": 0.5,     "DeviceId": "abcdefg123"   },   "Car": {     "Brand": "Tesla",     "Owner": "Jacky"   } }

这样的数据不符合原生批次表的存储逻辑,即每个 batch 的属性名称应完全一致。

显然,充电桩的 Price(就是单价)、DeviceId 和车子的 Brand(品牌)、Owner 并不是一样的。

如果用这个扩展来表示,在批次表的 JSON 中将会是:

{   "extensions": {     "3DTILES_batch_table_hierarchy": {       // ...     }   } }

映入眼帘的是 extensions,它是一个 JSON,下面有一个 3DTILES_batch_table_hierarchy 的属性,其值也是一个 JSON:

{     "classes": [     { /* ... */ },     { /* ... */ }   ],   "instancesLength": 2,   "classIds": [0, 1] }

其中,classes 是描述每个分类的数组,这里有充电桩类、电动汽车类,详细展开电动汽车类:

[   { /* 电动汽车类,略 */ },   {     "name": "Car",     "length": 1,     "instances": {       "Brand": ["Tesla"],       "Owner": ["Jacky"]     }   } ]

每个 class 就记录了该类别下,所有模型要素的属性值(此处是 Brand 和 Owner),以及有多少个模型要素(length 值,此处是 length = 1 辆车)。

扩展:如果这个 b3dm 又多增加了一个电动汽车,那么这个 JSON 就应该变成下面的样子了

{   "name": "Car",   "length": 2, // <- 变成 2   "instances": {     "Brand": ["Tesla", "Benz"], // <- 加一个值     "Owner": ["Jacky", "Granger"] // <- 加一个值   } }

图示:

3dTiles 数据规范详解[5] 扩展

3.2.1 属性:3DTILES_batch_table_hierarchy.classes

classes 代表此 b3dm 内有多少个模型种类,这里有充电桩、汽车两类。

3.2.2 属性:3DTILES_batch_table_hierarchy.instancesLength

instancesLength 代表所有模型种类的数量和,这里每个种类都只有 1 个 batch(要素),加起来就是 2

instancesLength 和 b3dm 中要素表的 BATCH_LENGTH 并不是相等的。

当且仅当模型之间不构成逻辑层级时,这两个数字才相等。显然,此例中的 “充电桩”和“电动汽车”不构成逻辑分层、从属关系。

有关这一条,在 3.3 小节中的层级关系会详细展开。

3.2.3 属性:3DTILES_batch_table_hierarchy.classIds

classIds 是一个 classId 数组,每个数组元素代表每个 batch 的 分类 id,若两个 batch 是 classes 数组中的某个 class,那么它俩的 classId 是一样的。

这个数组去重后的 id 数量,就等于 classes 数组的长度。

例如,classIds: [0,0,0, 1,1],有 0、1 两个 classId,那么 classes 数组的长度就应该是 2.

3.3 虚要素:由多个实际的要素构成的属性

现在,换一个场景,假设有一块空间,上面有墙模型要素、窗模型要素、门模型要素、屋顶模型、楼板模型要素共 5 类,每个分类有 1、2、1、1、1 个模型要素,即

  • 1个墙模型要素
  • 2个窗模型要素
  • 1个门模型要素
  • 1个屋顶模型要素
  • 1个楼板模型要素

通过 3.2,很快得到扩展 JSON:

  • 1 可扩展的格式
  • 2 官方当前的两种扩展
  • 3 以 “b3dm 类型的瓦片属性信息” 引入
    • 3.1 区分每一个顶点是谁
    • 3.2 不同模型要素有不同的属性怎么办
      • 3.2.1 属性:3DTILES_batch_table_hierarchy.classes
      • 3.2.2 属性:3DTILES_batch_table_hierarchy.instancesLength
      • 3.2.3 属性:3DTILES_batch_table_hierarchy.classIds
    • 3.3 虚要素:由多个实际的要素构成的属性


1 可扩展的格式

继承自 glTF 的可扩展性,3dTiles 在定义上也留下了可扩展的余地。包括但不局限于:优化几何数据的存储,扩展属性数据等。

2 官方当前的两种扩展

  • 层级属性
  • 点云的 draco 压缩

下面,将简单介绍这两个扩展。

3 以 “b3dm 类型的瓦片属性信息” 引入

b3dm 瓦片的属性信息写在批次表(batchtable) 中。b3dm 中每个独立的模型,叫做 batch,(等价于要素表中的要素)这个概念引申自图形编程,意思是“一次性向图形处理器(GPU)发送的数据”,即批次。一个 b3dm 瓦片有多少个 batch(有多少个要素),是由要素表的 JSON 表头中的 BATCH_LENGTH 属性记录的。

而批次表(batchtable)的每个属性数据长度,都与这个 BATCH_LENGTH 相等。

以上是 03 篇与 04 篇的回顾。

批次表记录属性数据是有缺陷的。

  • 第一,对字符串、布尔值等非数字型数据的支持较差,只能记录在批次表JSON头,二进制体无法记录非数字型数据;
  • 第二,也就是此扩展重点解决的问题,当 batch 之间存在逻辑分层、从属关系时,如何记录它们的层级属性数据的问题

3.1 区分每一个顶点是谁

此小节需要对 glTF 格式规范比较熟悉。知道“顶点属性”的概念,知道 WebGL 的帧缓存技术。

b3dm 瓦片内置的 glTF 模型中,每个 primitive 的 attribute,也即顶点属性中会加上一个新的属性,与 POSITIONUV0 等并列,叫做 _BATCHID

这样,通过 _BATCHID,使用 WebGL 中的帧缓存技术,在 FBO 上绘制 _BATCHID 的颜色附件,即可完成快速查询。

要素表通过 BATCH_ID 访问 批次表里的属性数据,几何数据(glTF 中的 vertex)通过 _BATCHID 绑定要素。

3dTiles 数据规范详解[5] 扩展

3.2 不同模型要素有不同的属性怎么办

假设有这么一块空间范围,归属在 0.b3dm 瓦片内,瓦片的 glTF 模型拥有两个 BATCH,即两个要素,为了方便观察,不妨具象化:

  • 空间范围 = 一个停车场

  • BATCH1 = 充电桩

  • BATCH2 = 电动汽车

如下图所示:

3dTiles 数据规范详解[5] 扩展

现在,我用一个简单的 JSON 来描述这两个要素的属性数据:

{   "Charger": {     "Price": 0.5,     "DeviceId": "abcdefg123"   },   "Car": {     "Brand": "Tesla",     "Owner": "Jacky"   } }

这样的数据不符合原生批次表的存储逻辑,即每个 batch 的属性名称应完全一致。

显然,充电桩的 Price(就是单价)、DeviceId 和车子的 Brand(品牌)、Owner 并不是一样的。

如果用这个扩展来表示,在批次表的 JSON 中将会是:

{   "extensions": {     "3DTILES_batch_table_hierarchy": {       // ...     }   } }

映入眼帘的是 extensions,它是一个 JSON,下面有一个 3DTILES_batch_table_hierarchy 的属性,其值也是一个 JSON:

{     "classes": [     { /* ... */ },     { /* ... */ }   ],   "instancesLength": 2,   "classIds": [0, 1] }

其中,classes 是描述每个分类的数组,这里有充电桩类、电动汽车类,详细展开电动汽车类:

[   { /* 电动汽车类,略 */ },   {     "name": "Car",     "length": 1,     "instances": {       "Brand": ["Tesla"],       "Owner": ["Jacky"]     }   } ]

每个 class 就记录了该类别下,所有模型要素的属性值(此处是 Brand 和 Owner),以及有多少个模型要素(length 值,此处是 length = 1 辆车)。

扩展:如果这个 b3dm 又多增加了一个电动汽车,那么这个 JSON 就应该变成下面的样子了

{   "name": "Car",   "length": 2, // <- 变成 2   "instances": {     "Brand": ["Tesla", "Benz"], // <- 加一个值     "Owner": ["Jacky", "Granger"] // <- 加一个值   } }

图示:

3dTiles 数据规范详解[5] 扩展

3.2.1 属性:3DTILES_batch_table_hierarchy.classes

classes 代表此 b3dm 内有多少个模型种类,这里有充电桩、汽车两类。

3.2.2 属性:3DTILES_batch_table_hierarchy.instancesLength

instancesLength 代表所有模型种类的数量和,这里每个种类都只有 1 个 batch(要素),加起来就是 2

instancesLength 和 b3dm 中要素表的 BATCH_LENGTH 并不是相等的。

当且仅当模型之间不构成逻辑层级时,这两个数字才相等。显然,此例中的 “充电桩”和“电动汽车”不构成逻辑分层、从属关系。

有关这一条,在 3.3 小节中的层级关系会详细展开。

3.2.3 属性:3DTILES_batch_table_hierarchy.classIds

classIds 是一个 classId 数组,每个数组元素代表每个 batch 的 分类 id,若两个 batch 是 classes 数组中的某个 class,那么它俩的 classId 是一样的。

这个数组去重后的 id 数量,就等于 classes 数组的长度。

例如,classIds: [0,0,0, 1,1],有 0、1 两个 classId,那么 classes 数组的长度就应该是 2.

3.3 虚要素:由多个实际的要素构成的属性

现在,换一个场景,假设有一块空间,上面有墙模型要素、窗模型要素、门模型要素、屋顶模型、楼板模型要素共 5 类,每个分类有 1、2、1、1、1 个模型要素,即

  • 1个墙模型要素
  • 2个窗模型要素
  • 1个门模型要素
  • 1个屋顶模型要素
  • 1个楼板模型要素

通过 3.2,很快得到扩展 JSON:

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

赞(0) 打赏
部分文章转自网络,侵权联系删除b2bchain区块链学习技术社区 » 3dTiles 数据规范详解[5] 扩展求职学习资料
分享到: 更多 (0)

评论 抢沙发

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

b2b链

联系我们联系我们