GLTF扩展权威指南

NSDT工具推荐： Three.js AI纹理开发包 - YOLO合成数据生成器 - GLTF/GLB在线编辑 - 3D模型格式在线转换 - 可编程3D场景编辑器 - REVIT导出3D模型插件 - 3D模型语义搜索引擎 - AI模型在线查看 - Three.js虚拟轴心开发包 - 3D模型在线减面 - STL模型在线切割 - 3D道路快速建模

glTF 扩展扩展了基本 glTF 模型格式。 扩展可以引入新的属性（包括引用外部数据的属性，并且扩展可以定义这些数据的格式）、新的参数语义、保留的 ID 和新的容器格式。 扩展是针对特定版本的 glTF 编写的，并且可能会在更高版本的 glTF 中提升为核心 glTF。

glTF广泛应用于Web上的3D展现，如果你需要将模型转换为glTF格式，可以使用NSDT 3DConvert的在线转GLTF工具。

1、GLTF扩展机制

所有 glTF 对象属性（请参阅 glTFProperty.schema.json）都有一个可选的扩展对象属性，该属性可以包含新的特定于扩展的属性。 这允许扩展扩展 glTF 的任何部分，包括几何、材质、动画等。扩展还可以引入新的参数语义、保留 ID 和包含 glTF 的新格式。

GLTF扩展无法删除现有的 glTF 属性或重新定义现有的 glTF 属性以表示其他含义。

示例包括：

• 新属性： KHR_texture_transform 扩展引入了一组纹理变换属性，例如：

{
  "materials": [{
    "emissiveTexture": {
      "index": 0,
      "extensions": {
        "KHR_texture_transform": {
          "offset": [0, 1],
          "rotation": 1.57079632679,
          "scale": [0.5, 0.5]
        }
      }
    }
  }]
}

GLTF扩展可以添加新的属性和值，例如属性语义或纹理的 mime 类型。 在所有 Khronos (KHR) 扩展中，并且作为供应商扩展的最佳实践，这些功能添加旨在允许在无法识别 extensionsUsed 数组中的扩展的工具中安全回退使用。

模型中使用的所有扩展都以字符串形式列在顶级 extensionsUsed 数组中； 所有必需的扩展都以字符串形式列在顶级 extensionsRequired 数组中，例如，

{
  "extensionsUsed": [
    "KHR_draco_mesh_compression", "VENDOR_physics"
  ],
  "extensionsRequired": [
    "KHR_draco_mesh_compression"
  ]
}

这允许引擎快速确定它是否支持渲染模型所需的扩展，而无需检查所有对象的扩展属性。

如果典型的 glTF 加载器在不支持该扩展的情况下无法加载资源，则认为需要扩展。 例如，任何网格压缩扩展都必须根据需要列出，除非资产提供了未压缩的后备网格。 同样，必须根据需要列出纹理图像格式扩展，除非还提供了核心格式（JPG、PNG）的后备纹理。 通常，PBR 或其他类型的材质扩展不应在 required 中列出，因为核心 glTF 材质可以被视为此类扩展的有效回退，并且此类扩展不会导致一致的 glTF 加载程序失败。

2、创建GLTF扩展

要创建新的GLTF扩展，请使用GLTF扩展模板并在此存储库中打开拉取请求。 确保将扩展添加到 glTF 扩展注册中心。

如果扩展添加一个新的顶级数组（通过扩展根 glTF 对象），则其元素应继承  glTFChildOfRootProperty.schema.json 的所有属性。 扩展引入的其他对象应继承  glTFProperty.schema.json 的所有属性。 根据 glTF 2.0 约定，模式应该允许附加属性。 请参阅 KHR_lights_punctual 作为示例。

如果缺乏扩展支持会妨碍正确的几何加载，则扩展规范必须声明这一点（并且必须在 extensionsRequired 顶级 glTF 属性中提及此类扩展）。

3、GLTF扩展的命名规范

注意：由于历史原因，较旧的扩展可能不遵循这些准则。 未来的扩展应该这样做。

• 名称必须以大写前缀开头，后跟下划线。  Khronos 扩展的前缀为 KHR、多供应商扩展的前缀为 EXT，以及其他可能为供应商扩展保留的前缀。
• 名称必须在前缀后使用小写蛇形字母，例如 KHR_materials_unlit。
• 名称应该构造为 <PREFIX>_<scope>_<feature>，其中 scope是已有的 glTF 概念（例如 mesh、 texture、 image），而 feature描述了在该范围内添加的功能。 建议使用此结构，但不是必需的。
• scope应该是单一的（例如 mesh、 texture），除非这与现有的 Khronos 扩展（例如 material、 lights）不一致。

4、GLTF扩展 vs. GLTF附加

除了扩展之外， extras对象也可以用来扩展glTF。 这与扩展完全分开。

所有 glTF 对象属性都允许向 extras 对象子属性添加新属性，例如，

{
  "asset": {
    "version": 2.0,
    "extras": {
      "guid": "9abb92a3-39cf-4986-a758-c43d4bb4ab58",
    }
  }
}

这使得 glTF 模型能够包含特定于应用程序的属性，而无需创建完整的 glTF 扩展。 对于扩展不会被广泛采用的利基用例来说，这可能是首选。

5、GLTF扩展注册中心

应当将你的GLTF扩展添加到GLTF扩展注册中心，以便得到广泛地应用。具体注册方法请参考 README.md。

5.1 glTF 2.0已批准的 Khronos 扩展

Khronos 扩展使用保留的 KHR 前缀。 一旦获得 Khronos 集团的批准，它们就会受到 Khronos IP 框架的保护。 打算批准的扩展也可以使用 KHR 前缀来避免名称/代码/版本抖动。 Khronos 成员可以提交延期批准，然后由 Khronos 发起人委员会进行投票。

Khronos Group 已批准以下扩展：

• KHR_draco_mesh_compression

KHR_draco_mesh_compression扩展定义了一个架构以使用 glTF 格式的 Draco 几何压缩（非规范）库。 这使得 glTF 支持流压缩几何数据而不是原始数据。 该扩展规范基于 Draco 比特流版本 2.2（该规范的全部内容是规范性的并包含在范围内）。

一致性部分指定实现在遇到此扩展时必须执行的操作，以及扩展如何与基本规范中定义的属性进行交互。

• KHR_lights_punctual

KHR_lights_punctual扩展定义了一组与 glTF 2.0 一起使用的灯光。 灯光定义场景内的光源。

许多 3D 工具和引擎支持灯光类型的内置实现。 使用此扩展，工具可以导出这些灯光，引擎可以导入这些灯光。

该扩展定义了三种“准时”光类型：定向光、点光和聚光灯。 准时光被定义为参数化的无限小点，它们以明确的方向和强度发光。

这些灯光由节点引用并继承该节点的变换。

此扩展的一致实现必须能够加载资源中定义的灯光数据，并且必须使用这些灯光渲染资源。

• KHR_materials_anisotropy

KHR_materials_anisotropy扩展定义了材料的各向异性（anisotropy）属性，例如通过拉丝金属可观察到的属性。 引入非对称镜面波瓣模型来考虑这种现象。 该波瓣的视觉上明显的特征是镜面反射的细长外观。

• KHR_materials_clearcoat

KHR_materials_clearcoat扩展定义了一个透明涂层，可以分层在现有 glTF 材料定义之上。 透明涂层是基于物理的渲染中常用的技术，用于表示应用于基材的保护层。

• KHR_materials_emissive_strength

核心 glTF 2.0 材质模型包括 emissiveFactor 和 emissiveTexture 来控制材质发出的光的颜色和强度，并限制在范围  [0.0, 1.0] 内。 然而，在具有高动态范围反射和照明的 PBR 环境中，可能需要更强的发射效果。

在KHR_materials_emissive_strength扩展中，提供了一个新的 emissiveStrength 标量因子，它控制每种材料的发射强度的上限。

可以使用核心材料的 emissiveFactor 和 emissiveTexture 控件对该强度进行着色和回火，从而允许强度在材料表面上变化。 为 emissiveStrength 提供高于 1.0 的值可能会对反射、色调映射、光晕等产生影响。

• KHR_materials_ior

KHR_materials_ior扩展允许用户将折射率设置为特定值。

glTF 中金属粗糙度材料的介电 BRDF 使用固定值 1.5 作为折射率。 这非常适合许多塑料和玻璃，但不适用于水或沥青、蓝宝石或钻石等其他材料。

• KHR_materials_iridescence

彩虹色描述了一种色调根据视角和照明角度而变化的效果：半透明层的薄膜会导致相互反射，并且由于薄膜干涉，某些波长会被吸收或放大。 在肥皂泡、油膜或许多昆虫的翅膀上都可以看到彩虹色。

利用 KHR_materials_iridescence 扩展，可以指定薄膜的厚度和折射率（IOR），从而实现虹彩材料。

• KHR_materials_sheen

KHR_materials_sheen扩展定义了可以分层在现有 glTF 材质定义之上的光泽。 例如，光泽层是基于物理的渲染中用于表示布料和织物材料的常用技术。

• KHR_materials_specular

KHR_materials_specular扩展向金属粗糙度材质添加了两个参数：镜面反射和镜面颜色。

镜面反射允许用户配置电介质 BRDF 中镜面反射的强度。 值为零会禁用镜面反射，从而产生纯漫反射材质。 金属BRDF不受该参数的影响。

specularColor 更改电介质 BRDF 中镜面反射的 F0 颜色，允许艺术家在金属粗糙度材质中使用镜面光泽度材质 ( KHR_materials_pbrSpecularGlossiness) 中已知的效果。

• KHR_materials_transmission

KHR_materials_transmission扩展旨在解决光学透明度最简单和最常见的用例：无折射、散射或色散的无限薄材料。 专门处理“薄”材料（即仅考虑表面而不考虑体积的材料）可以在计算折射和吸收等内容时进行许多简化。

许多光学透明材料无法用核心 glTF 2.0 PBR 材料以物理上合理的方式表示。 这是因为核心规范仅包含“alpha 作为覆盖范围”的概念（通过 baseColorFactor 和 baseColorTexture 的 alpha 通道公开）。 许多常见材料（例如玻璃和塑料）需要截然不同的渲染技术。

• KHR_materials_unlit

KHR_materials_unlit扩展定义了用于 glTF 2.0 材质的无光照着色模型，作为核心规范提供的基于物理的渲染 (PBR) 着色模型的替代方案。 不发光材料的三个激励用例包括：

• 资源有限的移动设备，其中不发光的材质提供了更高质量着色模型的高性能替代方案。
• 摄影测量，其中照明信息已经存在并且不应应用额外的照明。
• 出于美观原因不需要照明的风格化材料（例如“动漫”或“手绘”外观）。

这些用例并不相互排斥：艺术家可能出于性能原因选择未照明的材料，并做出美学决策来补充该选择。 因此，能够渲染 PBR 的客户端实现不应自动“升级”到完全着色的 PBR。 在无光照材质上指定的任何核心 PBR 属性（ baseColor 除外）仅作为不支持 KHR_materials_unlit 扩展的客户端的后备。 扩展名，无论是资产中必需的还是可选的，都表明对无光照视觉样式的偏好。

• KHR_materials_variants

KHR_materials_variants扩展允许对资产的多种材质变体进行紧凑的 glTF 表示，其结构允许在运行时进行低延迟切换。

一个典型的用例是数字商务，其中可能会向用户展示例如 一双运动鞋以及在不同颜色之间切换的能力。

• KHR_materials_volume

默认情况下，glTF 2.0 材质描述包围无限薄体积的表面的散射属性。 由网格定义的表面代表薄壁。

KHR_materials_volume扩展使得可以将表面转变为体积之间的界面。 材料所附着的网格定义了均匀介质的边界，因此必须是流形的。 体积提供折射、吸收和散射等效果。 散射不是本扩展的主题。

• KHR_mesh_quantization

顶点属性通常使用 FLOAT 组件类型存储。 然而，这可能会导致精度过高、内存消耗和传输大小增加，以及渲染性能降低。

KHR_mesh_quantization扩展扩展了网格属性存储允许的组件类型集，以提供内存/精度权衡 - 根据应用程序需求，16 位或 8 位存储就足够了。

使用 16 位或 8 位存储通常需要转换原始浮点值以适应统一的 3D 或 2D 网格； 该过程通常称为量化（quantization）。

为了简化实现要求，该扩展依赖于现有的方法来指定几何变换，而不是向模式添加特殊的反量化变换。

例如，静态 PBR 就绪网格通常需要每个顶点的 POSITION（12 字节）、TEXCOORD（8 字节）、NORMAL（12 字节）和 TANGENT（16 字节），总共 48 字节。 通过此扩展，可以使用 SHORT 来存储位置和纹理坐标数据（分别为 8 和 4 字节），使用 BYTE 来存储法线和切线数据（各 4 字节），每个顶点总共 20 字节，通常可以忽略不计 质量影响。

由于该扩展不提供指定数据的 FLOAT 和量化版本的方法，因此使用该扩展的文件必须在 extensionsRequired 数组中指定它 - 该扩展不是可选的。

• KHR_texture_basisu

KHR_texture_basisu扩展增加了使用具有 Basis Universal 超级压缩的 KTX v2 图像指定纹理的功能。 此扩展的实现可以使用此类图像作为 glTF 2.0 中可用的 PNG 或 JPEG 图像的替代品，以提高资源传输效率并减少 GPU 内存占用。 此外，指定 mip 贴图级别是可能的。

使用扩展时，允许使用值 image/ktx2 作为 KHR_texture_basisu 纹理扩展对象的 source 属性引用的图像的 mimeType 属性。

在运行时，引擎应将通用纹理格式转码为平台支持的某种块压缩纹理格式。你可以使用BasisViewer在线查看Basis格式的纹理。

• KHR_texture_transform

许多技术可用于优化 3d 场景的资源使用。 其中最主要的是能够最大限度地减少 GPU 必须加载的纹理数量。 为了实现这一目标，许多引擎鼓励将许多对象的低分辨率纹理打包到单个大型纹理图集中。 然后，通过垂直和水平偏移以及该区域的宽度和高度来定义与每个对象相对应的生成图集的区域。

为了支持此用例，KHR_texture_transform扩展向 textureInfo结构添加了偏移、旋转和缩放属性。 这些属性通常作为 UV 坐标上的仿射变换来实现。 在 GLSL 中：

varying in vec2 Uv;

uniform vec2 Offset, Scale;
uniform float Rotation;

mat3 translation = mat3(1,0,0, 0,1,0, Offset.x, Offset.y, 1);
mat3 rotation = mat3(
    cos(Rotation), sin(Rotation), 0,
   -sin(Rotation), cos(Rotation), 0,
                0,             0, 1
);
mat3 scale = mat3(Scale.x,0,0, 0,Scale.y,0, 0,0,1);

mat3 matrix = translation * rotation * scale;
vec2 uvTransformed = ( matrix * vec3(Uv.xy, 1) ).xy;

这相当于Unity的 Material#SetTextureOffset和 Material#SetTextureScale，或者Three.js的 Texture#offset和 Texture#repeat。 截至目前，UV 旋转尚未得到广泛支持，但为了向前兼容性而包含在此处。

• KHR_xmp_json_ld

KHR_xmp_json_ld扩展向 glTF 添加了对 XMP（可扩展元数据平台）(ISO 16684-1) 元数据的支持。 元数据用于传输有关 glTF 资产的信息（例如归属、许可、创建日期）。 元数据对 glTF 资源外观和渲染没有规范影响。

XMP 是一种将元数据嵌入到文档中的技术，自 2012 年以来一直是 ISO 标准。XMP 数据模型的一个实例称为 XMP 数据包 (ISO 16684-1$6.1)。 XMP 元数据作为元数据包数组嵌入到顶级 glTF 扩展中。 然后可以从以下类型的 glTF 对象引用 XMP 元数据包：资产、场景、节点、网格、材质、图像、动画。 glTF 顶级对象资产引用的 XMP 元数据适用于整个 glTF 资产。

XMP 元数据按命名空间组织 (ISO 16684-1$6.2)。 此扩展允许将任何 XMP 元数据命名空间嵌入到 glTF 资产中。 glTF 中的 XMP 元数据数据包使用 JSON-LD 的受限功能子集。 这允许 JSON 解析器和 JSON-LD 解析器读取各个数据包。

XMP 的 JSON-LD 序列化 (ISO 16684-3) 中概述了使用 JSON-LD 序列化 XMP 元数据。 JSON-LD 规范概述了 JSON-LD 1.1 的详细使用方法。 JSON-LD 限制和建议中概述了 glTF 的其他限制。

• EXT_mesh_gpu_instancing

EXT_mesh_gpu_instancing扩展专门设计用于启用 GPU 实例化，使用少量绘制调用一次渲染单个网格的多个副本。 它对于树木、草地、路标等非常有用。平移、旋转和缩放属性允许网格以不同的旋转和比例显示在许多不同的位置。 与顶点属性一样，自定义实例属性可以使用下划线作为前缀（例如 _ID、 _COLOR 等），并用于特定于应用程序的效果。

虽然此扩展存储针对 GPU 实例优化的网格数据，但需要注意的是，(1) 即使没有此扩展，GPU 实例和其他优化也是可能的，并且受到鼓励，以及 (2) 该术语的其他常见含义“ 实例化”存在，与此扩展不同。

• EXT_meshopt_compression

glTF 文件带有各种二进制数据 - 顶点属性数据、索引数据、变形目标增量、动画输入/输出 - 这些数据可能占总体传输大小的很大一部分。 为了优化交付大小，可以使用 gzip 等通用压缩 - 但是，它通常不会捕获 glTF 二进制数据中的某些常见类型的冗余。

EXT_meshopt_compression扩展提供了一个用于压缩二进制数据的通用选项，该选项是针对 glTF 缓冲区中常见数据类型定制的。 该扩展在 bufferView 级别上工作，因此与数据的使用方式无关，支持几何图形（顶点和索引数据，包括变形目标）、动画（关键帧时间和值）和其他数据，例如 EXT_mesh_gpu_instancing 的实例转换。

与超压缩纹理类似（请参阅 KHR_texture_basisu），此扩展假设缓冲区视图数据针对 GPU 效率进行了优化 - 使用量化并使用 GPU 渲染的最佳数据顺序 - 并在 bufferView 数据之上提供压缩层。 每个 bufferView 都是独立压缩的，这使得加载器能够最有效地将数据直接解压缩到 GPU 存储中。

除了优化压缩比之外，压缩格式还具有两个特性：非常快的解码（使用 WebAssembly SIMD，解码器在现代桌面硬件上以约 1 GB/秒的速度运行），以及与通用压缩兼容的字节存储。 也就是说，不是尽可能减少编码大小，而是以通用压缩器可以进一步压缩比特流的方式构建比特流。

这对于典型的 Web 交付场景是有益的，其中所有文件通常都使用 gzip 压缩 - 这里的编解码器不是完全替换它，而是增强它，同时仍然减小大小（当 gzip 压缩不可用时，这对于优化交付大小很有价值） ，并且还减少了 gzip 解压缩的性能影响，gzip 解压缩通常比此处提出的解码器慢得多）。

• EXT_texture_webp

EXT_texture_webp扩展允许 glTF 模型使用 WebP 作为有效的图像格式。 未实现此扩展的客户端可以忽略提供的 WebP 图像并继续依赖基本规范中可用的 PNG 和 JPG 纹理。 定义后备纹理是可选的。 最佳实践部分描述了此扩展的预期用例以及在没有后备纹理的情况下使用它时的预期行为。

WebP 是一种由 Google 开发和维护的图像格式，可为网络上的图像提供卓越的无损和有损压缩率。 与 PNG 相比，它的尺寸通常小 26%，比同类 JPEG 图像小 25-34% - 源。

5.2 glTF 2.0 的多供应商扩展

当一个扩展由多个供应商实现时，其名称可以使用保留的 EXT 前缀。 Khronos IP 框架通常不涵盖多供应商扩展，但有一些值得注意的例外情况（上面列出）在 EXT 前缀下广泛使用后已经通过了 Khronos 批准过程。

• EXT_lights_ies

EXT_lights_ies扩展允许使用 IES 灯光配置文件作为场景内的光源。 IES 光轮廓使用来自光源的真实测量数据来描述光的分布。

许多 3D 工具和引擎都支持 IES 灯光配置文件。 使用此扩展，工具可以导出，引擎可以导入包含 IES 灯光配置文件描述的灯光的场景。

灯光配置由节点引用并继承该节点的变换。 它们描述场景内的点光源。 这些光源被定义为参数化的无限小点，它们以角度变化的强度向各个方向发射光。

此扩展的一致实现必须能够加载资源中定义的灯光配置文件并使用这些灯光渲染资源。 需要支持以下 IES 光配置标准：IES LM-63-95、ANSI/IESNA LM-63-02 和 ANSI/IES LM-63-19。 实施必须支持 B 型和 C 型光度测定的光配置文件。 对 A 型光度测定的光配置文件的支持是可选的。 请参阅实现细节，了解不需要的字段列表以及上述标准版本之间的相关差异的描述。

• EXT_lights_image_based

EXT_lights_image_based扩展提供了在 glTF 场景中定义基于图像的灯光的能力。 基于图像的灯光由环境图组成，该环境图表示场景的镜面反射亮度以及辐照度信息。

许多 3D 工具和引擎支持基于图像的全局照明，但所采用的具体技术和数据格式各不相同。 使用此扩展，工具可以导出，引擎可以导入基于图像的灯光，并且结果应该高度一致。

此扩展精确指定了一种格式化和引用要使用的环境贴图的方法。 这样做的目标有两个。 首先，它使得实现对此扩展的支持变得更加容易。 其次，它确保基于图像的照明的渲染在运行时保持一致。

此扩展的一致实现必须能够加载基于图像的环境数据并使用此照明渲染 PBR 材质。

5.3 glTF 2.0 的供应商扩展

供应商前缀列表维护在 Prefixes.md 中。 任何供应商（不仅仅是 Khronos 成员）都可以通过在 GitHub 上提交问题来请求扩展前缀。 请求应包括：

• 前缀的名称。
• 请求前缀的供应商的名称。
• 供应商的 URL 和/或联系信息。

Khronos IP 框架不涵盖供应商扩展。

• ADOBE_materials_clearcoat_specular

ADOBE_materials_clearcoat_specular扩展定义了一种控制  KHR_materials_clearcoat 扩展提供的透明涂层的折射率 (IOR) 和镜面 F0 的方法。 这会覆盖透明涂层的默认 IOR（1.5），并且还提供了一种调制 F0 反射率的方法。 这与 KHR_materials_ior 和 KHR_materials_specular 扩展一起修改 F0 反射率的方式完全相同。

• ADOBE_materials_thin_transparency

许多光学透明材料无法用核心 glTF 2.0 PBR 材料以物理上合理的方式表示。 Alpha 覆盖（通过 baseColorTexture 的 Alpha 通道暴露）对于不反射、折射、吸收或散射光的透明材质（例如纱布）很有用。 然而，大多数物理材料不属于这一类。 透明玻璃和塑料就是很好的例子。 在最简单的情况下，玻璃表面的镜面反射在完全透明的网格上仍然可见。 使用 0% 的 Alpha 覆盖率也会使反射不可见。

ADOBE_materials_thin_transparency扩展旨在解决光学透明度最简单和最常见的用例：没有复杂散射（例如动态散射）或色散的薄材料。 专门处理“薄”材料（即仅考虑表面而不考虑体积的材料）可以在计算折射和吸收等内容时进行许多简化。

• AGI_articulations

AGI_articulations扩展用于定义模型上所有可移动节点的自由度的名称和范围。

在 glTF 2.0 中，核心动画系统面向典型的图形行业使用模式，其中模型作者在创作时决定模型的哪些部分将移动，以及这些移动的确切性质和时间安排。 它不允许模型的某些部分被作者指定为可移动的情况，但它们的确切运动直到模型构建之后才知道。

例如，想象一下机动支架上的无线电碟形天线的情况。 构建模型时，模型作者可能知道碟形天线可以指向某些方向，但可能不知道（直到碟形天线被积极使用）它在任何给定时间指向哪里。 该碟形天线的 glTF 模型需要指出可用运动的名称和限制，但该模型不包含要执行的实际运动序列，这可能要等到运行时或碟子运行时的实时模拟才能知道。

在这种情况下，我们说模型是可以铰接（articulated）的，我们需要铰接来定义模型上所有可移动节点的允许运动（自由度）的名称和范围。 如果需要，将关节应用到节点并不排除将 glTF 核心动画应用到同一节点。 实现可以自由选择如何以及何时运用可用的关节，并且预计该信息将位于 glTF 文件的外部（否则它可以简单地编码为动画）。

• AGI_stk_metadata

AGI_stk_metadata扩展向 glTF 模型添加了额外的元数据。 这些元数据旨在与 Analytical Graphics, Inc. 生产的产品 STK（系统工具包）的现有功能进行 1:1 匹配。

• CESIUM_primitive_outline

非真实感 3D 对象（例如无纹理的建筑物）在勾勒出其边缘时通常更具视觉吸引力。 向 glTF 模型添加轮廓的一个简单方法是向模型添加 LINES 类型的附加基元，沿着要轮廓的边缘绘制线条。 不幸的是，这种方法的视觉质量相当差，因为线条深度与三角形相冲突。 线条的光栅化与三角形边缘的光栅化不匹配。

避免这种深度冲突的传统方法是使用 glPolygonOffset 或类似的方法。 然而，glTF 2.0 不支持指定多边形偏移。 即使它确实如此 - 或者定义了扩展来支持它 - 使用这种方法也很难获得高质量的渲染。 根据所选的多边形偏移值，由于深度偏差太大，背面上的线条可能会“渗透”到正面，或者由于深度偏差太小，线条可能会呈现点状外观。 即使仔细调整多边形偏移值，通常也可以在单个场景中同时检测到两个问题。

即使这些伪影被认为是可以容忍的，渲染单独的线图元也会增加渲染场景所需的绘制调用数量。 此外，在某些硬件上，绘制线条比绘制三角形要慢得多。

CESIUM_primitive_outline扩展向渲染引擎指示应勾勒出三角形边的列表。 虽然它没有规定应该如何完成渲染，但所有线条实际上都是三角形的边缘这一事实允许渲染引擎使用更高质量和更快的技术来渲染线条，而无需推断出这种技术在运行时的适用性。

• FB_geometry_metadata

FB_geometry_metadata扩展通过场景关联场景图的累积几何复杂性和场景空间范围的摘要来注释 glTF 场景对象。 每个递归引用的网格都会被枚举以获得总顶点和图元计数，并且每个单独的顶点都会被转换到场景空间中以获得完美计算的边界框。

此信息的一些经过验证的实际应用：

1. 当观看者需要快速、高级地决定显示哪个场景时。 这也许是最有意义的，例如 当场景用于表示模型的不同变体（例如 LoD 级别）时。

2. 当服务器端系统需要根据几何复杂性做出决策，并且不想包含自己的复杂矩阵/向量代码时。

• MPEG_accessor_timed

glTF 中的访问器定义存储在通过 bufferView 查看的缓冲区中的数据的类型和布局。 当从缓冲区读取定时数据时，缓冲区中的数据可能随时间动态变化。

包含定时媒体和/或元数据的场景应利用MPEG_accessor_timed定时访问器扩展来描述对动态变化数据的访问。 MPEG_accessor_timed 是常规访问器的扩展，用于指示底层数据缓冲区是动态的。 请注意，定时访问器有两个 bufferView，一个从包含访问器继承，另一个在 MPEG_accessor_timed 扩展中。 前者用于引用定时媒体数据。 后者可用于指向动态缓冲区标头，该标头可能存在也可能不存在。 当存在时，两个 bufferView 应指向同一个循环缓冲区。

具有 MPEG_accessor_timed 扩展的访问器中的 accessor.bufferView 字段以及定时访问器信息头字段适用于循环缓冲区内每个帧的数据。

定时访问器扩展由 MPEG_accessor_timed 标识。

• MPEG_animation_timing

MPEG_animation_timing 扩展支持媒体时间线和 glTF 2.0 定义的动画时间线之间的对齐。 使用扩展可以创建讲述的故事。 动画计时元数据可以允许同时暂停和对 glTF 2.0 和媒体中定义的动画进行其他操作。

• MPEG_audio_spatial

MPEG_audio_spatial 扩展添加了对空间音频的支持，它可以包含在顶层或附加到场景中的任何节点。

• MPEG_buffer_circular

为了支持定时数据访问，缓冲器元件被扩展以提供循环缓冲器的功能。 MPEG_buffer_circular 扩展可以被包括作为缓冲器的一部分。 提供对定时数据的访问的缓冲区应包括 MPEG_buffer_circular 扩展。

• MPEG_media

MPEG_media 提供了 glTF 文档中其他扩展引用的 MPEG 媒体项数组。

• MPEG_mesh_linking

MPEG_mesh_linking 扩展提供了将一个网格链接到 glTF 资源中的另一个网格的可能性。

阴影网格对应于 glTF 2.0 定义的常规网格数据，不带 MPEG_mesh_linking 扩展。 依赖网格可以通过依赖阴影网格来进行变换/动画。 包含在从属网格中的 MPEG_mesh_linking 扩展链接从属网格和阴影网格，并提供用于实现对从属网格进行动画处理的能力的数据和信息。 因此，阴影网格存在于 glTF 资源中，以帮助实现将变换应用到从属网格上的能力。

• MPEG_scene_dynamic

MPEG_scene_dynamic扩展链接。

• MPEG_texture_video

MPEG_texture_video 扩展提供了将 glTF 2.0 中定义的纹理对象链接到媒体及其相应轨道（由 MPEG_media 列出）的可能性。 MPEG_texture_video 扩展还提供对定时访问器的引用，即具有 MPEG_accessor_timed 扩展的访问器，其中解码的定时纹理将可用。

当不支持 MPEG_texture_video 扩展时，纹理缓冲区应由标准 glTF 源对象描述的数据填充。

• MPEG_viewport_recommended

MPEG_viewport_recommished 扩展通过引用定时访问器提供从 glTF 2.0 中定义的相机对象到推荐视口信息的链接，其中推荐视口信息的样本将可用。

推荐的视口信息提供动态变化的信息，包括包含相机对象的节点的平移和旋转，以及相机对象的固有相机参数。 客户端根据动态变化的信息来渲染视口。

注意：实现推荐视口的另一种方法是为带有附加相机的节点定义动画。 然而，该方法不支持动态更改内部相机，并且必须在创建 glTF 对象期间定义。

• MSFT_lod

MSFT_lod 扩展添加了为 glTF 资源指定各种细节级别 (LOD) 的功能。 此扩展的实现可以将 LOD 用于各种场景，例如根据对象的距离渲染不同的 LOD，或者从最低的 LOD 开始逐步加载 glTF 资源。

此扩展允许在几何节点或材料级别定义 LOD。 节点 LOD 可以跨不同级别指定不同的几何体和材料，而材料 LOD 可以为相同的几何体指定不同的材料。

MSFT_lod 扩展被添加到最高 LOD 级别。 扩展定义了一个 ids 属性，它是一个包含较低 LOD 级别索引的数组。 数组中的每个值都指向质量低于前一级别的 LOD 级别。 例如，如果扩展是在节点级别定义的，则具有扩展的节点对象是最高 LOD 级别。 扩展的 ids 数组中指定的每个值都指向另一个节点对象的索引，该节点对象应用作较低的 LOD 级别。

此扩展的实现可以解析 ids 数组以创建可用于资产的 LOD 级别列表。 如果包含此扩展的资源加载到未实现该扩展的客户端中，则将加载最高的 LOD 级别，并忽略所有较低的 LOD。

• MSFT_packing_normalRoughnessMetallic

MSFT_packing_normalRoughnessMetallic扩展增加了对备用纹理打包的支持，旨在用于 Windows Mixed Reality Home 和 Windows Mixed Reality 的 3D 启动器。

此扩展定义了 normalRoughnessMetallicTexture 的附加属性。 此属性指定具有包装法线 (RG)、粗糙度 (B)、金属 (A) 的纹理的索引。 这种专门的包装旨在为核心 glTF 2.0 规范中指定的包装提供一种优化的替代方案。

该扩展仅应在为支持此打包的引擎创建 glTF 资产时使用，而不是通用的打包扩展。 任何不支持此扩展的客户端都可以安全地忽略这些额外的打包纹理并依赖于 glTF 2.0 中的默认打包。 此扩展还可以与其他扩展（例如 MSFT_texture_dds）一起使用，以将打包纹理存储在 DDS 文件中。

• MSFT_packing_occlusionRoughnessMetallic

MSFT_packing_occlusionRoughnessMetallic扩展增加了对备用纹理打包的支持，旨在用于 Windows Mixed Reality Home 和 Windows Mixed Reality 的 3D 启动器。

此扩展定义了三个附加属性：

1. occlusionRoughnessMetallicTexture：指定具有包装遮挡 (R)、粗糙度 (G)、金属 (B) 的纹理的索引
2. roughnessMetallicOcclusionTexture：指定具有包装粗糙度 (R)、金属 (G)、遮挡 (B) 的纹理的索引
3. normalTexture：指定包含两个通道（RG）法线贴图的纹理的索引。

该扩展仅应在为支持此打包的引擎创建 glTF 资源时使用，而不是通用的打包扩展。 任何不支持此扩展的客户端都可以安全地忽略这些额外的打包纹理并依赖 glTF 2.0 中的默认打包。 此扩展还可以与其他扩展（例如 MSFT_texture_dds）一起使用，以将打包纹理存储在 DDS 文件中。

• MSFT_texture_dds

MSFT_texture_dds扩展添加了使用 DirectDraw Surface 文件格式 (DDS) 指定纹理的功能。 此扩展的实现可以使用 DDS 文件中提供的纹理作为 glTF 2.0 中可用的 PNG 或 JPG 纹理的替代方案。

该扩展名被添加到纹理节点并指定一个指向图像节点索引的源属性，该索引又指向 DDS 纹理文件。 不理解此扩展名的客户端可以忽略 DDS 文件并继续依赖指定的 PNG 或 JPG 纹理。

• NV_materials_mdl

NV_materials_mdl扩展提供了在 glTF 资源中存储和传输材质的能力，这些资源是在 NVIDIA 材质定义语言 (MDL) 中定义的，如 MDL 语言规范中所定义。 此扩展的目的是除了标准 glTF 2.0 PBR 模型之外，还可以在 glTF 中为支持 MDL 的应用程序和渲染器提供高质量的材质定义。

MDL 材料在 MDL 模块中定义，这些模块存储在文件扩展名为 .mdl 的文件中。 对 .mdl 文件的引用在一致实现的配置上下文中解析，特别是使用 MDL 语言规范附录 F 中记录的搜索路径。 作为替代方案，MDL 模块也可以嵌入到资产中。 MDL 材质可以接受纹理和其他资源作为输入参数。 此扩展使用 JPG 和 PNG 纹理的核心 glTF 2.0 标准中的图像。 此外，如果使用此扩展，图像对象还可以分别使用 image/x-exr 和 application/x-vdb 媒体类型引用 EXR 和 VDB 资源。 EXT_lights_ies 扩展用于 IES 灯光轮廓，MDL 语言规范附录 B 中定义的 MBSDF 各向同性测量 BSDF 数据是此扩展的一部分。

此扩展的一致实现必须能够加载引用的 MDL 模块，验证引用的函数调用和用户定义的类型在这些 MDL 模块中具有兼容的定义，并在引用的材质绑定中使用这些函数来渲染网格 相应的 MDL 材料代替标准 glTF PBR 材料。 通过检查带有类型参数的调用是否找到匹配的函数定义（包括 MDL 语言规范第 12.4 节中定义的重载解析）来针对 MDL 模块验证函数调用。 通过检查 MDL 模块中相应类型的所有字段或枚举值是否存在，针对 MDL 模块验证用户定义类型。

由于 MDL 材质取代了标准 glTF 材质，因此强烈建议创作应用程序还在 MDL 材质旁边提供紧密匹配的标准 glTF PBR 材质，以便不理解此扩展的实现仍然可以显示此 glTF 文件的代表性渲染 。 然而，定义后备材料是可选的。 最佳实践部分提供了有关此问题的更多详细信息。

MDL 材质是通过返回内置类型材质的语言中的函数来定义的。 此扩展对引用的 MDL 模块中定义的函数的函数调用进行操作。 这些函数调用在 functionCalls 数组属性中定义，该属性在顶级 NV_materials_mdl 扩展对象中定义。 函数调用和类型引用的模块在modules 数组中定义。 最后，BSDF 测量资源在 bsdfMeasurements 数组中定义。

5.4 glTF 2.0 的存档扩展

存档的扩展名对于读取较旧的 glTF 文件可能很有用，但不再建议使用它们来创建新文件。

• KHR_materials_pbrSpecularGlossiness

KHR_materials_pbrSpecularGlossiness扩展定义了基于物理的渲染 (PBR) 的镜面光泽度材质模型。 此扩展允许 glTF 支持此附加工作流程。

• KHR_techniques_webgl

KHR_techniques_webgl扩展允许 glTF 使用外部着色器程序及其参数化值定义着色技术的实例。 着色技术使用 JSON 属性来描述 GLSL 顶点和片段着色器程序的数据类型和语义。

此扩展规范针对 WebGL 1.0，并且如果设备支持必要的 WebGL 扩展，则可以在任何基于 WebGL 1.0 的引擎中受支持。

• KHR_xmp

KHR_xmp扩展向 glTF 添加了对 XMP（可扩展元数据平台）(ISO 16684-1) 元数据的支持。 元数据用于传输有关 glTF 资产的信息（例如归属、许可、创建日期）。 元数据对 glTF 资源外观和渲染没有规范影响。

XMP 是一种将元数据嵌入到文档中的技术，自 2012 年以来一直是 ISO 标准。XMP 数据模型的一个实例称为 XMP 数据包 (ISO 16684-1$6.1)。 XMP 元数据作为元数据包数组嵌入到顶级 glTF 扩展中。 然后可以从以下类型的 glTF 对象引用 XMP 元数据包：资产、场景、节点、网格、材质、图像、动画。 glTF 顶级对象资产引用的 XMP 元数据适用于整个 glTF 资产。 XMP 元数据按命名空间组织 (ISO 16684-1$6.2)。

此扩展允许将任何 XMP 元数据命名空间嵌入到 glTF 资产中。

5.5 进行中的 glTF 2.0 的 Khronos 和多供应商扩展

Khronos (KHR) 延期草案尚未获得批准。 多供应商 (EXT) 扩展不需要批准，但在完成之前仍可能发生变化。

本节跟踪 Khronos 和多供应商扩展的状态，这些扩展要么已经在开发中，要么我们认为表现出足够的共识，极有可能用于未来的开发。 我们欢迎对这些以及所有其他扩展提供反馈（请参阅 GitHub 问题）。 该列表旨在提供当前优先事项和方向的总体了解。

对于此处未列出但可能对不同用途很重要的功能，我们鼓励社区从供应商扩展（不需要审核）开始，寻求反馈和合作者，作为共识形式，我们可能会考虑最好的方法 将供应商扩展引入更广泛的生态系统：通过多供应商扩展、Khronos 扩展或包含在 glTF 规范的未来版本中。

原文链接：glTF Extension - KhronosGroup

BimAnt翻译整理，转载请标明出处