Houdini专栏前言

其实本来是不准备在自己的个人博客中讨论Houdini的，因为公司的项目中用到了Houdini，我需要避嫌。但转念一想，Houdini本身也只是个工具而已，虽然我不能讨论和公司项目相关的内容，但是Houdini本身的基础概念，或者用它来做些与公司项目无关的小东西，我觉得还是可以的。

因此我决定开一个Houdini专栏，内容包含Houdini一些基础概念，以及用它做一些有趣的小东西。博客对我而言有备忘的作用，此外或许也能给在研究Houdini的同学提供参考资料。
这篇博客，先讨论一个最关键的问题：Houdini是如何与游戏项目结合的

结合方式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），是否写专用的代码是更好的选择呢？