Unity实现无缝大世界--Houdini
开始之前，如果不知道Houdini是什么，可以先简单搜索一下Houdini是个什么工具。Houdini是做无缝大世界游戏必备的一个工具，他能节省巨大的成本，也是能保证项目前中后期的产出都能保质保量的先决条件。当然，宇宙第一《原神》的确是没用Houdini，纯地编硬怼工作量出来的。一方面，咱肯定没米哈游那么大的魄力，能给到那么多的研发成本，另一方面，原神其实在地编上也暴露出了一些问题。实际上，圈内的小伙伴应该也知道，米哈游也在大力扩建自己的Houdini团队。
如果，你曾经抱怨过美术出东西太慢，你需要Houdini，如果你曾经抱怨过策划老改需求，你需要Houdini，如果你曾幻想过脱离XX美术，自己做资源，但是技能又受限，你需要Houdini.....。Houdini是我遇见一个引擎TA，安利一个的工具，无论程序向还是美术向，建议如果有TA团队，每个人都必须要会Houdini。
Houdini最初是用来做影视的，慢慢被几个大厂发掘用来做游戏，TX，WY据说已经积累四五年了。他最擅长的点实际上是真实的物理模拟，做特效我觉得已经非常无敌了（感觉再过几年，使用Houdini制作特效可能会成为主流）。其次，是程序化建模，地形，这俩功能是做大世界所必须的。Houdini的坑几天几夜也说不完，Houdini的确也是目前来说，可以说是唯一一个功能比较齐全的程序化生成工具。
什么人员能转Houdini？
Houdini职位空缺非常大，并且市场上真正懂用Houdini做游戏的人员基本都在那几家大厂（他们自己培养出来的）。初看觉得，好像美术转Houdini是比较正确的路。但是实际上，这个工具的思维是完完全全的程序员思维。美术人员如果没有程序基础，很难入门，并且就算能使用，也绝不能写出特别好的模块化可复用的功能。这里还是有些许审美的引擎人员，如果人员不够，甚至纯技术的引擎人员也能胜任。经验来看，程序只需学习两周就能独自完成部分功能。美术人员，特别是地编人员，也必须得充分理解这个工具，至少能理解里边的Line，Layer，Mask等概念，可以不需要python，甚至VEX前期都可以不需要。经验来看，一个纯白的美术新手要到能使用，大概需要至少半年时间，需要一直矫正使用习惯到一年左右才能放手。这里给萌新们贴一下如果想入门Houdini的链接，如果有条件，TA团队应该自己总结一份Houdini入门教程。
哪些资源需要使用Houdini
尽可能多地使用Houdini产出资源。至少包括所有非策划属性的地编资源。
Terrain（地形起伏，Layer）
植被，岩石分布。
河流（除了产生河流资源，还需影响Terrain和植被）
道路，桥梁（除了产生道路桥梁资源，还需影响Terrain和植被）
村庄（主城一般需要地编详细设计，野外或者废弃的不让进入的城市也需使用houdini）
。。。。
使用Houdini需要遵循哪些规则
首先，Houdini产出的毛坯资源，一直到游戏运行时使用的资源，这一条流水线上的处理都必须是自动化的，不要有人工的痕迹。比如：从houdini导出到unity的地形，发现某个地方凸起有些高，想压平一下，在unity使用地形工具，进行压平操作。这个是绝对不允许的，因为你这个压平操作是没办法保存下来的，下次重新生成Houdini资源，压平地形的这个操作就丢掉了。那么这个问题该怎么解决呢？首先，最重要的是要保证houdini出来的毛坯资源就要尽量合理，如果出来不合理的地方，应当先调整houdini工具使其正常。实在是不行，也应该把现在houdini产出的毛坯，再经过houdini的精加工，达到预期，比如：缝合工具。如果还是不行，只能在unity处理（houdini几乎能处理99%），那么也要保证是使用unity的脚本来处理的，并且需要把这个代码嵌入到自动化处理资源的流程中去。
再就是对于使用houdini，我这里多说两句。基本用Houdini就跟写代码一样，千万不要图方便，一顿瞎连，可能这也是为啥程序入Houdini比美术好入那么多。写代码的设计模式，在这里都能得到很好的体现。
比如封装。我们开发的功能必须是一个个有输入和输出的模块。如果把所有功能写到一起，可读性变得很差，扩展性也几乎没有，复用性更是不可能。单一职责，装饰等等，这里不做过渡展开，玩过一段时间houdini后，自己就深有体会。还有重构，houdini插件一定要经常迭代和重构，重构节点的重要性跟重构代码一样，一定要留出很大一部分时间来重构节点，不然当量级上来后，就变成，这部分功能能跑就行，千万别动的状态。
使用Houdini大概分为这几种模式
1，C语言式--无尽的houdini提供的简单节点网
我记得我刚学会C语言两个月，在一个Function里写了2W行代码实现了一个文字小游戏。刚学houdini时，我把他当成UE的材质蓝图那样，一顿瞎连，实现简单功能也没啥问题，哈哈。Houdini之所以好入门，也是因为至少能很容易做到这样，跟玩戴森球计划一样就能把功能给做了。普通美术入houdini基本都停留在这个阶段，没法继续深入，这也是我不推荐让美术去写Houdini主要功能的原因（停留在这一阶段的美术建议去玩玩戴森球QAQ）
2，HDA式
hda是Houdini向外输出的一个工具接口文件，通过引擎插件，如Unity的Houdini package，导入到unity，即可在unity进行操作，实际的运转模式是，在unity启动了一个Houdini的线程，然后把unity的操作和输入发送到Houdini，然后在houdini里执行，再把执行结果发送会Unity。这里要吐槽的是，Houdini的Unity插件难用到爆，并且各种bug，有条件的话最好自己维护一份，但是又牵扯到版本升级问题，很麻烦。不过，如果停留在仅仅使用Hda的方式的话，这个倒没有太大的问题。
houdini工具非常强大，并且实用性特别广。hda式的用法，不仅仅在大世界游戏中使用，他更能输出特别多好用的工具给引擎使用人员。如：烘焙河流流向图，生成岩石包边，连线沿途生成水管或是其他物件等。
由于产出的工具众多，后期可能会有几百个hda，并且版本迭代也比较多，管理起来比较麻烦，虽然houdini是提供这方面的支持的。版本管理建议用官方推荐做法，统一命名规则，使用package进行整合。
仅仅使用hda的话，整个大世界流程没有一个地方进行整合，只能在unity开一个场景，然后使用一个hda，生成新的资源，但是大世界流程太过复杂，有的时候需要串联和并行几十个，上百个hda。unity比较好存储的只是生成完的unity资源，输入曲线，线段，mask，中间过程资源等都不太好存储和展示。
3，HDA串联节点网
这个阶段相当于结合了前两步，通过程序开发hda插件，进行有效的封装。然后让地编为每个地块创建一个hip文件（houdini的scene文件）。在这个地块上，地编会根据原画，出一个初始的height起伏，画出各种Mask，河流道路等曲线，各个hda上的参数。总之，hda需要什么，地编美术就配置什么，通常都是一些简单的houdini节点产生的Houdini中间资源（hda参数，mask，layer，point，line）。
类似这种，实际情况比这个复杂多了，一个hda可能会被重复使用很多次。因为存在hda循环依赖的情况，比如河流依赖侵蚀，河流出来后，改变了一些地貌，可能需要进一步侵蚀，才能更加自然，每个HDA上的参数也都不一样。
其实只需做少量优化，这个阶段已经勉强能满足做一个大世界游戏所需的houdini流程。工作室很容易到达，并且将在很长时间一直处于这个阶段，我也是建议大家停留在这一阶段，后面的进阶版，如果人员素质达不到，或者流程不规范反而会出现更大的问题。
这种模式虽然已经把输入和输出通过hda的形式进行解耦了。但是整个串联依然存在很多依赖，后面的结果必须依赖前面结果计算完成。每个hip文件包含的地形尺寸为了编辑方便不宜过小，一般至少得2048，而在功能越来越多越来越复杂后，整个流程从头到尾执行完毕需要很长一段时间，转化到unity资源import更是长得离谱。而houdini的预览功能实在是一言难尽，需要有很好的想象力，才能预料到在unity生成的最终资源大概长什么样。这里非常考验地编美术的想象力，因此他们会不断要求你缩短从houdini编辑到看到在unity长啥样的时间。再者，这个hip文件的节点数大概会到达几百个左右，每个地编的编辑习惯不一样，hip文件的分布千奇百怪，要想阅读他人的编辑文件非常困难，就算地编人员自己在一段时间过后要想修改某项功能都比较麻烦。更不要说，如果出现人员变动，换个人接手，给他擦屁股这种糟心行为。另一方面，美术日常使用的工具，无一例外，全是所见即所得，且他们对于unity的熟悉程度高于houdini，他们还是希望能在unity里，做一些输入，能得到实时反馈。
考虑到大家极有可能都处于这种阶段，可以展开说一下这个阶段的一些优化方法，能大大提升效率。也是通过这些优化方法，慢慢进阶到下一阶段。
多用活用file节点，保存中间的geo文件
houdini号称是自己做了很多缓存机制，当你修改某个节点，他只会更新后边的节点。但是，实际来看，一方面，hip在节点爆炸后，整个节点编辑会变得特别卡，内存占用更不用说（128G内存都扛不住）。另一方面，当你不关注中间的某些功能，可以在一个新的hip空间直接拉一份中间geo数据，甚至可以切成需要的那一块，然后填写数据拉取hda，在极短时间就能导入unity进行预览，快速更改数据，反复迭代，直到调到比较满意后再迁入主流程。
建立模板库
为了功能的完整性，在编写hda的时候会尽量暴露更多的参数。但是，实际操作起来，一个一个配置起来非常麻烦，也涉及到一个填参数到验证的时间成本问题。类似于材质库，我们可以在一个很小的地块比如256上，填写hda参数，进行快速迭代验证功能，然后把参数保存起来。比如：针对草地，雪山，高原等生态工具参数，一级，二级，三级，高速公路等道路工具参数。Houdini的preset是能做这件事的，只是他保存的地方，以及加载都是写死的。我们可以用hscript写一个保存preset和加载preset的工具，直接挂在那个下拉菜单上（houdini提供自定义UI，类似于Unity的MenuItem）。建立模板库，不仅能提升地编美术工作效率，而且能统一规格，比如不同人填写高速公路参数时，可能不一样，那么他们接起来时就会出现问题。如果这个模板库构建得足够合理，后期地编人员，只需要对照原画，把区域，线路这些画好，然后连上hda，设置模板，一气呵成，一天出一个2048都不是问题。
尽量剥离输出资源文件
很多hda输出的资源，没必要一直串着，直到最后一股脑输出到引擎里。最简单的是，各个hda都可能产生的mesh和点云，这部分文件可以直接输出导入到unity，并将其在主输出线路上去掉。但是，这部分文件后边又可能需要，比如河床，后边可能需要通过河床的Mesh，投射出Mask，或者通过一些点云建立Mask区域供其他hda使用。这里，我们有两种办法处理，一个是在hda工具里就要把这些mask处理出来，打上tag，比较通用性的mask可以采用这种办法。还有一种办法是，把这些点云和mesh，保存起来，一方面可以导入到unity生成资源，另一方面也能给后边的hda做输入，在需要用到的hda里，自己从那个地方去取，这里要注意的就是命名规范问题，有一套自己的命名规范后，houdini是可以在字符串通过变量进行拼接的。
尽量脱离主干串行节点
主干串行节点负载过高，我们需要给其减负，有些hda是比较独立的，或者我们能为其独立出来。最常见能独立的情况是，如果我这个hda输出的结果，除了产生unity使用的资源外，无需给其他接下来的hda进行使用，也没有更改串行上的geo，如：height，mask，layer等。即：如果我把处理部分设置成ByPass，除了没有这个hda产出的资源，剩余部分能正确产出资源。更有甚者，如果这个hda输入部分也能是unity的资源的话，都可以把这个hda放入unity场景中，维护一个hip对应的scene场景，直接利用插件所见即所得。
4，Houdini推荐方案
上一模式在得到上面三条的充分优化后，会得到Houdini的推荐方案，也是houdini做影视一直使用的方案。
无限简化缩短每条工作流，解耦工作流上的依赖。这对hda的开发人员有很高的要求，好在开发hda工具的人员都是程序人员，对于这种高要求跟写代码的解耦一样，也不是什么大问题。甚至只需要一个“架构师“，设计每个hda的输入和输出，然后在pdg里进行组装，有点导演，设计师的味道。
把每个功能都模块化，给我什么资源，我就产生对应的资源，有的是直接给unity的，有的是缓存成bgeo的cache资源，各模块并不关心最终在unity长啥样。就跟工厂流水线一样，有的人一直在拧螺丝，有的人一直在把轮子安装上去，他们甚至不知道自己在干什么，每个人都按部就班。唯一一点是，每条流水线的任务都比较轻松，并且能快速迭代知道自己的产出是否正确，优化调整自己的流水线。
ok，等各个模块准备完毕。就像道具组，摄影组，灯光组，服化道组都就绪了，就等导演开拍了。
看到这里，你可能会觉得，你这个不回到最初的模式了么。虽然这个图看着挺像的，但是大部分操作的区域不一样，在这种流程下，大部分工作都是在操作模块内部，这里只是最终的资源输出。而且重点在于各个模块能单独运行，什么意思呢。每个模块，都能根据现有的Input，一直在运算最终结果，无需依赖上一步的数据，大不了就是使用的老数据而已。地编人员，如果编辑道路，只需修改道路的曲线，马上就得到道路在unity里的模型，如果想关注道路影响的生态，那么他可以跳过中间步骤，直接通过新的道路模块产生的数据和老的其他数据，得到新的生态数据，或者只处理道路相关的生态数据。而为了适配这种操作模式，houdini推出了pdg（虽然现在bug很多，也有可能是我用得不对，反正各种问题）
5，终极解决方案
使用Houdini的门槛确实有点高，特别对于美术来讲。培养一个仅仅会使用TA开发好的hda进行连线，都需要一年。现在市面上会Houdini的地编几乎招不到。使用Houdini几年以来，特别是刚开始，几乎每周都能听到能不能脱离Houdini，直接搭建在引擎内，做到让美术无感知，还经常拿一些youtube上那种拖拖拉拉就能马上在引擎内看到效果的视频。其实那些视频里一个是尺寸太小，再一个是功能其实都不算太复杂，要做到这种程度其实还好，实际上我还真花了一些时间做过那种demo，包括自己写分布式线程，联机加速。但是要投入使用还有非常远的路要走。
https://www.zhihu.com/video/1436649720987455488
做得最好的，当然还是Unreal（yyds）。Unreal和Houdini还挺有渊源的，据说他们创始人关系不错，最近Unreal也是收购了Houdini，Houdini跟Unreal的结合要比Unity好用多了，主要是Unity的Houdini插件相比HDK实在是太难受了。Unreal最近几个版本的landscape，功能越来越齐全，相信不久的将来应该是能完全满足大世界地编需求。 很强大，可惜中文学习资料太少[捂脸] md你一提原神lz就不爽了。[语塞] 我是个美术，最近就在连houdini的地形，连的我痛不欲生，但其实还蛮有意思的，自己学了几个月，勉强能照猫画虎的连一个正常的地形出来了。。。。确实主要是教程太少了 youtube上教程挺多的，不会科学上网的话，淘宝上也有不少卖教程的，大多都是从YouTube上转过来的。 嗯，都是英文教程，看的头疼，其实最快的是实战，可惜没什么这类项目的机会。 请问u3d开发也能转吗 可以的，程序转都比较简单。 零几年的完美世界就能做到无缝大世界，怎么感觉现在反而倒回去了？ 美术品质提高了，资源也就复杂了
页:
[1]
2