程序化生成建筑细节介绍(UE4和Houdini)

作者:澳门新葡8455最新网站   来源:http://www.shktv988.com    栏目: 澳门新葡亰登入    日期:2019-10-10

  1,出于公心:我今日发了一段ue4&houdini的求职demo,在qq群中打了广告,发现很多人对procedural流程以及houdini软件,不太了解.故而想写点东西介绍一下我这几年对procedural流程的看法与学习心得。

  2,出于私心: 这篇文章也是算是一种求职方法,毕竟我搜遍了各大招聘网站也没找到需要houdini程序生成的职位,若有hr看到请留个邮箱,我好投简历。

  求职:岗位不限,地方不限,场景相关,类型不限.只求打杂倒水(真实述求,未有玩笑成分)。

  游戏资产(个人从某处学到的词,是模型,uv,纹理,lod,碰撞等游戏资源的统称,拿来使用,请诸位理解)

  Procedural的应用确实取决于项目需求,例如蜘蛛侠中的曼哈顿场景便是houdini,便极大的提高了制作效率,有些人认为只有大场景才能用的上houdini,这是高估了Procedural的威力,Procedural流程并不是一个程序解决游戏开发中的所有问题.Procedural的重点在于设置一些小插件,优化工作流程,细节设计上采用procedural流程上更能发挥出houdini的优势。

  例如,要给山体设置阶梯,传统方法是手动摆放,若遇到山体修改,则需要手动修正阶梯角度,,且很难避免因为模型角度变化而导致的前后连接问题。而houdini可以实时调节模型与山体的关系(如下图)。毕竟修改返工是设计师的痛苦根源,而houdini在一定程度能帮助大家减少修改的次数,降低痛苦。熟悉houdini者设置此类HDA不会超过20分钟,投入的时间成本很低。

  常见观点二:procedural生成是一次性的,定制化的东西,每次还要专门diy一个程序。

  蜘蛛侠的曼哈顿场景就是houdini生成的,确实是一次性的,定制化的,别人游戏开发商用不到,或者自己不再做以曼哈顿为背景的游戏也用不到。

  但实际整个hda(ue4,unity,maya等软件所能识别的houdini文件格式)工程是由控制街道,楼梯,店铺,贴画,垃圾桶摆放的小型hda拼装而成,这些hda是高度模块化,技术点都是通用的。且小型hda内部并非全是代码,内部结构如下图所示(头号玩家-叠楼区video/av52),其内部的核心是由一些普通的节点以及包含vex代码的pointwrangle构成(vex是houdini的内置语言)。

  而这5个pointwrangle中vex只是同一段代码的不同变体,只是对输入的点进行处理,高度模块化,这5个pointwrangle中的代码可应用于任何高层住宅或者商业大楼,而重庆-洪崖洞中的横向排布hda,可用于任何的街道类项目。技术通用,需要修改的只是输入模型。(重庆-洪崖洞/video/av52,约54秒)

  有人认为设计就应该人手工做出来的,程序生成的没有灵魂,缺少匠人精神,这是一种狭隘的看法。

  优秀的设计也是将现有元素按照美学规则进行拼贴与重构。而规则是可以提炼的,可以用houdini定义设计规则,曝露出足够的参数,保证设计的可修改性。最大限度的在时间与效果谋取平衡。Houdini是一个工具,procedural生成是一种方法,为的是提高工作效率。

  1,质量取决于游戏资产模组的制作水准,houdini不是游戏资产的生成者,只是游戏资产的搬运工,将完整的模组放在合适的位置上。

  2,此言论属于偏见,恰恰是低质量开发的游戏才不会用程序生成,procedural生成是成本与效果平衡的产物。而低质量开发的游戏只有妥协,没有平衡。

  一:何时采用procedural生成,用程序修改实际到处是需要具体问题具体分析的情况。

  若是开发现代写实场景,或者科幻类,赛破朋克类的游戏内容,可以采用procedural流程提高迭代效率,丰富游戏内容。若是手游,棋牌,抽卡或者室内演出型游戏则不需要。

  类似于maya,既可建模,uv,亦可动画,破碎。此类方法是将houdini作为资产生成的软件,作用等同于maya,c4d,blender等软件建模后导入游戏引擎。

  houdini可以在内部生成资产,不依赖第三方DCC软件(如模型:maya。3dmax。c4d,blender,modo)。所有的建模,uv,烘焙,纹理,lod,动画等都在houdini完成。(教程连接:

  此种方法是改变模型的拓扑结构,较为适合影视流程,或游戏领域中的模块化生成(模块化:若游戏中需要10km的高速公路,只需制作一小段路面,然后不断复制即可)。

  1,若想在游戏引擎中实时修改:请导出hda格式,uv,烘焙需要在houdini内部完成,碰撞给予模型一个字符串属性即可(如下图中的命名约定表)。纹理可直接调用引擎中的已有纹理(游戏引擎想要识别hda格式,需安装houdini engine插件,ue4/unity文档链接:docs/hengine,ue4,unity的细节有些许不同,请细细查阅)。

  2,若不想在引擎中实时修改:请导出fbx,obj格式,剩下与常规流程相同,即uv,烘培可在第三方软件中完成(个人建议:uv,lod可在houdini内直接完成,速度贼快,用过都说好)。

  只是把houdini当作一个资产的搬运工,不破坏拓扑结构。此种方法是procedural的核心。

  举个例子,大家一定知道《我的世界》的玩法,通过小方格就可以组合出千变万化的造型。小方格就是模块化单元。那么一座城市也可以模块化,比如墙,窗户,道路,树木,红绿灯等等。再通过程序就可以得到一座城市,且房子的样式还是多样化的,这就是Procedural的强大之处。

  优点 : 高效控制drawcall的数量与大小,高度模块化,在输入----处理----输出的数据处理中,只定义处理的方式,不同的输入,都会得到一个明确且可重复,可动态调整的输出。

  1, packed实例,将输入的模型打包成一个实例,游戏引擎可以自动识别(注:unity很早就有了动态实例,ue4在4.22才有)。

  2,点云实例,将houdini定义的规则封装在一个个的点中,游戏引擎可以直接读取。如下图(若图不动,请移步video/av52,约在54-59秒)。

  1,packed实例通过hda导出后ue4,unity,maya,3dmax,c4d软件都可识别,点云实例不可通用,因为点云实例中要包含的实例属性的名字不一样,要导出为不同的版本(注:不同版本的修改,只需一秒钟,把ue4版本中实例属性的名字替换为unity即可完成unity版本的制作)。

  2,packed实例可在houdini中显示模型,易于观察,点云实例只有一个个点,只能引擎中看到效果,个人建议先用packe方式制作,最后转为点云实例。

  3,点云实例的优点在于可以更有效的删除模型重叠部分,例如重庆-洪崖洞项目中相邻建筑之间紧密相连,便可以剔除掉重叠的模型。(如下图)

  1,完全程序化生成,不做修改。如Roguelike类游戏,全自动一键生成,依靠某一全局参数控制场景的整体变化;

  3,采用houdini的规则定义方式,进行procedural生成。暴露内部参数,若是不加修改便是第一种完全程序化生成 。也可以单独设每一个参数,例如位置,角度,缩放等,达到传统方法中的完全手动的效果。在完全程序化与完全手动中各取优点,直接bake成actor再修改的区别在于bake之后就变为普通actor无法自动适应定义的规则。

  如下图所示若在ue4烘焙成actor,再进行调整的话,建筑之间的电线便不会自动跟随物体变化(如无法查看动图,请移步视频链接video/av52,约在4-9秒)。

  2,设置你要调整几个建筑的细节,例如我准备调节2号建筑这一个建筑的旋转角度,在prop_num中输入1(代表修改总数为1);

  3,将要修改的建筑的标号输入point_id,如要修改2号建筑,即在point_id输入2,即可对2号建筑的旋转,位置等所有属性进行修改。

  1,procedural流程不是一劳永逸,目的加快迭代速度,减少人力成本;

  3,procedural生成是成本与效果平衡的产物,采用与否请具体问题具体分析;

  4,houdini是一个工具,procedural生成是一种方法,为的是提高工作效率。

上一篇:YPE htmlhtml lang=enhead data-       下一篇:本溪中小型天然气压缩机价格自产自销