Oculus研发实战分享：VR开发中的Asset 管道设计
为何管道重要
（映维网 2021年05月14日）这篇由Oculus开发者关系工程师肖恩·伯贡（Sean Burgoon）撰写的博文主要涉及游戏开发的asset管道。尽管所述主题并不特定于虚拟现实，但它对高效制作至关重要。另外，伯贡指出内容都是主观性观点，每个团队的需求都不尽相同，但希望这篇博文能够启发大家，告诉大家关于管道的价值和目的。下面是映维网的具体整理：
1. 什么是Pipeline管道？
解释asset管道的最简单方法是：将其想象为将美术和DCC工具接到游戏中的一系列管道。asset通过所述管道“流入”你的游戏。如果系统设计正确，这种流入将是简单的、可预测的和易于维护的。我们可以将整个管道抽象为下面的图例：
当然，这是一个非常简化的图例。从几乎不存在的管道（可能是网络驱动器的文件夹结构），到由专业管道工程师团队建造和维护，并由世界级动画和特效工作室使用的复杂管道，管道的复杂性各不相同。通常的游戏管道介于两者之间，而且管道的复杂性通常与美术团队和工程团队的规模直接相关。什么样的管道复杂度适合你？我们稍后再讨论。
2. 为什么说管道重要？
游戏开发是一次平衡产品需求与可用资源的持续斗争。它们很少能自然地保持平衡。事实上，可以肯定地说，我们在开发过程中都会感到资源不足。有鉴于此，花时间在管道开发可能会让人觉得违反直觉。将技术、美术或工程资源（通常都是供不应求的）投入到客户永远看不到的东西，你显然会认为有风险。同样地，如果你可以开发新的功能并在董事会评审中给投资者和/或高管留下深刻印象，继续开发管道似乎会站不住脚。
尽管上面所述都是事实，但管道开发依然极其重要。这是整个开发过程赖以生存的基础，为开发适当范围的管道所花费的时间将在以后通过提高效率、减少调试和返工时间来实现回报。
举一个具体的例子，一位独立美术负责你的VR地牢游戏。这位美术的水平和经验都非常出色，能够在所有的DCC应用程序之间无缝跳跃，并创造出令人眼花缭乱的盔甲设置和恐怖可怕的敌人怪兽。美术花了最后一天时间来润色作品。低多边形模型搞掂，纹理烘焙完成，所以问题是，你什么时候能在游戏中看到这个asset呢？好吧，根据你的管道状况，几乎是任何答案都行。
如果管道依赖于大量的美术手动干预，这可能会导致所述asset在“最后一英里”花费数天，甚至更多时间，因为美术需要尝试手动创建所有最终输出文件。美术需要确保所有文件都是正确的格式，把它们放在正确的地方，并协调所有的依赖关系。更糟糕的是，一旦asset放到游戏里面，它的外观或表现可能会有所不同。着色不同，颜色空间不同，角色艺术和动画之间的错误交流……所有这些潜在的缺陷都会导致返工和延迟，甚至会在短时间内吞噬本来是最为充分的时间表。一个好的asset管道可以提前将这种陷阱降到最低，并且当不可避免地需要返工时，其可以减少改动和快速部署的摩擦。在整个制作过程中，即使每项asset的收益微乎其微，优秀管道的潜在影响都会变得更加明显。
另一个示例是，一款内容即将发行。一路走来克服了众多波折，而成功就在眼前，然后突然之间，你在其中一个目标平台发现了一个性能问题。在对代码进行了详尽的系统性修改之后，不可避免的现实将会袭击你。你必须对角色艺术做一个优化通道，而这将影响角色几何，材质和rig。
没有什么能使这种大规模的后期工作变得容易，但一个坚实、高效的自动化管道至少可以使其易于管理。在这个场景中，从前面示例中节省的时间将能加倍。或者，花费30分钟到1小时的小烦恼，但从来不是什么“大不了”的事问题都会突然间大大减少。另外，随着美术开始疲劳，错误更容易产生，而且很难找到。把越多的工作转移到管道，你的团队就越能集中精力在手头的开发挑战。
3. 管道组成
有几乎无限多的方法可以用来分解管道，但对于本次讨论，我们将把理论管道分解为三个主要缓解：asset引入、asset管理、以及工具/环境。我们可以很容易地按规程（角色艺术、动画、FX等）将管道拆分，并且这在设计管道时是一个有用的练习。但对于高阶讨论，这三者提供了一个有用的框架。
3.1 asset引入
大多数简单的管道主要涉及asset引入，这意味着从DCC应用程序中获取asset并将其引入游戏中。这是必要的，因为美术存储的源格式通常不是你想要直接拉到引擎中的格式。即使引擎可以直接导入DCC的本机文件格式（例如Unity可以直接导入Maya的ma文件），你通常都不希望在没有某种引入处理的情况下这样做。源文件需要组织成能够简化美术的工作流程。文件中经常会存储额外的对象供参考，以及在创建asset期间非常宝贵的复杂节点历史记录和其他数据，但如果在导入之前未清除，它们可能会变成无用的或潜在的错误源。
所以在我们的简单管道中，你可能会有某种导出插件、脚本或两者的组合。最简单的形式是美术选择要包含的对象，单击导出按钮，然后选择保存导出文件的位置以便游戏引擎获取。听起来不错，但这个简单的管道有着众多潜在的故障点。以下是在这个阶段可能出现错误的简短列表：
- asset保存在错误的位置
- asset保存时覆盖另一asset
- 未选择对象，或选择了错误的对象
- 导出的源文件版本错误
- 忘记保存并签入这一版本的源文件
- 导出前，未删除对象的历史记录
无数美术和技术美术的时间都浪费在这种可以理解的人类错误上，但它们本可避免。上述例子都不应该完全依靠人为干预。每个asset都应该有一个确定性导出位置，它将被导出到哪个位置（如果没有，这本身就已经是一个问题）。
即使在单个源文件中存储多个asset（有时可能非常有用），你都没有理由不在文件中定义与确定性导出位置相对应的导出组，同时导出脚本或插件没有理由无法检查源代码管理软件，以确保美术使用的是最新版本。同样重要的是，如果没有签入，则予以警告提醒（若不能确定它来自哪个源文件和版本，导出的asset都不应出现在游戏中，因为你只需在导出时进行简单的编码）。最后，应自动处理任何asset（删除历史记录、检查无效几何图形或预算外材质计数等），并且应在导出之前以编程方式检测常见错误。关键是尽量减少美术的干预。越接近一个能够自动验证、清理、导出、命名和版本化asset的绿色按钮，对你就越好，对美术就越好，对进度就越好。
3.2 管理
除了引入asset的任务外，asset管理同样重要。在这种情况下，asset管理不仅仅是一个文件结构和命名约定。asset之间的关键依赖关系几乎总是需要管理。即使是简单的角色网格都有依赖的纹理和材质。构建和管理这种依赖关系通常是bug和浪费时间的另一个来源，但同时是一个高级管道提供帮助的绝佳机会。下面我们来看看更新角色网格的常见示例。
更新网格看起来非常简单，但它涉及其他几个规程和资源。假设我们已经有了一个基本的管道，它处理源文件的版本控制，以及导出文件的命名和放置。现在我们来看看可能的依赖关系。首先，可能有一些纹理和材质需要更新。这些纹理可能存在于PSD文件中的图层组中，并需要拆分为几个简单的单层位图文件。UV同样可能已经改变，并需要新的烘焙，或者某种程度的美术干预。新UV同时可能会影响利用角色网格和UV的视觉效果，所以需要通知FX美术，以便其重新检查。你还可能需要更新动画rig并通知动画师，以便其能够确保依然能正确读取新网格的内容。
我描述的大部分内容都可以通过合适的管道设计来处理。在最简单的层次上，维护一个在特定asset更新时需要通知的利益相关asset列表应该要简单直接，这可以节省大量的时间和麻烦。如果rigging系统为自动（绝对应该是），你可以重建rig并渲染一系列运动测试，通过电子邮件发送给角色负责人和动画负责人进行视觉验证，并通知使用旧rig的动画师。你甚至可以在导出过程中直接将它们与以前版本进行比较，从而检查某些更改（如UVs），或者可以开发一个更复杂的系统以散列代表asset不同方面的数据，从而在DCC中直接进行精细对比。这个主题可以另起一篇文章介绍，但核心观点是尽量避免用户干预，并且对于需要用户关注的地方，尽量帮助引开这种注意力。计算机擅长于无聊的管理工作，所以最好交给它们。
3.3 工具和环境
这是管道设计中最被忽视的地方之一，但同时可能是非常重要的地方之一。”环境”在这种背景下并不意味着关卡美术。这是指用户工作站的“环境”，包括DCC软件、实用程序、插件以及脚本。对于小规模环境，许多开发者都会手动处理。美术或IT工作者应该自己更新软件，而插件和脚本通常存储在网络，以便用户根据需要访问和更新。尽管这没什么问题，但它可能会导致错误和调试困难，并创建另一个潜在的人为错误点。
更好的解决方案是将开发者环境包含在管道设计中。最简单的方法是将插件、脚本和简单工具作为管道的一部分。当用户运行DCC应用程序时，你可以启动一个脚本，以确保所有相关的脚本和插件都是最新的。你同时可以运行一个nightly chron来做同样的事情。如果愿意，你甚至可以为DCC软件亲自执行所述操作。例如，确保所有美术都使用相同版本的Maya。然而，由于DCC许可证管理器和Windows的其他打包挑战，这可能比简单地同步插件和脚本更具技术挑战，对于中小型团队来说可能不实用。
除了确保及时更新和减少兼容性问题外，这种系统还将帮助技术团队精确地再现美术的调试环境，而这非常有益。这样的系统允许你定义组，以及每个组的软件和工具的版本。这样，你可以定义一个测试组（或选择进入测试组），在工作中使用几天之后才发布更新。
无论是简单还是高级，管道设计的目标基本上与以asset为中心的领域相同：尽量减少人为干预。如果要确保美术打开了正确版本的文件，没有什么理由不同样地确保其使用正确的工具，并以正确的软件版本打开所述文件。
4. 总结
我们希望这篇文章能够告诉你管道是什么，以及为何它重要。下一个逻辑问题是，什么样的管道适合你的团队？
遗憾的是，没有简单的方法来回答这个问题。这个等式中包含大量重要的输入，从项目规模、进度、技术团队规模、美术团队规模、是否有多个项目可以共享一个管道，以及从哪种管道（如果有的话）开始等等。如果你不是一个技术美术，但你已经在考虑管道和它可以为你做什么，这将是重要的第一步。
我们建议在你的开发过程中注意摩擦，然后问问你自己，这种摩擦是不是因为一个人在做一个本可轻松由计算机处理的动作。如果答案是肯定的，你将有机会设计一个合适的管道。但要小心，正如太少的管道可能造成大量的人为错误，太多的管道则可能需要大量的技术精力。平衡是关键，你对管道的理解越透彻，你就能够更好地就根据具体项目和团队设计关键的管道。
