找回密码
 立即注册
查看: 1053|回复: 14

Unity实现无缝大世界--Houdini

[复制链接]
发表于 2021-12-14 15:02 | 显示全部楼层 |阅读模式
开始之前,如果不知道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,功能越来越齐全,相信不久的将来应该是能完全满足大世界地编需求。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

×
发表于 2021-12-14 15:04 | 显示全部楼层
很强大,可惜中文学习资料太少[捂脸]
发表于 2021-12-14 15:13 | 显示全部楼层
md你一提原神lz就不爽了。[语塞]
发表于 2021-12-14 15:21 | 显示全部楼层
我是个美术,最近就在连houdini的地形,连的我痛不欲生,但其实还蛮有意思的,自己学了几个月,勉强能照猫画虎的连一个正常的地形出来了。。。。确实主要是教程太少了
发表于 2021-12-14 15:31 | 显示全部楼层
youtube上教程挺多的,不会科学上网的话,淘宝上也有不少卖教程的,大多都是从YouTube上转过来的。
发表于 2021-12-14 15:41 | 显示全部楼层
嗯,都是英文教程,看的头疼,其实最快的是实战,可惜没什么这类项目的机会。
发表于 2021-12-14 15:48 | 显示全部楼层
请问u3d开发也能转吗
发表于 2021-12-14 15:57 | 显示全部楼层
可以的,程序转都比较简单。
发表于 2021-12-14 15:58 | 显示全部楼层
零几年的完美世界就能做到无缝大世界,怎么感觉现在反而倒回去了?
发表于 2021-12-14 16:03 | 显示全部楼层
美术品质提高了,资源也就复杂了
懒得打字嘛,点击右侧快捷回复 【右侧内容,后台自定义】
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

小黑屋|手机版|Unity开发者联盟 ( 粤ICP备20003399号 )

GMT+8, 2024-12-23 13:05 , Processed in 0.073914 second(s), 23 queries .

Powered by Discuz! X3.5 Licensed

© 2001-2024 Discuz! Team.

快速回复 返回顶部 返回列表