GLTF格式解析

前置知识：GLB文件格式解析GLTF文件格式解析 (baidu.com)

glb格式解析 | 码农家园 (codenong.com)

3D性能优化 | 说一说glTF文件压缩 - 知乎 (zhihu.com)

glTF格式详解(目录) - 知乎 (zhihu.com)

1 GLTF文件

{
  "accessors": [
    {
      "bufferView": 0,
      "componentType": 5126,
      "count": 3575,
      "type": "VEC2",
      "max": [
        0.9999003,
        -0.0221377648
      ],
      "min": [
        0.0006585993,
        -0.996773958
      ]
    },
    {
      "bufferView": 1,
      "componentType": 5126,
      "count": 3575,
      "type": "VEC3",
      "max": [
        1.0,
        1.0,
        0.9999782
      ],
      "min": [
        -1.0,
        -1.0,
        -0.9980823
      ]
    },
    {
      "bufferView": 2,
      "componentType": 5126,
      "count": 3575,
      "type": "VEC4",
      "max": [
        1.0,
        0.9999976,
        1.0,
        1.0
      ],
      "min": [
        -0.9991289,
        -0.999907851,
        -1.0,
        1.0
      ]
    },
    {
      "bufferView": 3,
      "componentType": 5126,
      "count": 3575,
      "type": "VEC3",
      "max": [
        0.009921154,
        0.00977163,
        0.0100762453
      ],
      "min": [
        -0.009921154,
        -0.00977163,
        -0.0100762453
      ]
    },
    {
      "bufferView": 4,
      "componentType": 5123,
      "count": 18108,
      "type": "SCALAR",
      "max": [
        3574
      ],
      "min": [
        0
      ]
    }
  ],
  "asset": {
    "generator": "glTF Tools for Unity",
    "version": "2.0"
  },
  "bufferViews": [
    {
      "buffer": 0,
      "byteLength": 28600
    },
    {
      "buffer": 0,
      "byteOffset": 28600,
      "byteLength": 42900
    },
    {
      "buffer": 0,
      "byteOffset": 71500,
      "byteLength": 57200
    },
    {
      "buffer": 0,
      "byteOffset": 128700,
      "byteLength": 42900
    },
    {
      "buffer": 0,
      "byteOffset": 171600,
      "byteLength": 36216
    }
  ],
  "buffers": [
    {
      "uri": "BoomBox.bin",
      "byteLength": 207816
    }
  ],
  "images": [
    {
      "uri": "BoomBox_baseColor.png"
    },
    {
      "uri": "BoomBox_occlusionRoughnessMetallic.png"
    },
    {
      "uri": "BoomBox_normal.png"
    },
    {
      "uri": "BoomBox_emissive.png"
    }
  ],
  "meshes": [
    {
      "primitives": [
        {
          "attributes": {
            "TEXCOORD_0": 0,
            "NORMAL": 1,
            "TANGENT": 2,
            "POSITION": 3
          },
          "indices": 4,
          "material": 0
        }
      ],
      "name": "BoomBox"
    }
  ],
  "materials": [
    {
      "pbrMetallicRoughness": {
        "baseColorTexture": {
          "index": 0
        },
        "metallicRoughnessTexture": {
          "index": 1
        }
      },
      "normalTexture": {
        "index": 2
      },
      "occlusionTexture": {
        "index": 1
      },
      "emissiveFactor": [
        1.0,
        1.0,
        1.0
      ],
      "emissiveTexture": {
        "index": 3
      },
      "name": "BoomBox_Mat"
    }
  ],
  "nodes": [
    {
      "mesh": 0,
      "name": "BoomBox"
    }
  ],
  "scene": 0,
  "scenes": [
    {
      "nodes": [
        0
      ]
    }
  ],
  "textures": [
    {
      "source": 0
    },
    {
      "source": 1
    },
    {
      "source": 2
    },
    {
      "source": 3
    }
  ]
}

bufferViews":有好几个，为什么每个都设置 "buffer": 0, 这个“buffer”指的啥？？？

GLTF格式用于描述3D模型和场景的信息。
在您提供的JSON示例中，
`buffers`，`bufferViews`和`accessors`协同工作以描述3D模型的顶点和其他数据。
 
### Buffers
- **Buffers** 是存储实际的二进制数据的地方。在这个例子中，
`"uri": "BoomBox.bin"` 指明了buffer的位置，
`"byteLength": 207816` 描述了buffer的长度。
 
```json
"buffers": [
    {
      "uri": "BoomBox.bin",
      "byteLength": 207816
    }
]
```
 
### BufferViews
- **BufferViews** 描述了如何从buffer中查看数据。
每个`bufferView`有一个`byteOffset`来描述从buffer的哪个位置开始，
以及`byteLength`来描述view的长度。`"buffer": 0` 指明了该`bufferView`
是从第一个（也是唯一一个）buffer中查看的。
 
```json
"bufferViews": [
    {
      "buffer": 0,
      "byteLength": 28600
    },
    ...
]
```
 
### Accessors
- **Accessors** 则进一步描述了如何从`bufferView`中解读数据。
它会定义component的类型，例如，是否是一个VEC3或者SCALAR，
以及数据的类型，例如，是否是FLOAT。它还会包含一些有关数据的其他信息，例如min和max值。
 
```json
"accessors": [
    {
      "bufferView": 0,
      "componentType": 5126,
      "count": 3575,
      "type": "VEC2",
      ...
    },
    ...
]
```
 
### 为什么每个 BufferView 的 `"buffer": 0` ？
在您的JSON示例中，所有的`bufferViews`都有`"buffer": 0`，
这是因为所有的`bufferViews`都是从同一个buffer中提取的，
也就是上述`buffers`数组中的第一个（并且是唯一的）buffer。
 
如果您的GLTF文件中有多个buffer，那么您将会看到不同的`bufferViews`
关联到不同的buffer。例如，如果有一个`bufferView`从第二个buffer中
提取数据，那么它将会有`"buffer": 1`。

"accessors": [ { "bufferView": 0, "componentType": 5126, "count": 3575, "type": "VEC2", ... }, ... ]

这accessors中的每一个bufferView可以重复吗，比如accessors三个孩子，bufferView分别为0,1,1？？？

  比如这种文件

{"asset":{"generator":"COLLADA2GLTF","version":"2.0"},"scene":0,"scenes":[{"nodes":[0]}],"nodes":[{"children":[1],"matrix":[1.0,0.0,0.0,0.0,0.0,0.0,-1.0,0.0,0.0,1.0,0.0,0.0,0.0,0.0,0.0,1.0]},{"mesh":0}],"meshes":[{
 
"primitives":[{"attributes":{"NORMAL":1,"POSITION":2},"indices":0,"mode":4,"material":0}],"name":"Mesh"}],
 
"accessors":[
 
{"bufferView":0,"byteOffset":0,"componentType":5123,"count":36,"max":[23],"min":[0],"type":"SCALAR"},{"bufferView":1,"byteOffset":0,"componentType":5126,"count":24,"max":[1.0,1.0,1.0],"min":[-1.0,-1.0,-1.0],"type":"VEC3"},{"bufferView":1,"byteOffset":288,"componentType":5126,"count":24,"max":[0.5,0.5,0.5],"min":[-0.5,-0.5,-0.5],"type":"VEC3"}]
 
,"materials":[{"pbrMetallicRoughness":{"baseColorFactor":[0.800000011920929,0.0,0.0,1.0],"metallicFactor":0.0},"name":"Red"}],
 
"bufferViews":[
{"buffer":0,"byteOffset":576,"byteLength":72,"target":34963},
{"buffer":0,"byteOffset":0,"byteLength":576,"byteStride":12,"target":34962}],
"buffers":[{"byteLength":648}]}

是的，`accessors`中的`bufferView`可以重复。每个`accessor`定义了
如何解读存储在`bufferView`中的数据。不同的`accessor`可以使用相同
的`bufferView`，但可能会有不同的`byteOffset`、`componentType`、
`count`或`type`，以便以不同的方式解读相同的数据，或解读该`bufferView`
中的不同部分数据。
 
举个例子，假设我们有两个`accessor`，它们都指向`bufferView` 1，但
一个是解读VEC3类型数据，另一个是解读SCALAR类型数据。那么，这两个
`accessor`将会从相同的`bufferView`中提取不同类型和格式的数据。
 
```json
"accessors": [
    {
      "bufferView": 1,
      "componentType": 5126,
      "count": 1000,
      "type": "VEC3"
    },
    {
      "bufferView": 1,
      "componentType": 5123,
      "count": 2000,
      "type": "SCALAR"
    }
]
```
 
在这个例子中，即便两个`accessor`都引用了`bufferView` 1，但由于
它们有不同的`type`和`componentType`，它们将会以不同的方式解读
`bufferView`中的数据。

2 GLB文件并进行了Draco压缩

glTF   T	  ?  JSON{
  "asset": {
    "version": "2.0",
    "generator": "draco_decoder"
  },
  "scenes": [
    {
      "nodes": [
        0
      ]
    }
  ],
  "scene": 0,
  "nodes": [
    {
      "children": [
        1
      ],
      "matrix": [
        1,
        0,
        0,
        0,
        0,
        0,
        -1,
        0,
        0,
        1,
        0,
        0,
        0,
        0,
        0,
        1
      ]
    },
    {
      "mesh": 0
    }
  ],
  "meshes": [
    {
      "primitives": [
        {
          "attributes": {
            "NORMAL": 2,
            "POSITION": 1
          },
          "indices": 0,
          "mode": 4,
          "material": 0,
          "extensions": {
            "KHR_draco_mesh_compression": {
              "bufferView": 0,
              "attributes": {
                "NORMAL": 0,
                "POSITION": 1
              }
            }
          }
        }
      ]
    }
  ],
  "materials": [
    {
      "pbrMetallicRoughness": {
        "baseColorFactor": [
          0.800000011920929,
          0,
          0,
          1
        ],
        "metallicFactor": 0,
        "roughnessFactor": 1
      },
      "emissiveFactor": [
        0,
        0,
        0
      ],
      "alphaMode": "OPAQUE"
    }
  ],
  "accessors": [
    {
      "componentType": 5121,
      "count": 36,
      "normalized": false,
      "max": [
        23
      ],
      "min": [
        0
      ],
      "type": "SCALAR"
    },
    {
      "componentType": 5126,
      "count": 24,
      "normalized": false,
      "max": [
        0.5,
        0.5,
        0.5
      ],
      "min": [
        -0.5,
        -0.5,
        -0.5
      ],
      "type": "VEC3"
    },
    {
      "componentType": 5126,
      "count": 24,
      "normalized": false,
      "max": [
        1,
        1,
        1
      ],
      "min": [
        -1,
        -1,
        -1
      ],
      "type": "VEC3"
    }
  ],
  "bufferViews": [
    {
      "buffer": 0,
      "byteOffset": 0,
      "byteLength": 152
    }
  ],
  "buffers": [
    {
      "byteLength": 152
    }
  ],
  "extensionsRequired": [
    "KHR_draco_mesh_compression"
  ],
  "extensionsUsed": [
    "KHR_draco_mesh_compression"
  ]
}
 ?   BIN DRACO    	
 
	
 
	   	  ??鱑?喊﹤        ???鏌?I)?皷 ?         ?   ?   ?  €?  

这段 JSON 是 glTF（GL Transmission Format）格式的，一个用于
 3D 场景和模型的传输格式。这个例子中使用了 Draco 压缩，这是一
种几何图形压缩方法，可以大幅减小 3D 模型的文件大小。
 
以下是该 JSON 文件的组织结构：
 
1. **asset**
   - 描述了 glTF 资源的信息，比如版本和生成器。
 
2. **scenes**
   - 定义了 3D 场景的列表，其中包含了场景所包含的节点（nodes）。
 
3. **scene**
   - 表示当前要展示的场景。
 
4. **nodes**
   - 定义了场景中的节点列表，其中每个节点可能包含子节点、网格、变换矩阵等。
 
5. **meshes**
   - 定义了网格的列表。每个网格都包含了一组 primitive，每个 primitive 
都有自己的 attributes，如位置、法线等。
 
6. **materials**
   - 定义了场景中使用的材料的属性。
 
7. **accessors**
   - 定义了如何从 bufferView 中访问数据，包含了类型、数量等信息。
 
8. **bufferViews**
   - 定义了如何在 buffer 中访问原始二进制数据。
 
9. **buffers**
   - 存储了原始二进制数据的长度信息。
 
10. **extensionsRequired 和 extensionsUsed**
    - 定义了此 glTF 模型所需和所用的扩展，本例中使用了 Draco 压缩的扩展。
 
### Draco 压缩
 
在这个例子中，`"KHR_draco_mesh_compression"` 扩展被使用，表示模型数据经
过了 Draco 压缩。压缩后的数据存储在 `buffer` 中。Draco 压缩的具体信息是
在每个 `primitive` 的 `extensions` 字段中定义的：
 
```json
"extensions": {
  "KHR_draco_mesh_compression": {
    "bufferView": 0,
    "attributes": {
      "NORMAL": 0,
      "POSITION": 1
    }
  }
}
```
 
这里的 `bufferView` 指向包含压缩数据的 `bufferView`，而 `attributes` 定义
了属性类型和对应的索引，这些索引对应于 Draco 压缩数据中的属性。
 
总而言之，这个 JSON 文件定义了一个 glTF 场景，其中包含了节点、网格、材料、访
问器、缓冲视图和缓冲器，以及 Draco 压缩的扩展，以减小 3D 模型的文件大小。 若
要渲染这个 3D 模型，需要按照定义在访问器和缓冲视图中的信息，从缓冲中获取原始
数据，然后解压 Draco 压缩的数据，最后应用材料并将其放入场景中。

indices是怎么来的，我看其他glb文件有的是1，有的是2？？？

在 glTF 结构中，`primitives`字段定义了如何将顶点属性组合成几何图元。
每个`primitive`都包含一个`attributes`对象，`attributes`对象定义了
一组`accessor`，这些`accessor`引用了包含实际几何数据的缓冲区视图
（`bufferView`）。`indices`字段则是一个指向`accessor`的索引，这个
`accessor`包含了组成这些几何图元的索引。
 
- `"indices": 0`表示用来组成几何图元的索引存储在`accessors`数组的第一个元素中。
- `"indices": 1`表示索引存储在`accessors`数组的第二个元素中。
- `"indices": 2`表示索引存储在`accessors`数组的第三个元素中。
 
以此类推。这个`indices`引用的`accessor`定义了如何从`attributes`指定的
顶点属性中索引值，来组成三角形或其他几何图元。
 
例如，如果您有以下几何结构：
```
"accessors": [
    { ... }, // 0: indices
    { ... }, // 1: POSITION
    { ... }  // 2: NORMAL
],
"primitives": [
    {
      "attributes": {
        "POSITION": 1,
        "NORMAL": 2
      },
      "indices": 0,
    }
]
```
 
在这个例子中，`indices`是`0`，意味着`accessors`数组的第一个元素包含了
组成几何图元的索引。而`POSITION`和`NORMAL`属性分别由`accessors`数组的
第二个和第三个元素提供。
 
所以，如果您在不同的glTF或glb文件中看到不同的`indices`值，这仅仅是因为
这些索引存储在`accessors`数组中不同的位置。这并不会影响最终模型的几何
结构，因为`indices`和`attributes`的组合提供了完整的几何定义。