复杂场景

工厂数字孪生由数千种设备模型构建。一个街区由建筑物、基础设施和地形组成。仿真环境是由许多厂商提供的资源拼接而成。像这样的场景是被组装出来的，而不是单文件——但glTF 2.0只提供了两种方式来实现它们：将所有内容压缩到一个整体文件中，或者采用专有的多文件合成惯例。这两者都无法保持glTF价值所在的互操作性，这一差距成为在该规模上采用glTF的主要障碍之一。

glTF 2.1通过一套协调的核心功能缩小了差距。在场景合成方面，外部资产允许 glTF 文件引用其他 glTF 文件，并在加载时将其实例化为场景层级结构，而 Packaging 则将合成场景及其所有依赖作为一个独立的资产交付。对于空间原件，隐式体积通过形状进入核心规范，包围体层级利用它们使大型场景的筛选、流式和查询变得高效。在这两者之下，都有统一文件引用——一个统一且一致的机制，用于解析外部、嵌入和打包资源，其余架构依赖于此。

这些能力共同使得完整、结构化、多文件场景能够作为一个互操作的 glTF 资产交付——它们构成了构建渐进场景流、LOD 层级、分布式资产库和大规模协作环境等功能的基础。它们还使2.0规范中的一项变得过时：glTF 2.1正式弃用了本节末尾描述的罕见多场景模式。

外部资产

通过外部资产，glTF 文件可以声明性引用其他 glTF 文件，并将其实例化为自身场景层级中的模型。该模型在CAD和BIM中很熟悉：装配文件引用零件文件，打开装配时即可解析。在 glTF 2.1 中，这个分辨率是在加载时完成的——根文件声明它需要的内容，加载程序负责合成场景。

这个单一机制包含多个工作流程。一个大型场景可以由许多独立编写和维护的 glTF 文件组成。同一被引用的资产可以被实例化任意次数——同一设备模型的千百个实例，加载一次并重复使用——使得大型重复场景变得紧凑易实现。而且由于引用是声明式的，加载可以被推迟：只有当应用程序决定需要时才获取内容，而这正是渐进式场景流的基础。资源间的循环引用被严格禁止，保持每个场景的加载依赖是无循环且可预测的。

该工作组此前曾作为独立的伴随格式 glTF 外部参考（社区内许多人称之为“glTFX”）探索过这一功能。glTF 2.1 通过将外部引用直接引入核心规范，解决了这一长期存在的设计讨论，每个符合标准的加载器都将支持它。设计还着眼于未来：引用资产通过一种间接层次声明，未来扩展可以用来自定义实例——例如覆盖变换以呈现引用角色姿态——而无需改变引用机制本身。指向被引用文件的路径通过新数组表示，即本节后面将介绍的统一引用机制。​​files​​

外部资产打包

外部资产功能不仅仅是链接文件：它还可以打包它们。当外部 glTF 文件作为缓冲区视图嵌入而非由 URI 引用时，主机文件的文件数组作为虚拟文件系统——嵌入文件中的任何 URI 都是根据该数组中声明的原始 URI 值解析，而非针对文件系统或网络。

这意味着单个 glTF 文件可以作为复杂多文件场景的完全自包含包，承载所有依赖——纹理、缓冲区和嵌套的 glTF 文件——而无需修改任何原始数据。原本分布在多个文件中的场景可以打包成一个资源，方便分发、归档或交换，而每个组件文件的内部结构和URI则保持不变。嵌套资产间共享的资源——例如多个设备模型使用的纹理——一次性存储，并由所有设备模型解析。

这种方法是有意选择的，而不是基于ZIP的容器或重构的多块GLB等替代方案。通过直接在外部资产和文件机制之上构建打包行为，glTF 2.1 提供了自包含的复杂场景，无需额外容器格式实现。

形状

glTF 2.1 将隐式几何图形纳入核心规范。这解决了一个长期存在的空白：glTF 2.0 没有原生方式来表示简单体积，如盒子、球体、胶囊或圆柱体，除非诉诸显式网格几何。这使得glTF在物理流程、空间查询系统和程序式内容工作流中既昂贵又低效，而原始形状是自然的工作单位。

glTF 2.1 增加了顶层数组，取代了待处理的 KHR_implicit_shapes 扩展，并为这些常见原语在规范中提供了一个稳定、可互操作的归属。基础规范定义了五种形状类型的几何、参数化和语义——箱形、球形、胶囊形、圆柱形和平面形态，这些类型在物理引擎和空间查询系统中广泛支持。未来可能会通过扩展添加更复杂或专用的形状类型。这种分层的方法既保持核心可实现性和聚焦，又为更丰富的形状词汇在扩展生态系统中不断发展留下空间。​​shapes​​

在glTF 2.1中，形状有一个核心消费者：它们是构建包围体层级（下文所述）的几何结构。核心层面上，相同的定义也准备好通过扩展服务物理碰撞器、触发体和程序流程——一个共享的形状词汇，涵盖每个空间用例，而非每个扩展自行发明。

包围体积层级

高效的空间查询，如碰撞检测、遮挡剔除、光线交叉和物理仿真，都依赖于连接场景节点的紧凑且结构良好的边界体。在 glTF 2.0 中没有标准表达方式，因此每个引擎和运行时都会创造自己的惯例，削弱了可移植性。

glTF 2.1 将包围体层级（BVH）纳入核心规范，新增节点性质：一个简单的几何形状，可选择变换，完全包围节点内容。体积是从刚才描述的隐式形状构建的，因为它们连接在节点上而非网格上，因此可以绑定任何内容——网格、灯光、摄像机或整个参考资产。通过节点层级定义的体积保持空间连贯性：节点的体积完全包含其后代内容，这使得层级结构易于穿越。​​boundingVolume​​

作者可以完全控制每卷的紧凑程度。蒙皮网格的体积可以被设计为包含所有合理的变形状态;有许多动画儿童的家长可以省略自己的体积，动态依赖自己的体积。除了剔除和交叉，应用还可以利用边界卷驱动延迟加载——仅在内容量变得相关时（通过摄像头角度大小或其他指标）获取内容——这与外部资产结合，正是渐进场景流构建的基础。

统一文件引用

外部资产和打包都基于本节中出现的一个机制：新的顶层阵列。它的存在是因为glTF 2.0没有统一的外部内容引用惯例。URI出现在规范的多个位置——缓冲区、映像——每个都有自己的处理方式，每个引用外部文件的扩展都必须定义自己的数组，重复相同的模式、 、 和属性。​​filesuribufferViewmimeType​​

实际代价是，工具无法可靠地发现glTF文件的依赖关系，除非了解每个扩展名。本应简单的操作——将glTF文件及其依赖打包到自包含的资产中，从文件选择器上传完整模型，确认没有遗漏——如果不支持所有引用该文件的扩展，就无法正确实现。

阵列解决了这个问题。它的工作方式与现有和数组类似，但接受任何文件类型，必须有 ，未来所有添加到 glTF 的新文件类型都会使用该类型——同时且继续保持不变，以实现完全向后兼容。文件间的循环引用被严格禁止。结果是：工具需要在三个地方精确查找glTF文件的每个外部依赖——、、和——，从而赋予格式可移植性、在操作系统和部署环境中明确的路径解析，并为复杂场景奠定上述所有基础。​​filesbuffersimagesmimeTypebuffersimagesbuffersimagesfiles​​

特色	它的作用
外部资产	引用场景节点的 glTF/GLB 资产，并在加载时实例化一次或多次实例化
外部资产打包	将一个合成好的场景及其所有依赖资源作为一个可移植的产物交付，无需修改原始文件
形状	描述简单的非渲染体——盒体、球体体、胶囊体、圆柱体和平面体——以表示紧致边界和代理体
包围体积层级（BVH）	为任意节点附加包围体，形成层级结构，使大型场景的剔除、流式处理和查询更高效
统一文件引用	命名、定位并解析外部、嵌入和打包资源，包括glTF资产、纹理、音频、行为图、元数据模式和压缩有效载荷

多场景的贬低

glTF 2.0 允许一个文件在数组中包含多个场景，并带有一个属性表示默认值。实际上，这一功能很少被使用，支持不一致，且在交换中存在歧义——glTF 2.0 从未定义过同时使用多个场景的方法，社区多年来一直要求移除该功能。大多数工具每个文件只生成并消耗一个场景。​​scenesscene​​

上述复杂的场景功能现在提供了多个场景从未实现过的所有功能——一种定义了在层级中实例化资源、无限次重用以及跨文件组合的方式——因此glTF 2.1正式弃用多场景模式，明确glTF文件最多包含一个场景。这不是破坏性变更：现有文件依然有效，glTF 2.1导入器应继续像glTF 2.0时一样处理多个场景，只有新内容才不建议依赖该模式。

生活质量改进

除了复杂的场景外，glTF 2.1还带来了工作组称之为“生活质量”的一系列改进——这是一个刻意谦逊的名称，指的是那些价值会叠加的变化。仅凭这些特征，并不能改变 glTF 所表达的内容。每一个项目都消除了流水线中某个实际消耗时间的阻力：必须先渲染才能浏览资产的预览、无法容纳单个GLB的数据集、产生技术上无效文件的转换、无法可靠从文件外部寻址的对象。这种摩擦作用叠加到每一个资产、每一个工具以及它们之间的每一次交接，消除这些摩擦是glTF 2.1让日常工作更高效的直接方式之一。

这些改进涵盖了资产的整个过程——从创作和格式转换，到资产管理与优化，再到交付和工具链集成。还有几个改进还纠正了glTF 2.0规范中已承认的漏洞，在核心中弥补这些漏洞，而不是让每个实现都绕过它们。每项改进将在下文中描述。

缩略图

glTF 2.1 引入了一流的缩略图支持，这一实用功能提升了 glTF 的工作流程和可用性。glTF 2.0 文件没有标准机制来携带预览镜像，因此资产管理系统、文件浏览器和内容管道必须提前渲染每个资源，或者退回到通用图标。

在 glTF 2.1 中，glTF 文件可以声明缩略图——嵌入文件中或与之并列引用——应用程序可以在不加载场景图到三维引擎的情况下显示。缩略图完全是可选的，不需要的应用可以忽略。效果立竿见影：用户浏览数百个模型库，无需启动渲染器即可看到每个资产的真实内容，作者还能提供超出3D场景可见的自定义图像——摆拍角色、品牌封面。对于管道和数字资产管理（DAM）系统，标准化缩略图完全消除了专有预览生成步骤的需求。

64位二进制文件格式

GLB 二进制容器格式在 glTF 2.0 引入，使用32位长度字段，单个块限制在 4 GiB。虽然这一限制在典型的实时3D资产中很少成为问题，但对于高保真内容、大规模点云、密集网格数据、地理空间数据集以及辐射场格式（如3D高斯喷溅）来说，这一限制日益成为重要。

glTF 2.1定义了二进制格式版本3，将长度字段升级至64位——将上限从4 GiB提升至8 EiB，足以在可预见的未来满足现代资产大小的全部需求。现有的版本2格式依然完全定义：glTF 2.1导入器必须支持两个版本，导出器可以继续生成版本2文件，以实现最大兼容性，只要内容符合现有限制。版本3还增加了保留的块编码字段——在glTF 2.1中始终为零——为未来版本和扩展提供了明确的分块级压缩功能。这是一项务实的升级，为大型专业和地理空间工作流程中已出现的数据量提供未来适应性。