我们使用 Blender 和 Godot 的工作流程

Blender Studio 追求游戏项目的核心目标之一是验证和熟悉开源游戏开发的现状。 由于我们决定使用 Godot 作为引擎（显然 Blender 作为我们的 DCC），我们必须建立一个围绕这两个工具构建的管道，并允许一个 8 人的团队处理游戏文件。 在本文中，我想概述一下我们得出的结论。

Blender at the Center

从这个项目开始，我们心中就有一个梦想的管道。 一个挑战是，我们的工作室是为电影制作而设立的。我们的工具、基础设施和团队的技能都针对这一点。我们越能坚持我们所知道的就越好。 理想情况下，我们将能够尽可能多地利用 Blender，并拥有一个管道，允许我们在 Blender 中创建资产、场景组装、动画库和基本的游戏特定定义（如碰撞）。Godot 只会真正被用来验证游戏中的样子（当然，除了实现整个游戏逻辑）。 为此，我们需要能够在 Blender 中预览我们的资产，就像它们在游戏中的外观一样。由于我们大部分时间都采用了标准的 PBR 工作流程，因此开箱即用的效果非常好。

这种以 DCC 为中心的工作流程在游戏开发中不一定常见。但对我们来说，这是正确的方法，使我们能够发挥自己的优势。

glTF 作为容器

为了使我们的资产在游戏文件中可用，我们使用 glTF 作为交换格式。这对我们来说是一个显而易见的选择，原因有很多：

• Blender 和 Godot 中都集成了可靠的原生支持（材质、动画、自定义网格数据）

• glTF 正在积极进行开发，我们已经支持我们需要的许多功能

• 它的高度可扩展性意味着我们可以在此基础上构建自己的功能

Godot 也可以选择直接导入文件，但我们决定不使用它。直接导入我们的资源意味着没有明确的导出/发布步骤。因此，工作文件和游戏资源文件之间不会有区别。这通常是可行的，但是当与多人协作时，我们发现明确将更改推送到生产环境中很有用。 由于 Godot 的这个功能在内部使用 glTF 作为交换格式，因此它是一个更好的解决方案，可以使该导出步骤成为我们管道的明确部分，并让我们对该过程有更多的控制权。.blend

集合导出

自动化导出管道的一个重要方面是使用 Blender 的导出集合功能。这意味着我们可以设置专用集合来导出多个单独的资源，而不是单独导出文件。因此，可以提前设置所有资源的导出设置，并且可以一次单独导出文件中的所有资源。 它还允许在文件中有各种附加数据以供参考，以便在不污染导出数据的情况下工作。.blend

同一 .blend 文件中许多资产的集合导出器设置的屏幕截图。

棘手的部分只是我们如何在彼此内部进行资源嵌套的问题，而不会冗余地导出嵌套资源。这就是一些额外的自定义代码的用武之地。

用于交换的自定义代码

为了给我们提供必要的控制权，使美术团队能够轻松地将资产运送到 Godot 并从 Blender 迭代它们，我们在两端都有自定义代码。 有一个 Blender 扩展，它可以处理设置和执行资产的导出，同时提供有关它的所有必要信息。还有一个 Godot 插件，可以确保在每次导入时，提供的数据都用于正确重新创建资产并生成所需的游戏数据。

你可以在本文末尾找到该代码的（非常）初步版本，这对我们来说已经足够好了，但不是一个完全充实的工具。

资产分离

设置的一个核心原则是，美术师将导出到游戏文件中的每个资产都只包含其自己的即时数据。如果另一个资产嵌套在里面（例如集合实例化），它应该被替换为引用，并且应该在导入时在 Godot 中重新创建该引用。

这样，可以在一个文件中定义树资源及其部分（每个分支可能有一个资源集合），并且可以在单独的设置文件中定义树的实例化和放置。集合、树和分支都是单独的资产，而每个资产的数据只导出一次，并且文件之间存在的引用在 Godot 中的导出文件之间重新创建。在这种情况下，set 资源实际上只包含其他资源的引用和转换。