程序生成建筑细节介绍(ue4&houdini)

2019-05-11 本文已影响0人赵某人_1bef

全文3200字,版本V1,写于2019-05-10夜,可直接从正文开始看,欢迎转载(修改请不要删除前言)

前言:

注:文章为第一版,记为V1,以后会慢慢修改,更新记为V2,V3等.以后文章也会按照这一格式

文章包含词汇:

HDA 格式(全称 houdini digital asset ,是ue4,unity,maya等软件所能识别的houdini文件格式)

VEX(houdini的内置编程语言,类似于c/c++,houdini也支持python,但效率不如vex)

PDG(全称: Procedural Dependency Graph .houdini17.5新出的功能,可以高效,快速的生成不同类型的资产,官方连接:https://www.sidefx.com/products/pdg/)

游戏资产(个人从某处学到的词,是模型,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内部并非全是代码,内部结构如下图所示(头号玩家-叠楼区https://www.bilibili.com/video/av52010921),其内部的核心是由一些普通的节点以及包含vex代码的pointwrangle构成(vex是houdini的内置语言),而这5个pointwrangle中vex只是同一段代码的不同变体,只是对输入的点进行处理,高度模块化,这5个pointwrangle中的代码可应用于任何高层住宅或者商业大楼,而重庆-洪崖洞中的横向排布hda,可用于任何的街道类项目.技术通用,需要修改的只是输入模型.(重庆-洪崖洞(https://www.bilibili.com/video/av52010921,约54秒))

头号玩家-叠楼区主体建筑的内部结构

常见观点三:只有不需要设计的次要场景才会用程序化生成

有人认为设计就应该人手工做出来的,程序生成的没有灵魂,缺少匠人精神,这是一种狭隘的看法,优秀的设计也是将现有元素按照美学规则进行拼贴与重构,而规则是可以提炼的,,可以用houdini定义设计规则,曝露出足够的参数,保证设计的可修改性.最大限度的在时间与效果谋取平衡,Houdini是一个工具,procedural生成是一种方法,为的是提高工作效率,

常见观点四:往往只有低质量开发的游戏才会用到程序生成

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

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

个人观点:

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

资产类型:

1,游戏主角不需要,但1000个配角需要

2,一栋建筑不需要,但制作城市需要

游戏类型:

若是开发现代写实场景,或者科幻类,赛破朋克类的游戏内容,可以采用procedural流程提高迭代效率,丰富游戏内容

若是手游,棋牌,抽卡或者室内演出型游戏则不需要.

二 houdini在游戏领域的两种使用形式

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

houdini可以在内部生成资产,不依赖第三方DCC软件(如模型:maya,3dmax,c4d,blender,modo.纹理:sp,sd),所有的建模,uv,烘焙,纹理,lod,动画等都在houdini完成,(效率较低,不推荐)

如下图所示,便是houdini内部建模,不依赖外部资产导入(教程连接:https://www.youtube.com/watch?v=fAmjnJAuvp0)

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

优点:达到对模型结构,uv的完全控制,实时调整,完全程序生成.

缺点:若是在较大规模的游戏场景中采用此种方法,在游戏引擎中无法高效控制drawcall的数量.且修改效率过低.

综合优缺点:一些需求种类很多的单体物体可以采用此类方法,配合houdini17.5的pdg流程可以快速生成同一类型的资产变体,然后导出模型到游戏引擎.例如书本,罐子,箱子,武器,饰品等小型物体(pdg相关连接:https://www.youtube.com/watch?v=lL_jUZtaF1k).

注意事项:

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

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

改变拓扑结构

碰撞的命名约定

mesh与碰撞体(上图共有11种类型,任君选择)

二规则的定义者

只是把houdini当作一个资产的搬运工,不破坏拓扑结构.此种方法的口号是: houdini 从不生产水,只是大自然的搬运工,

头号玩家-叠楼区模组

重庆_洪崖洞的所有模组

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

此类方法有两个不同的实现方式

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

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

三两种方式经验总结:

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

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

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

三程序化与手动摆放的平衡

场景关卡生成大致可分为3个方式

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

2 完全手动摆放与修正,传统制作方法

3 采用houdini的规则定义方式,进行procedural生成,暴露内部参数,若是不加修改便是第一种完全程序化生成 ,也可以单独设每一个参数,例如位置,角度,缩放等,达到传统方法中的完全手动的效果.在完全程序化与完全手动中各取优点.直接bake成actor再修改的区别在于bake之后就变为普通actor 无法自动适应定义的规则.如下图所示若在ue4烘焙成actor,再进行调整的话,建筑之间的电线便不会自动跟随物体变化(如无法查看动图,请移步视频链接https://www.bilibili.com/video/av52010921,约在4-9秒)