《glTF 资产格式与场景加载管线》

每个引擎都有自己的资产格式，导致建模工具、美术管线与运行时互相割裂。glTF 2.0（GL Transmission Format）由 Khronos 定义，把场景描述成一份 JSON + 若干二进制缓冲，兼容 glTF 的软件可以零转换互相传递——被 NVIDIA Omniverse、UE5（导入支持）、Babylon、Three.js 广泛采用。本文从 glTF 的层次结构讲起，覆盖 glb 二进制容器、Draco 压缩、PBR 属性映射、动画蒙皮，再讨论加载器架构与校验优化，与 WebGPU 教程 中 Web 端资产加载的场景直接衔接。

一、glTF 2.0 结构总览

一句话：glTF 2.0 是一个 JSON 文档描述场景图与资源引用，外加（可选的）.bin 二进制缓冲与图像文件，运行时解析 JSON、上传缓冲到 GPU，即可还原整个场景。

1.1 顶层结构

glTF 文档（JSON）:
  ├─ asset      : 版本、生成器信息
  ├─ scene      : 默认场景，引用根 node
  ├─ nodes      : 场景图节点（变换 + 子节点）
  ├─ meshes     : 网格（含 primitives 子集）
  ├─ materials  : 材质（PBR 参数）
  ├─ textures / images / samplers : 纹理链路
  ├─ buffers / bufferViews / accessors : 几何与属性数据
  ├─ animations : 动画轨道
  └─ skins      : 蒙皮（骨骼矩阵）

1.2 数据引用链

buffers (.bin 或内嵌 base64)
  └─ bufferViews    : 某缓冲的字节区间 + 对齐
      └─ accessors  : 视图内的具体数组（float3 顶点、uint16 索引等）
          └─ 被 mesh.primitive / animation / skin 引用

关键点：accessor 描述"哪段字节、什么类型、多少元素"，GPU 上传时只需把 bufferView 的字节拷给 VBO/IBO，accessor 则翻译成绑定格式。

{
  "buffers": [{ "uri": "scene.bin", "byteLength": 4096 }],
  "bufferViews": [{ "buffer": 0, "byteOffset": 0, "byteLength": 2048 }],
  "accessors": [{
    "bufferView": 0, "componentType": 5126,
    "count": 256, "type": "VEC3"
  }]
}

1.3 三种表达

.gltf + 外部分离文件（JSON 引外部 .bin/.png，可读）与 .gltf 内嵌 base64（data URI，单文件）适合调试；.glb 二进制容器体积最小、解析最快，是发布首选。

二、scene 与 node：场景图

一句话：glTF 的场景图是 node 树：每个 node 有平移/旋转/缩放（TRS）或矩阵，可挂网格、蒙皮、相机、光源；scene 则是一组根 node。

2.1 node 结构

{
  "nodes": [
    { "name": "car", "translation": [0, 0, 0],
      "rotation": [0, 0, 0, 1], "scale": [1, 1, 1],
      "children": [1, 2] },
    { "name": "wheel_FL", "mesh": 0, "translation": [-1, 0.3, 1.2] }
  ]
}

• TRS 优先：矩阵由 TRS 计算；若直接给 matrix 则覆盖；
• rotation 是四元数（x,y,z,w），Y-up 右手系、单位米——glTF 约定与多数引擎对齐；
• extensions：节点可扩展（KHR_lights_punctual 给光源、KHR_mesh_quantization 给量化顶点等）。

2.2 运行时遍历

加载器按 node 数组递归建树：由 TRS 或 matrix 计算局部矩阵，mesh 索引映射到网格资源，children 递归挂接，即可还原完整变换层级。

2.3 scene 与默认相机

scene 数组里通常一个"主场景"；scenes[0] 为默认。相机可选（KHR_camera 或 nodes[].camera），引擎若未提供相机可用 glTF 自带的透视/正交定义直接建。

三、mesh 与 primitive：几何数据

一句话：mesh 由若干 primitive（子网格）组成，每个 primitive 是"一份索引 + 一组顶点属性 accessor"，材质挂在 primitive 上——多材质物体天然拆成多 primitive。

3.1 primitive 结构

{ "meshes": [{
    "name": "car_body",
    "primitives": [{
      "attributes": { "POSITION": 0, "NORMAL": 1, "TEXCOORD_0": 2 },
      "indices": 3, "material": 0, "mode": 4
    }]
}] }

• attributes：键为语义（POSITION/NORMAL/TANGENT/TEXCOORD_0/COLOR_0/JOINTS_0/WEIGHTS_0），值为 accessor 索引；
• mode：4=三角形（默认）、5=三角带、6=三角扇等；
• material：该子网格用的材质（可为空 → 默认材质）。

3.2 顶点属性约束

KHR_mesh_quantization 允许 POSITION 用 int16 等量化类型，大幅降体积但需要运行时反量化。

3.3 双份上传策略

加载器为每个 primitive：从 accessor 解析顶点布局（stride/format/offset）→ 拷贝 bufferView 字节创建 VBO/IBO → 记录 material 索引绑定对应 PSO；注意 JOINTS/WEIGHTS 这类整型属性在 Vulkan 中须独立缓冲。

四、material：PBR 材质属性映射

一句话：glTF 的材质是 Metallic-Roughness PBR（金属度-粗糙度），所有引擎按同一套语义把 JSON 参数映射到自己的着色器常量与纹理槽。

4.1 核心参数

{
  "materials": [{
    "name": "gold",
    "pbrMetallicRoughness": {
      "baseColorFactor": [1, 0.766, 0.336, 1],
      "baseColorTexture": { "index": 0, "texCoord": 0 },
      "metallicFactor": 1.0,
      "roughnessFactor": 0.3,
      "metallicRoughnessTexture": { "index": 1 }
    },
    "normalTexture": { "index": 2, "scale": 1.0 },
    "occlusionTexture": { "index": 3 },
    "emissiveFactor": [0, 0, 0],
    "emissiveTexture": { "index": 4 },
    "alphaMode": "MASK",
    "alphaCutoff": 0.5,
    "doubleSided": true
  }]
}

4.2 与引擎着色的映射

4.3 注意点

• 色彩空间：baseColorTexture 采样后要 sRGB→linear 解码（见 纹理与内存），而法线/ORM（occlusion-roughness-metal）纹理是线性；
• MetallicRoughness 纹理打包：B 通道存金属度、G 通道存粗糙度、R 通道留作 AO——采样后必须拆通道；
• doubleSided：决定背面剔除是否关闭，影响网格背面光照；
• extensions：KHR_materials_pbrSpecularGlossiness（旧版）、KHR_materials_clearcoat、KHR_materials_emissive_strength 等扩展材质。

// GLSL：glTF Metallic-Roughness 采样核心
vec4 baseColor = texture(baseColorTex, vUv) * uBaseColorFactor;
float metallic = texture(ormTex, vUv).b * uMetallicFactor;
float rough    = texture(ormTex, vUv).g * uRoughnessFactor;

五、sampler 与纹理链路

一句话：纹理经 images → textures → samplers 三层描述：image 指向像素数据，texture 把 image 与采样器组合，sampler 定义过滤与环绕模式。

5.1 三层结构

{
  "images":  [{ "uri": "albedo.png", "mimeType": "image/png" }],
  "samplers": [{ "magFilter": 9729, "minFilter": 9987,
                 "wrapS": 10497, "wrapT": 10497 }],
  "textures": [{ "sampler": 0, "source": 0 }]
}

• 过滤：9729=LINEAR、9987=LINEAR_MIPMAP_LINEAR（三线性）；
• 环绕：10497=REPEAT、33071=CLAMP_TO_EDGE、33648=MIRRORED_REPEAT；
• image 的 source：外部文件或内嵌 base64。

5.2 运行时上传

// C++：纹理上传
TextureUpload(gltf, texIndex) {
    Image img = decode(gltf.images[texIndex]);
    if (sampler.minFilter 用了 mipmap 过滤) generateMipmaps(img);
    createImage(img, filter, wrap, mipLevels);
}

5.3 常见陷阱

• minFilter 指定 mipmap 但 image 无 mipmap → 需运行时生成，否则采样错误；
• wrapS/T 与引擎默认不一致 → 纹理边缘硬切；
• 同一 image 被不同 sampler 引用时，须按 sampler 各自创建视图；
• Draco 压缩只压几何，纹理仍走普通 image 路径。

六、二进制 glb 与 Draco 压缩

一句话：glb 把 JSON 与 .bin 塞进一个文件（JSON chunk + BIN chunk），Draco 则用网格压缩把顶点数据缩小一个数量级，两者叠加让资产体积大幅下降。

6.1 glb 容器格式

glb 文件:
  header   : magic(glTF) + version + totalLength
  JSON chunk : { length, type(JSON), jsonData }
  BIN  chunk : { length, type(BIN),  binaryData }
  可选: 第 3 个 chunk 存放扩展数据（如 Draco 压缩缓冲）

JSON 里的 buffer 不再给 uri，而是指向 BIN chunk 偏移（"buffer": { "byteLength": N }，加载器按 bufferViews 在 BIN 里取区间）。

6.2 Draco 压缩

KHR_draco_mesh_compression 扩展把几何数据用 Draco 库压缩——JSON 的 extensions 里声明压缩数据所在的 bufferView 与 attributes 映射（如 POSITION→accessor 0），运行时用 Draco 解码器解出顶点数据再上传 GPU。典型收益：

6.3 解码成本权衡

• 解码用 WASM/C++（native）或 JS 库 draco3d，Web 端通常异步解码；
• 加载时间 vs 解码时间：体积省下的下载时间常大于解码时间，收益为正；
• 高端机直接解码到 GPU；低端机可先加载低 LOD（见 LOD）再异步补高模。

七、动画与蒙皮数据

一句话：glTF 动画是一组关键帧轨道（translation/rotation/scale/weights），蒙皮则用骨骼关节矩阵把顶点变形——加载器要同时处理"时间采样"与"GPU 矩阵调色板"。

7.1 动画轨道

{ "animations": [{
    "channels": [{ "sampler": 0, "target": { "node": 1, "path": "rotation" } }],
    "samplers": [{ "input": 0, "output": 1, "interpolation": "LINEAR" }]
}] }

• path：translation / rotation / scale / weights（形态键）；
• interpolation：LINEAR / STEP / CUBICSPLINE；
• 运行时按时间在 accessor 的采样点间插值，更新节点 TRS。

7.2 蒙皮（Skin）

{ "skins": [{
    "joints": [0, 1, 2],
    "inverseBindMatrices": 4,   // accessor，每关节的逆绑定矩阵
    "skeleton": 0
}] }

顶点属性 JOINTS_0 / WEIGHTS_0 指定每顶点影响它的关节与权重。运行时计算：

最终关节矩阵 M_j = 全局关节矩阵_j × 逆绑定矩阵_j
顶点变形   = Σ weight_i × (M_joint_i × 顶点位置)

// GLSL：蒙皮顶点着色器
layout(set = 0, binding = 3) readonly buffer Joints {
    mat4 jointMat[MAX_JOINTS];
};
void main() {
    ivec4 joints = ivec4(aJoints);
    vec4  w = aWeights;
    mat4  skin = w.x * jointMat[joints.x] + w.y * jointMat[joints.y]
               + w.z * jointMat[joints.z] + w.w * jointMat[joints.w];
    gl_Position = projView * nodeMatrix * skin * vec4(aPos, 1.0);
}

7.3 注意事项

• JOINTS_0 的 componentType 多为 8-bit/16-bit 无符号整型，Vulkan 整型顶点属性须独立缓冲；
• 权重需归一化（glTF 不保证和为 1，加载时可归一）；
• 动画节点树与蒙皮关节树可能不同，运行时需分别维护；
• 形态键（Morph Targets）经 weights 轨道混合，逐顶点加位移。

八、加载器架构与校验优化

一句话：加载器要决定"何时解析、何时上传、何时解码"——离线烘焙（转原生格式）与运行时解析（即时用 glTF）是两条路径，配合同步/异步加载与校验工具构成完整资产管线。

8.1 离线烘焙 vs 运行时解析

AAA 游戏通常发布时转成私有二进制（离线烘焙），Web 与引擎内嵌（Three.js/Babylon）则运行时解析。

8.2 加载管线分层

1. 读取: 网络/磁盘 → 字节
2. 容器: 解析 glb chunk / gltf JSON
3. 数据: 构建 bufferViews → accessors → 上传 GPU（同步/异步）
4. 解码: Draco 解压、纹理解压、量化反量化
5. 组装: node 树 → 运行时 SceneGraph（材质/网格/动画绑定）
6. 就绪: 交给渲染循环（可先显示占位、后填充）

8.3 校验与优化工具

优化步骤通常：量化 POSITION → Draco 压几何 → 纹理压缩（KTX2/BasisU） → 抽取（去未用数据） → 合并 mesh，最终体积可缩 80~90%。

8.4 工程陷阱

• 忘记处理 byteOffset 对齐（accessor 要求对齐），GPU 绑定崩溃；
• 纹理未生成 mipmap 导致远处闪烁；
• 动画轨道 accessor 的 stride 与插值器假设不符；
• 多 primitive 材质切换状态混乱，Draw Call 翻倍；
• 加载器同步解析阻塞主线程 → 帧率掉帧，须异步加载。

// C++：异步加载示意（主线程先渲染占位场景，等待完成再切换）
std::future<Scene> fut = std::async([&] {
    auto gltf = gltf::Load(filePath);
    return BuildScene(gltf, UploadMeshes(gltf));
});

总结

glTF 2.0 用"JSON 场景图 + 二进制缓冲"统一了 3D 资产的交换语言：scene/node 描述场景、mesh/primitive 组织几何、material 携带 Metallic-Roughness PBR 参数、sampler 定义纹理采样，glb 容器与 Draco 压缩把体积压到一个数量级，动画与蒙皮数据则让资产可动、可交互。加载器的核心是把这些结构映射到 GPU 资源与运行时 SceneGraph，并配合离线烘焙或异步解析满足平台需求。

实践路径：先用 gltf_validator 跑通最小 glb，手写加载器解析 node/mesh/material 并上传到渲染管线；再接入 Draco 解码与纹理 mipmap；随后补动画与蒙皮；最后用 gltf-transform/gltfpack 做体积优化，并用 RenderDoc 核对 GPU 资源与 glTF 语义一致。