Houdini与游戏项目的结合方式

Houdini与游戏

Houdini本身是一个工具，就和Maya、Blender一样，目标是产出美术资源。

但是它却是一个比较特殊的工具。明显的的特点是程序化。

这种程序化的思维使其和游戏引擎有了更多交互方式的可能，同时官方也提供了相应的机制。

结合方式1：外部通用格式文件

即：Houdini将编辑的结果导出成一些通用格式的文件，如fbx，png等等。而这些文件可以被导入到UE4，Unity这种游戏引擎中。

在这种方式下，Houdini在资源流水线上的角色无异于Maya，blender这些DCC工具。唯一不同的是，Houdini资源制作方式是“程序化”的。

结合方式2：编辑时期HoudiniEngine

即：先用Houdini编辑器制作.hda文件。hda(Houdini Digital Asset)，从名字就可以看出：

1. 它是Houdini专用的资源，并非是通用的。
2. 它是“数字”资产，这里的意思是它是“活”的：它暴露了一些参数，通过调整参数可以动态地得到不同的结果。

之后，UE4或Unity等游戏引擎需要安装插件：HoudiniEngine。这个插件是Houdini的公司“sidefx”所制作的 ，主要职责是转变Houdini数据为游戏引擎自身的资源。这个插件本身会在后台启动一个Houdini进程，用来支持Houdini数据。

此种方式和【结合方式1：外部通用格式文件】的根本性不同在于：在游戏引擎编辑器内，也运行了一个Houdini进程来操纵Houdini数据，这和在Houdini编辑器内操纵节点等价（只不过界面不一样）。这带来的好处是：迭代更快，例如：

• 假设你用Houdini制作了一个模型，如果用的是【结合方式1：外部通用格式文件】，则需要导出成fbx。但是导入游戏引擎后发现之前制作时，一个参数改变之后可能会更好。那么此时就需要再回到Houdini制作并再次导出成fbx，再来一遍流程。但假如用的是【结合方式2：编辑时期HoudiniEngine】，那么就可以随时改变参数，来即时观察结果。

当然，这种方式对技术要求更高。最基础的：需要操纵HoudiniEngine插件，更进阶的就需要修改插件代码，来创建属于自己项目的定制化制作流水线了。对于后者，甚至可能不需要让美术同学开启Houdini编辑器，直接在游戏引擎内来制作资源：

结合方式3：运行时期HoudiniEngine（理想）

事先说明的是，这种方式我并未验证，也不知道目前是否存在游戏是这样使用Houdini的（更大可能是不存在）。

这种方式和【结合方式2：编辑时期HoudiniEngine】一样的是：都需要HoudiniEngine的支持。不同的是：【2】是仅在编辑时期来使用HoudiniEngine，编辑结束后它便成为了游戏引擎的资源，脱离了对Houdini的依赖。而【3】希望能在游戏运行时也运行Houdini，这样便拥有了游戏运行时动态创造程序化资源的能力，例如：

• 假设你制作了一个“随机石头生成器”，在【结合方式2：编辑时期HoudiniEngine】中，你可以不断修改参数，并实时观察效果，最终选择了5块石头，将他们作为游戏的资源。但是如果是在【结合方式3：运行时期HoudiniEngine】中，你就可以在游戏运行时，动态生成无限的石头放在场景中，玩家再也不会发现有任何两块石头是相同的了！

当然，这只是理想状态，理论上可行，但实际实行起来恐怕面临很多问题吧。我能想到的一个重要问题就是：Houdini本身并不轻巧，而一个游戏通常只是用到了冰山一角的功能，那么将它放到游戏程序中真的是值得的吗？对于那些真的需要动态创建随机资源的游戏（比如roguelike），是否写专用的代码是更好的选择呢？