游戏引擎的资产管道处理

对于游戏引擎的资源处理，引擎有着一种复杂的机制，我对于其中的理解是 它作为一种将艺术家所作的产品连接到游戏引擎中，再由游戏开发者去引用，是一种特别重要的工具。一个好的引擎资产管道，它能够使艺术家更专注于其领域相关的艺术作品，程序员也不需要在关注于其资产的兼容性。

接下来我将涵盖如下内容：

1   资产管道是什么？ Asset Pipeline Overview 资产管道的概述

2   资产管道如何设计，设计资产管道的主要目标和挑战是什么？

3   推或拉管道模型：从不同的角度解决问题，以实现更好的设计。

4   collada 数字标准的中间语言 利用标准及其广泛的可用性来构建资产管道。

5  用户内容： 重新定向资产管道以促进用户内容的创建

资产管道是什么？

资产管道是所有游戏资产从创建工具到最终游戏版本的路径。游戏中有许多需要用到的资产类型：模型，材质，纹理，动画，音频和视频。资产管道负责从用于创建他们的工具中获取数据，然后优化，分割，合并，转换和输出。（如图）

原始资产

原始资产是由艺术家和设计师创建的，通常是使用第三方工具DCC，原资产一般需要涵盖游戏所有的数据内容。

最终资产

最终的资产是针对于某个目标平台进行了优化和打包，通常，作为游戏开发人员无法参与设置给定的文件格式，而是由引擎强加给一个给定的格式。最终资产不需要多余的信息，因为所有数据都被引擎优化到了最佳值，就像源代码一样，必须针对某个特定平台优化。例如，纹理应该以硬件可以立即使用的格式和大小进行存储，因为纹理压缩算法和参数需要针对目标纹理硬件和显示功能进行优化。还为每个目标编译几何数据。大多数平台将只接受三角形，但是每批三角形的数量、顶点的排序顺序、三角形条的需要以及每个顶点的数据量将对游戏引擎的性能产生很大的影响。对硬件的着色器渲染功能的限制也可能会对几何图形产生影响，因为可能需要创建多个几何图形，以使引擎能够在单独的通道中使用这些几何图形来创建所需的效果。

最终的资产也需要对游戏的加载速度进行优化。例如将数据转换为二进制存储，以便于加载游戏时减少CPU时间，对于一个非常简易的游戏，它会尽可能的将数据压缩并且在游戏加载某一关卡时直接加载一次。当玩家游走的时候不会不断被loading例如（UE4 Level）。在引擎中内置良好的实时数据流功能是一项基本的核心技术。 引擎中内置良好的实时数据流功能是基础核心技术之一，它还有助于在不同平台上为玩家提供类似的 因为设备内存大小的限制可以被本地缓存机制所掩盖。因为设备内存大小的限制可以被本地缓存机制所掩盖。此外，如果内容存储为特定的硬件格式（例如，CD 或 DVD 可能有较长的寻道 时间较长），则必须按照游戏中出现的顺序对数据进行排序。

构建过程

构建过程使将所有的源数据转换为目标平台数据并且加入优化技巧，是自动化的（例如UE5 U3D 的build按钮一键点击就可以自动打包）。构建过程应进行优化，只处理与上次构建过程相比发生变化的数据。为整个游戏构建优化数据可能需要几个小时，甚至一整天。尤其是在项目结束时，需要在短时间内进行大量调整，而数据存储库已完全填充完毕，因此构建时间最长。在流程的早期，人们可能很少关注构建流程的优化和数据的组织，但游戏的整体质量和成功与否将取决于大部分资产创建完成后的最终编辑。换句话说，设计不当的构建流程很可能会直接影响最终产品的质量。

优化资产构建过程的主要问题之一是缺乏有关依赖关系的信息。由于源资产通常以特定于工具的不透明格式存储，因此通常不可能很容易地解析数据并递归地收集依赖关系信息。在源代码开发中，对依赖信息的需求和直接从源代码提取已经存在多年，但不幸的是，这样的过程还没有成熟，这将要求游戏引擎开发者积极开发自己的过程。

优化资产构建流程的主要问题之一是缺乏有关依赖关系的信息。由于源资产通常以特定工具的不透明格式存储，因此通常无法轻松解析数据并递归收集依赖关系信息。多年来，在源代码开发过程中一直需要从源代码中直接提取依赖性信息，但遗憾的是，这种流程在资产方面尚未成熟，这就要求 游戏引擎开发人员需要有自己的一套开发经验。

关于资产构建系统，有一些很好的信息来源，如《Game Asset Pipeline》和《Microsoft XNA content pipeline》书籍。尽管 XNA 仅针对微软平台（PC 和 Xbox 360）设计，并且有一些设计限制，例如依赖文件扩展名来区分数据类型，以及将构建信息嵌入源代码而非描述性数据[5]，但我们还是要提到后者。

元表

在游戏开发中一个非常常见的问题是，难以知道需要使用哪些资源、哪些资源依赖于其他资源以及哪些资源不再需要。在开发过程中，数据经常被堆积到一个共享目录中，游戏可以正常运行，因为脚本或其他资源引用的所有数据都可用。问题在于，很难知道哪些资源是真正必要的，因此在项目中途打包一个演示版本通常会导致压缩数据达到几个GB，分发变得困难。手动维护清单实现起来并不容易，因为这需要对艺术家和设计师施加严格的政策，确保他们将所有引用的资源添加到清单中，并移除未使用的资源。在实践中，手动维护清单几乎没有希望，因此非常有必要创建一个自动系统，从游戏的顶层描述（即关卡设计文件）中提取清单。为了能够自动创建清单，需要访问存储在资源内部的外部引用，例如脚本、纹理、模型、动画或其他引用，因此必须警惕在资源管道中使用不透明的格式。这些信息可以用来创建一个依赖图，使构建过程仅处理给定关卡所需的文件。依赖图还提供了对依赖于已更改资源的资源需要重新构建的理解。

快速路径

快速路径是指无需经过完整构建过程即可将资源加载到游戏引擎中。这一捷径对提高艺术家的效率非常重要。使用快速路径时，艺术家调用最小化的导出机制，实现更快的迭代。通常，艺术家只处理特定资源的子集，因此只有这些资源的数据会走快速路径，而场景的其他元素仍可以从最终构建路径加载。引擎需要同时支持完整构建和快速路径资源，以确保在生产过程中两者能够同时处于活动状态。快速路径加载器可以在引擎中被删除，除非开发者希望保留该功能供修改者使用。快速路径优化了整体生产过程，对在时间和预算限制内成功交付游戏非常重要。

中间资产
中间资产是介于源数据和最终形式之间的数据。它们通过DCC工具的导出器创建，并在最终转换成最终资产包之前代表沿构建过程处理的数据。中间资产格式应易于读取、解析和扩展，尽可能无损地包含所有可能需要的信息。早期不需要过度优化数据，最好在后续管道中自动丢弃不必要的数据，而不是每次需要额外信息时重新导出所有源资产。推荐使用纯文本或结构化XML文件，因为它们具有可读性，并且可以利用许多能够处理标准XML格式的库。此外，许多编程语言（如C# Python、Java等）内置了直接加载XML文档并提供对嵌入文档对象模型（DOM）的编程访问和搜索功能的能力。

理想情况下，整个转换过程中应使用单一灵活的中间格式，以便在内容管道中始终使用相同的格式和I/O代码，并提供更改构建过程步骤及其执行顺序的灵活性。这意味着格式需要尽可能接近DCC工具中的表示，以简化导出过程并尽量减少数据丢失，同时转换数据为尽可能接近目标平台所需最终编码的格式。这在设计中间格式时增加了一些复杂性，但最终避免了在导出过程中过早转换数据而导致的导出时间增加和数据丢失。如图所示，资产处理模块可以直接对中间资产进行转换，如三角化、纹理处理和细节层次计算。

管道
构建管道由多个处理模块组成。由于中间资产在整个过程中始终保持相同格式，因此可以在管道中的任何点进行探测。虽然不是必需的，但可以创建一个带用户界面的特定工具，通过简单连接资产处理模块来创建构建过程。这种设计使构建过程更加通用，能够处理来自各种来源和工具的数据，并可配置以支持现有和未来的目标平台，通过不同组合或配置一组资产处理模块。

如果一种格式能满足源和中间资产的需求，并被DCC工具识别，则无需使用不同的格式。这并不意味着数据在构建过程中保持不变，而是指可以使用相同的格式存储各阶段的转换数据。例如，虽然存在数百种图像文件类型/格式，但没有一种能够同时作为源和中间格式。理想情况下，源格式应能存储无压缩和/或无损压缩的像素，有些图像需要比通常的8位分量更高的分辨率，因此格式应允许16位甚至24位分量。高动态范围（HDR）存储日益重要，其中开放格式OpenEXR提供了支持。另一方面，中间格式应尽可能接近目标平台格式，但要求各异，几乎不可能统一。例如，最终纹理数据必须表示mipmaps、立方体贴图、体积贴图、高度贴图、法线贴图和纹理数组，并处理内存对齐、位交换、平铺和硬件压缩（DXT）。Microsoft的D3DX10格式可能最接近中间图像格式的需求，包括DirectDraw Surface（DDS）描述以及PNG、IFF和BMP格式。此外，它还可在Microsoft平台上用作最终格式。问题在于图像创建工具可能没有该格式的导出和导入工作流，迫使源和中间图像资产使用两种不同格式。

除了从源格式转换为中间格式外，图像还需要为DCC工具提供，这可能需要另一次格式转换。Adobe Photoshop的PSD本地格式能存储大量数据，希望主要DCC工具能直接加载PSD图像，并利用图层和其他附加信息。有趣的是，Adobe最近推出了开源通用图像库，旨在简化和优化图像资产处理，但不支持Adobe自己的PSD格式。

过去，游戏引擎开发者必须为艺术家使用的每个供应商特定工具创建自己的中间格式并编写自己的导出器插件，这是一项艰巨任务，尤其是在跟踪DCC SDK问题时。幸运的是，这已不再是必要的，开发者应利用标准中间格式和现有源代码。

中间资产以开放和文档化格式存储，对游戏资产的存档也很重要。例如，一家大型工作室发布了基于新IP的游戏，巧妙地存储了所有源资产、源代码和构建过程。经过多年后，续集被下达，但源资产无法被新版本DCC工具识别。幸运的是，他们还存储了创建资产的工具，但无法让旧工具的许可证服务器工作。中间资产以二进制不透明格式存储，因此无济于事，所有资产不得不重新创建。使用文本/XML文档化的中间格式存档可以节省大量时间和金钱

资产管道设计
从终端用户的角度来看，资产管道应该是透明的。理想情况下，资产管道开发的最终成果是让艺术家和游戏设计师感受不到管道的存在，认为创作工具与游戏引擎之间没有任何障碍。资产管道的核心工具是游戏引擎编辑器，它提供了资产集成接口。编辑器基于与游戏引擎相同的核心技术，为艺术家、设计师和工程师提供了所见即所得（WYSIWYG）环境，以快速处理资产和解决设计或引擎问题。

游戏引擎编辑器

有两种工作流程可供选择：

1 编辑器是一个高级查看器，允许用户在引擎中检查资产并控制相机位置、光照条件以及显示的资产。在这种设计中，资产仅在DCC工具中修改和编辑，每次更改时都会导出。

2 部分资产可在编辑器中编辑。这种设计使得资产管道工作流程更加复杂，因为编辑器实际上在创建源资产，需要适当地存储以进行构建过程。

设计内容管道时的两个主要考虑因素是效率和灵活性。效率对于团队按时交付高质量内容至关重要，灵活性则是为了适应团队不断变化的需求。然而，这两者之间存在一定的对立，因此没有单一解决方案能够满足所有项目的要求。相反，需要在设计资产管道时做出权衡和妥协。

因此，游戏引擎编辑器将根据项目的具体情况提供查看和编辑功能的组合。关键在于确定编辑功能的范围。显然，不实际重新编写所有DCC工具的编辑功能是不可行的。这将是一个重大任务，且会将开发重点从创建游戏转向创建DCC工具，这是一个完全不同的业务。一些人尝试通过将游戏编辑器写成DCC工具的插件来解决这个问题，但这也行不通，因为这需要在3D软件包中编写图像编辑器、音频编辑器、脚本编辑器、AI工具和关卡编辑器，并将工具链锁定在工具SDK的扩展能力上。正确的折中方法是仅在游戏编辑器中编写非常特定于游戏的编辑功能，或者提供比现成工具更大的效率改进。

此外，项目的资产管道设计应具有足够的灵活性，以便在项目过程中能够纳入新工具。这可能是一个微妙的过程。

其他考虑因素
管道的稳健性同样重要。资产管道是项目和团队的骨干。当管道出现故障时，项目将停滞不前，团队成员会因等待管道修复而闲置。坚实的设计和适当的文档告诉团队如何使用和扩展资产管道是其稳健性的关键。

效率、灵活性和稳健性都是中间资产格式的主要目标。提供源数据和最终资产格式之间的步骤的主要优势在于解耦引擎开发和资产创建。如果最终资产在导出时直接创建，大多数引擎更改将需要同步更改导出器，这将需要重新导出所有资产。缓存中间资产并在快速路径和构建的最后步骤中提供必要的更改，比重新加载所有DCC工具中的资产并重新导出更为高效。

推或拉管道模型

直接修改中间资产而不编辑源资产和重新导出是非常重要的，尤其是在时间紧迫时。但这通常不是一个好主意，因为中间资产会在源数据下一次修改和导出时被覆盖。

理想的解决方案是在管道的任何点进行更改，并确保这些更改反馈到源数据中。一种方法是能够将中间资产重新导入DCC工具，以便将修改合并回源资产中。但源资产中有许多数据在中间资产中没有复制，如构建历史和工具小部件布局。此外，中间资产可能已经过处理，原始数据形式丢失。因此，重新导入中间资产应考虑将更改合并到源资产中。

解决方案和示例
传统上，资产管道设计为推模型，用户必须通过调用构建过程来创建中间或最终资产，然后将结果加载到编辑器中查看最终结果。改进这一模型的方法是使用游戏引擎编辑器直接从用户界面拉取中间或最终资产。

例如，Torque 3D资产管道实现了这一技术，游戏引擎编辑器积极监听中间或最终资产的变化，并在外部变化时自动更新编辑器中的内容。另一种类似的想法是在《All-Important Import Pipeline》中描述的，游戏引擎编辑器提供用户直接加载中间资产，并自动调用构建过程按需创建最终资产。

这些方法朝着正确的方向迈进了一步，但尚未解决在应修改源资产时编辑中间资产的问题。资产管道设计如下图所示，添加了远程控制线，用户可以在游戏引擎编辑器中选择任何内容，并在中间资产存储源资产依赖关系和相关DCC工具的情况下，自动启动并提供给用户进行更改和重新导出。结合前述引擎监听中间资产变化并自动调用构建过程的方法，这提供了高效、灵活和稳健的资产管道设计。

用户视资产管道为拉模型。中间资产通过资产浏览器被拉入编辑器，例如，资产浏览器可以提供按类型分类的资产快速预览。编辑器可以自动创建清单并自动通过跟踪中间资产中存储的依赖关系构建依赖关系图。编辑器可以用于选择一个或多个资产并调用编辑命令，该命令将查看中间资产信息或用户偏好，并调用首选的DCC工具来编辑正确的源资产。编辑器还可以直接调用版本控制系统，适当地检出本地副本并检入修改后的资产。可以提供一组通用模型作为占位符，这些占位符可以插入当前游戏关卡中，以供以后创建资产，自动生成艺术团队的任务列表。

一种标准的中级语言

在2004年SIGGRAPH大会上，[20] COLLADA被介绍为首个针对游戏开发者的开放数字资产交换（.dae）规范。这一初步规范在经过一年的开发后向公众发布。恰好一年前，在2003年的SIGGRAPH大会上，索尼计算机娱乐（Sony Computer Entertainment）成功组建了一个由业内关键公司组成的工作组，试图创建一个通用的中间语言，以提供表示高级平台（如PlayStation 3）所需的所有资产。这些公司包括Alias、Discreet和Softimage等竞争对手，它们同意暂时放下竞争，参与设计和原型开发。Digital Eclipse、Electronic Arts、Ubisoft和Vicarious Visions等游戏开发者也支持这一想法，并提供了帮助。

经过多次迭代，规范得以稳定。2005年7月，Khronos Group [22] 发布了1.4版本的规范，[21] 这是一个开放标准，由同一组织管理OpenGL、OpenGL ES、OpenCL等知名图形标准。1.4版本规范经过了小修小补，发布了1.4.1规范，这在本出版时是最受欢迎的实现。

在2008年SIGGRAPH大会上，COLLADA规范1.5版本被引入，[23] 增加了来自CAD和GIS领域的功能，如逆运动学（IK）、边界表示（b-rep）、地理位置以及使用MathML描述语言的约束数学表示。1.4.x和1.5.x规范并非完全向后兼容，这不成问题，因为中间资产总是需要从源资产重新导出。截至今天，1.4.x格式是大多数应用程序支持的格式，而1.5支持仅限于少数应用程序，主要是在CAD领域。1.4.x和1.5.x规范将并行存在并维护。1.5版本引入的新功能可能永远不会融入1.4.x规范，因此越来越多的工具可能会提供这两种实现。从用户的角度来看，加载1.4或1.5应该是透明的，因为文档中包含了其编码版本的信息。

由于COLLADA是一个开放标准，许多公司提供了实现方案。COLLADA从一开始就被设计为一个无损中间语言，应用程序可以进行导入和导出。COLLADA作为语言的重要性在于，语言需要被使用和理解。为了验证和测试一个实现，必须使用有效的文档对应用程序进行测试，然后导出以与原始数据集进行比较，以查看是否在过程中丢失了任何数据。这是官方Khronos COLLADA合规性测试的基础，该测试提供了一个验证和认证过程，以向最终用户保证高质量的实现。通过测试的应用程序有权显示合规徽标。设置有效的独立合规性测试并不容易，因此在测试可用和强制执行之前，由于不同的人工解读规范，存在一定程度的不兼容性，但这些问题可以由最终用户修复。

由于COLLADA提供了导入和导出功能，并且可用于许多工具，它也作为一个交换格式而广受欢迎。交换格式的目标是使源资产能够从一个DCC工具转移到另一个DCC工具，这显然不是资产管道的目的。结果表明，COLLADA作为交换格式表现相当出色，能够比一些现有解决方案提供更快速、更准确的数据转换。

COLLADA 1.4.x的功能列表包括几何体、动画、蒙皮、变形、材质、着色器、相机、（刚体）物理和变换层级。它基于XML（可扩展标记语言）标准来电子编码文档，因此所有COLLADA文档都可以由任何商业或开源XML工具管理。COLLADA使用XML-Schema语言 [24] 定义，以便工具可以使用COLLADA模式来验证文档或自动创建各种语言的API以及编辑和展示工具。

COLLADA以非常结构化的方式可扩展。中间格式必须可扩展，因为资产管道需要编码特定于游戏引擎或游戏本身的数据。扩展的问题在于如何设计它们，以便不识别扩展的工具仍然可以导入中间资产，并在可能的情况下继续处理扩展。COLLADA在模式中提供了几个可以使用<technique>和<extra>元素进行扩展的地方。由于这些元素不能在文档的任何地方放置，因此COLLADA解析器可以被设计成识别这些扩展，并要么忽略内容，要么更好地将内容保存在字符串中以传递信息。当然，如果工具识别了扩展，它应该使用它！扩展对象有两种方式：要么是增加现有元素定义的附加信息，要么是对元素通用定义的替代定义。开发者可以决定如何扩展。如果扩展是通过替换进行的，则需要保持一个可以被其他工具用作占位符的通用定义。例如，一个使用特定几何定义的引擎（如metaballs [25]）可以使用<extra>元素存储metaball信息，同时保持标准网格几何体来存储通用网格。

让我们看看一些设计原则，这些原则旨在提供必要的灵活性，以便在共同语言中表示数据，同时尽可能接近特定的DCC表示，并使内部转换能够使其更接近引擎特定表示。该部分的其余内容是对COLLADA设计原则的概述。有关更多技术详细信息，读者可以参考Khronos网站 [22] 上的COLLADA 1.4和1.5规范以及本书附带的CD。这些规范和COLLADA参考书 [26] 提供了有关设计标准时所做选择的更多细节。

<source> 元素

<source>元素包含资产使用的原始数据。像其他元素一样，它有一个在有效文档中必须唯一的id属性。一个source包含一个特定类型（ID、名称、布尔值、浮点数或整数）的数据的一维数组。每个元素可以有一个名称，这个名称必须是有效的XML字符字符串，但名称信息仅用于存储对人类有意义的信息，永远不会用来在文档中引用对象。浮点数和整数可以用任意位数表示，提供所需的任何精度。尽管普遍认为使用十进制数字表示浮点数会有精度损失，但只要使用足够的数字——单精度9位和双精度17位 [27]——就绝对不会有精度损失。数组本身包含一个计数属性，以便于内存分配。

<technique_common>元素提供有关其他元素如何访问source的相关信息。<technique>元素是扩展可以找到的地方；一个元素可以同时携带来自多个工具的扩展，因为每个工具为其技术提供了一个配置文件名称。下图显示了一个<source>元素中只能有一个数组，并且显示了名称属性是可选的（用虚线表示），而id属性是必需的。所有这些信息都存储在Khronos网站上的XML模式中，可以自动转换为绘图或用于验证文档。下图显示了一个文档中的source是什么样的，且其解析起来非常简单。

<accessor> 元素

<accessor>元素（见图）是灵活性的核心。它使我们能够以更接近工具或目标格式的格式组织数组，从而允许构建过程在两者之间进行转换。这提供了更好的解耦，因为导出器可以按原样导出数据，然后使用<accessor>元素来解释数据应该如何被访问。count属性告诉可以通过<accessor>元素访问多少个元素，以及要使用的偏移量和步幅，通常会创建n-元组数据。然后它描述每个n-元组元素的一个参数，给出名称和类型。示例见上图。

如果<param>元素没有给出名称，这意味着对应的值将被忽略。因此，一个具有3-元组值的source数组实际上可以定义一个2-元组，带有一个填充值。如你所见，在同一语言中，可以以多种不同方式表示位置数组。聪明的读者会注意到<source>元素中的数组是可选的，其原因是<accessor>元素可以引用存储在另一个<source>元素中的数组，从而使得通过多个<accessor>元素以不同方式重用相同的数据数组成为可能。

几何体和<mesh> 元素

几何体最常通过<mesh>元素表示，尽管<convex_mesh>元素和<spline>元素分别用于刚体物理和2D动画曲线。COLLADA 1.5规范将<brep>添加到几何体类型列表中。<mesh>元素包含一组<lines>、<linestrips>、<polygons>、<polylist>、<triangles>、<trifans>和<tristrips>元素。最有可能的是，刚导出的网格数据是多边形，这些多边形通常会在构建管道接近末尾时被转换为三角形。

<mesh>元素包含一个必需的<vertices>元素，如上图所示。它有一个必需的input元素，该元素引用一个<source>元素，意味着它使用<source>元素中的<accessor>元素来访问数据。一个非常有趣的设计特性是COLLADA中没有提及顶点数据的维度。换句话说，一个顶点可以有一个、两个、三个或任何数量的维度，尽管大多数内容将使用带有X、Y和Z参数名称的3D顶点，因为在<scene><node>元素中，变换和位置限制为4D齐次坐标空间。<input>元素将一个语义与source相关联。自然，唯一必需的input是语义POSITION，它提供网格原语中所有顶点的位置（例如，x、xy、xyz、xyzw）。<vertices>元素可以包含多个<input>元素，以附加与每个顶点相关的额外数据。例如，通常会为每个顶点存储一个NORMAL，在旧系统中，每个顶点还常常有一个COLOR。

下图中的<triangles>元素作为<mesh>元素的子对象之一，可以看到它也由一组<input>元素组成，这些元素存储与每个原语相关的数据，而不是之前在<vertices>元素中处理的每个顶点的数据。一个<input>元素定义了语义VERTEX，它通过索引引用<mesh><vertices>元素中定义的POSITION，用于每个原语。显然，一个三角形列表中的每个元素包含三个顶点。<p>元素因此由P×N个索引组成，其中P是原语的数量，N是原语列表中定义的<input>元素的数量。

结论
总之，关于中间资产格式设计和COLLADA标准所做的选择，还有一些高层次的概念值得提及。

在设计中间资产格式时，最重要且最困难的设计概念是尽量避免依赖特定的实现或运行时。换句话说，数据应该是自描述的，以便可以在任何现有或未来的运行时中进行转换和使用。这是一个非常困难的设计目标，也是COLLADA工作组的大多数设计会议所关注的重点，因为一个功能的初步草案总是接近于运行时的使用方式或模型创建的方式。确保数据不是相对于单一的使用模型进行描述是非常重要的，因为这可以确保设计不会因为技术的快速发展而变得过时，或因为强加了与尚未发明的使用模型不匹配的模型而限制创造力。这一点设计原则是COLLADA与大多数其他格式的主要区别。这种区别在与Autodesk专有的FBX交换技术进行比较时尤为明显，FBX的定义完全通过API和特定的使用模型来进行：
“FBX文件格式没有文档。应用程序使用FBX SDK从FBX文件中导入场景数据或将场景数据导出到FBX文件中。”
—— FBX SDK程序员指南，第6页[28]。

另一个重要的设计原则是将元素分类为<library_xx>元素类型，这有助于数据的组织以及使文档内容按类型分开。重要的是区分数据定义和通过实例化进行的使用。这使得一个元素可以多次使用而不必重复定义，这样会显著减少中间和最终资产的大小。COLLADA通过使用<param>元素允许在实例化时修改某些元素的值，因此可以共享大部分元素定义并节省大量空间，同时仍然允许源数据更改影响所有实例，这在生产过程中非常有用。

最后但同样重要的是，COLLADA利用了URI技术[29]，这使得元素可以引用其他文档中的数据以实现灵活的组织，同时也利用了多种存储技术。例如，外部引用URI可以是被Web服务器解释为数据库查询的HTTP请求，或者是对本地存储设备上文件的简单引用。使用没有良好外部引用机制的格式的一个主要问题是所有中间资产都需要被组织在一个单一的文档中。这样的文档在项目进行过程中可能会变得无法管理。此外，这意味着所有数据必须由资产管道中使用的所有工具导入和导出，这是一大限制性问题。

OpenCOLLADA
由于COLLADA的开放性及其使用标准XML技术进行描述的特性，存在许多商业和开源选项可以用来与COLLADA文档接口。一些编程语言如C#和Python提供了可以直接与XML数据接口的库，给程序员提供了文档对象模型（DOM）[30]，即XML层次结构的内存表示，可以被程序化访问。C++的库，作为游戏引擎开发中最常用的语言，直接提供这个功能的库不多。不过，有几个通用库存在，可以加载和保存XML内容，还有一些商业工具可以在XML模式中自动生成特定的访问API，创建特定文档的API。C++程序员可以使用COLLADA DOM，它自动从模式生成核心API，并提供一个API来帮助管理内存中的对象。DOM提供了不仅仅是加载和保存接口的功能；它允许XML元素在内存中存在，因此可以直接编辑，而无需创建单独的表示[31]。

最近，在2009年SIGGRAPH期间，NetAllied Systems宣布了OpenCOLLADA[32]的可用性，这是第一个利用SAX解析和直接写入技术的开源实现，支持1.4和1.5版本。项目页面可以在 http://www.opencollada.org/ 找到。基于此技术构建的3DS Max和Maya插件，以及框架的源代码，都可以在该网页上找到，并且这些内容也包含在本书附带的CD中。读者被鼓励查看该网页以获取最新更新。

SAX（简单的XML API）是解析XML文档的另一种模型[33]。大多数现有库的主要问题是它们加载所有XML数据并创建数据的内存表示，然后再创建第三份数据副本以创建程序使用的对象表示。这种问题在所有文件加载SDK中都很常见，不论格式本身如何，这使得处理越来越大的资产变得困难。

当使用库创建完整的内存数据表示以导出内容时，这种内存管理问题同样存在。如果使用的库创建一个完整的内存表示，然后将数据写出，当一个大型模型在DCC工具中加载时，工作站内存通常会被耗尽，当导出被调用时，计算机会因为将所有内存内容交换出去以腾出空间给另一份数据副本而挂起。导出内容时可以采用相同的原则，通过写出数据目录来避免创建另一份内容副本。

上图中展示的DAE2Ogre示例代码 演示了如何利用这一技术。其思想是将一个写入器与读取器C++对象关联，其中读取器是COLLADA SAX解析器，而写入器（在本例中）是Ogre引擎特定格式。由于所有数据不会一次性加载到内存中，因此不能跟踪引用并期望找到数据。因此，SAX解析器使用UniqueId类型进行引用。由于数据按COLLADA文件中的顺序传递给写入器，因此在前向引用数据的情况下，可能无法立即解析引用。为了解决这个问题，通常需要两次加载文件。在第一次加载中，收集和存储场景图、材质和其他数据。在第二次加载中，处理几何体、动画和其他数据。SAX解析器比将所有数据保存在内存中稍复杂，但由于OpenCOLLADA开源框架[34]的可用性，这并不困难。正如我们已经看到的，对于如此大的资产，使用这种技术在内存使用方面有很大优势，同时也带来了性能提升。

上图展示了在3DS Max中对大场景进行导入和导出的操作的持续时间和内存消耗。这些表格比较了开源OpenCOLLADA技术和使用DOM/中间内存模型库FCollada[35]的Feeling Software开源实现。值得注意的是，这两种COLLADA实现之间的性能差异是显而易见的，无论用于存储的确切格式如何，读者都被鼓励对大型数据集进行性能测试，以提高资产管道的效率（如有需要）。

用户内容
Modding是一个计算机游戏社区俚语，源自动词“modify”，特别指创建新的或修改过的内容。Modding曾被视为边缘活动，但现在受到鼓励，因为它延长了游戏的生命周期。游戏开发者提供工具，帮助游戏社区创建额外内容，这些工具需要购买游戏本身，这为开发者提供了额外的内容和收入，而没有额外成本。实际上，强大的社区被开发并提供强大的病毒营销，从而增加了对游戏开发者的黏性和忠诚度。由最终用户创建的内容被称为用户内容或玩家内容。

为了让最终用户创建内容，游戏开发者必须提供简化或更强大的游戏编辑器、脚本和内容管道的访问权限。由于最终用户不太可能访问昂贵的DCC工具，因此提供一个也能利用免费的工具（如Blender[36]、Google SketchUp[37]或XSI Mod Tool[38]）的资产管道是非常重要的。Crymod是Crytek游戏的成功modding社区的一个例子，它在网页上拥有自己的门户，网址为 http://www.crymod.com/。Crytek与Softimage（现由Autodesk拥有）合作，提供一个COLLADA导出器的专业版工具，提供免费的专业级工具，并集成了资产管道，以增强高质量用户内容的创建。修改后的导出器使用Crytek引擎识别的特定名称语义，并用于将创建的内容连接到其物理和其他游戏特定实体。值得注意的是，这条资产管道（Mod Tool到COLLADA再到CryEngine）并未被Crytek用于开发自己的游戏，而是专门为modding社区设计的。但现在，这个工具链也找到了内部使用的机会。

越来越多的用户内容可以在3D内容库中找到。Google 3D Warehouse允许SketchUp用户将内容上传到这个库中，允许任何人搜索和下载COLLADA格式的内容。随着SketchUp 7.1的发布，提供了COLLADA的免费导入和导出功能，现在可以将使用其他工具创建的内容上传到仓库中，与其他用户共享。由于仓库与Google Earth相连，这里有许多现有建筑物的模型以及种类不断增加的内容。在游戏的原型设计阶段利用这些内容是值得考虑的，因为这是开发游戏玩法的一个很好的捷径，之后可以用真实资产替换这些内容。另一个用户内容网站采用了不同的方法：www.3dvia.com（一个达索系统公司）允许用户上传编码为多种源格式的内容，并自动在服务器上运行转换工具，使任何上传的内容都以3DXML（达索专有格式）和COLLADA格式提供。截至撰写时，已有超过150,000名用户和15,000个模型在这个3D用户内容社区中活跃。

一些游戏更进一步地利用了最终用户的创造力。Maxis/Electronic Arts的游戏《Spore》就是一个很好的例子，用户可以使用内容创建工具制作他们自己的生物、车辆和建筑物以在游戏中使用。《Spore》的最新版本将这一原则扩展到冒险或小游戏的创建。这类游戏的口号是“乐趣在工具中”，而《Spore》用户也确实享受其中，据报道已经创建了超过三百万个生物。在2009年SIGGRAPH期间，《The Sims》和《Spore》的创造者Will Wright做了一个主题演讲[39]，宣布了对用户内容的进一步支持。通过最新的《Spore》补丁，用户不仅可以创建丰富游戏的内容，还可以将游戏中的生物导出为COLLADA格式[40]。这个小小的变化为最终用户打开了一个新世界。这些生物被导出时包括它们的骨架和皮肤，以及漫反射、镜面反射和凹凸贴图。许多最终用户已经将《Spore》引擎中的生物释放出来，使用复杂的渲染和材质来装饰他们的创作，并与其他人分享。（例如，参见附带CD中的“Majestic Dragon”。）更高级的用户创建了已经发布在YouTube上的动画。这些高级用户现在正在教育其他用户，并尝试所有可以导入COLLADA模型的工具。未来，最终用户可能会创造短动画片，更令人兴奋的是不同游戏社区之间的交集。可能已经有《Spore》生物在CryMod中战斗了！

未来
潘多拉的盒子已经打开，无法回头。用户内容在不断增长，对最终用户和专业内容开发者来说，易于使用的资产管道的需求也在增加。3D正在成为主流媒体，就像音频和视频数字形式现在被主流媒体广泛生产和消费一样。预计随着3D的普及，对更好的资产管道的需求也在增长。特别是，原生3D显示电视和显示器[41]、支持高级着色器的移动设备3D加速器[42]、以及在网页浏览器中原生硬件加速3D渲染[43, 44]的消费者可用性也在推动这一进程。
 

References

[1] Subversion. http://subversion.tigris.org/

[2] Perforce. http://www.perforce.com/

[3] Ben Carter.The Game Asset Pipeline. Charles River Media, 2004.

[4] Microsoft. XNA Game Studio 3.1. 2009. http://msdn.microsoft.com/enus/library/bb203887.aspx

[5] Rémi Arnaud. COLLADA for XNA forum discussion and source code. 2008.

https://collada.org/public_forum/viewtopic.php?f=13&t=651and

https://collada.org/public_forum/viewtopic.php?f=13&t=676

[6] W3C. Extensible Markup Language (XML) 1.0, 5th ed. November 26, 2008.

http://www.w3.org/TR/REC-xml/

[7] Sony Computer Entertainment. "COLLADA Refinery".

https://collada.org/mediawiki/index.php/COLLADA_Refinery

[8] "Image file types". http://www.fileinfo.com/filetypes/image

[9] Industrial Light & Magic. OpenEXR. http://www.openexr.com/

[10] Microsoft. "D3DX10 image format". http://msdn.microsoft.com/enus/library/ee416748%28VS.85%29.aspx

[11] Microsoft. "DDS image format". http://msdn.microsoft.com/enus/library/ee418141%28VS.85%29.aspx

[12] Portable Network Graphics. "An Open, Extensible Image Format with Lossless

Compression". http://www.libpng.org/pub/png/ [13] IBM. "Standards and Specs: The Interchange File Format (IFF)". 1985.

http://www.ibm.com/developerworks/power/library/pa-spec16/

[14] Microsoft Windows Bitmap Format.

http://www.fileformat.info/format/bmp/spec/e27073c25463436f8a64fa789c886d9c/view.htm

[15] Adobe. "Open Source Generic Image Library (GIL)".

http://opensource.adobe.com/wiki/display/gil/Generic+Image+Library

[16] Rémi Arnaud and Kathleen Maher."COLLADA: Content Development Using an

Open Standard". Game Developer Magazine, May 2007.

[17] Noel Llopis."Optimizing the Content Pipeline". Game Developer Magazine, April

2004.

[18] GarageGames. "Effortless Art Pipeline using COLLADA".

http://www.garagegames.com/products/torque-3d#feature-pipeline

[19] Rod Green."The All-Important Import Pipeline". Game Developer Magazine, April

2009.

[20] Mark Barnes and Rémi Arnaud. "SIGGRAPH 2004 COLLADA Tech Talk". 2004.

http://www.collada.org/public_forum/files/COLLADASiggraphTechTalkWebQuality.pdf

[21] Sony Computer Entertainment. "COLLADA Approved by Khronos Group as Open Standard". July 29, 2005.

http://www.scei.co.jp/corporate/release/pdf/050729e.pdf

[22] The Khronos Group. "COLLADA—3D Asset Exchange Schema".

http://khronos.org/collada/

[23] Khronos Group. "Khronos Releases COLLADA 1.5.0 Specification with New Automation, Kinematics, and Geospatial Functionality", August 5, 2008.

http://www.khronos.org/news/press/releases/khronos_releases_collada_150_specification_with_new_automation_kinematics_a/ [24] "The X3C XML Schema". 2001. http://www.w3.org/XML/Schema

[25] "Metaballs". 1999.
http://www.siggraph.org/education/materials/HyperGraph/modeling/metaballs/metaballs.h

tm

[26] Rémi Arnaud and Mark Barnes.COLLADA: Sailing the Gulf of 3D Digital Content

Creation. AK Peters, 2006.

[27] David Goldberg."What Every Computer Scientist Should Know About Floating-Point

Arithmetic". 1991. http://docs.sun.com/source/806-3568/ncg_goldberg.html#812

[28] Autodesk. FBX SDK Programmer's Guide, 2009.

http://images.autodesk.com/adsk/files/fbx_sdk_programmers_guide_2010_2.pdf

[29] W3C. "Uniform Resource Identifier (URI): RFC 3986". 2005.

http://www.ietf.org/rfc/rfc3986.txt

[30] The XML Document Object Model from W3C, 2005. http://www.w3.org/DOM/

[31] COLLADA wiki. "COLLADA DOM Portal".

https://collada.org/mediawiki/index.php/Portal:COLLADA_DOM

[32] Khronos Group. "The Khronos Group Announces Significant COLLADA

Momentum at SIGGRAPH 2009". 2009. http://www.blendernation.com/the-khronos

group-announces-significant-collada-momentum-at-Siggraph2009/

[33] Wikipedia. "Simple API for XML".http://en.wikipedia.org/wiki/Simple_API_for_XML

[34] Netallied Systems GmBh. "OpenCOLLADA SDK".http://www.opencollada.org/faq.html 

[35] Feeling Software. COLLADA Support. http://www.feelingsoftware.com/en_US/3D

collada-tools/collada-tools.html

[36] Blender Foundation. Blender. http://www.blender.org/

[37] Google. Google SketchUp. http://sketchup.google.com/

[38] Autodesk. "Autodesk Softimage Mod Tool".

http://usa.autodesk.com/adsk/servlet/pc/item?id=13571257&siteID=123112

[39] Stephen Jacobs."SIGGRAPH: Wright Talks Perception And 'Entertaining The Hive

Mind'". Gamasutra.com, August 6, 2009. http://www.gamasutra.com/php

bin/news_index.php?story=24733

[40] Dan Moskowitz."How To Export Spore Creatures to Maya".

http://forum.spore.com/jforum/posts/list/37155.page

[41] Marguerite Reardon."3D is coming to a living room near you". CES 2009.http://ces.cnet.com/8301-19167_1-10142957-100.html

[42] Apple. "OpenGLES on iPhone OS". http://developer.apple.com/iphone/library/documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/OpenGLESontheiPhone/OpenGLESontheiPhone.html#//apple_ref/doc/uid/TP40008793-CH101-SW1

[43] Google. "O3D API". http://code.google.com/apis/o3d/
 

[44] Khronos Group. "Khronos Details WebGL Initiative to Bring Hardware-Accelerated 3D Graphics to the Internet". http://www.khronos.org/news/press/releases/khronos-webglinitiative-hardware accelerated-3d-graphics-internet/