Havok物理引擎与Unity3D游戏的结合

背景

在重度手游的研发过程当中,游戏中的车辆模拟,场景互动,特效展示等功能很多时候需要物理引擎的介入,以提供丰富的交互体验。目前3D手游的开发主要工具是使用Unity3D引擎,于是,如何在Unity3D的开发过程中结合入物理功能变一个需要仔细考虑的问题。

我们考察的2种物理效果实现方案:Unity3D物理引擎和Havok物理引擎。

Unity3d物理引擎介绍

Unity3d在内部集成了PhysX物理引擎,为其提供了物理模拟能力。

Physx是目前使用最为广泛的物理引擎,PhysX目前由Nvidia公司开发并维护,特点是免费且带N卡的GPU物理计算加速功能(1)。

PhysX被很多游戏大作所采用,使用PhysX制作的游戏:
 


4.X版本的Unity3D集成的是2.8.3的PhysX,该版本较为老旧。在Unity5中将集成PhysX3.3,较2.8.3版本在功能和性能上有较大幅的提升,但是目前unity5并不是非常稳定。

Havok物理引擎介绍

Havok物理引擎是由Havok公司开发的老牌物理引擎,与PhysX不同,Havok专注于CPU端+多线程模拟方案,并且与PhysX的强大市场推广以及免费策略不同,Havok授权很严格,而且基本不提供试用版本下载(2)。

使用Havok引擎的游戏大作在数量上与使用PhysX的不相上下,而且很多令人印象深刻:
 


Unity3D物理与Havok物理的功能对比

Unity3D集成的PhysX物理功能:

Unity3D通过其提供的各种Component访问PhysX的物理功能,打开菜单栏中的Component->Physics便可以看到各种组件:
 


其中,

Rigidbody提供了刚体的访问接口。

各种XXXCollider提供了3种碰撞包围体方案(Primitive,Mesh,Terrain)。

WheelCollider组件提供了车轮模拟方案。

XXXCloth组件提供了布料模拟方案。

XXXJoint组件提供了关节与连接点模拟方案。

PhysicsMaterial资源类型提供了表面物理材质描述功能。

在Unity3D中每一种物理组件都有对应的编辑界面,且即拖即用,非常方便。
 


PhysX引擎目前已经涵盖各个平台,且跨平台特性已经融入Unity3D的跨平台机制中,用户无需再关注跨平台开发。

由于PhysX与Unity3D的深度结合以及Unity3D的闭源特性,修改PhysX的底层模拟机制基本不可能。

Havok物理引擎功能介绍:

Havok物理引擎以C++库的形式,通过组件式的方式,提供了丰富的物理功能。包括了:
 

  • Rigidbody刚体模拟。
  • 5种碰撞包围体模拟方案(Primitive,Convex,Mesh,Compount,Terrain)
  • 完整的VehicleKit车辆模拟方案。
  • HavokCloth不了模拟方案。
  • Constraint关节与连接点模拟方案。
  • HKX物理资源数据描述格式以及对应序列化与反序列化接口。
  • HavokDestruction破碎模拟方案。


Havok并没有开发官方的Unity3D结合插件,市面上也没有第三方的结合插件可以使用,需要自行开发,有一定的开发成本。

Havok具备称述的跨平台能力,但是由于没有结合入Unity3D的跨平台机制,在发布到多平台上需要一点额外的工作量。

Havok在获得授权之后,用户可以修改与定制各个层级的物理功能。

Unity和Havok主要物理功能对比
 


结论:

游戏中简单的物理效果展示可以使用生的PhysX引擎,但是如果需要扩展功能或者订制细腻的物理效果,可以考虑其它物理方案。

Unity与Havok物理引擎的结合

既然有结合其它物理方案的需求,那么接下来我们便讨论一下结合的方案。

结合基本原理

要实现Havok与Unity3D相结合,那么两个系统之间的交互通信机制便是实现的关键。Unity3D提供的二次开发平台是Mono,并没有提供NativeCode级别的接口,而Havok是完全以C++编写的Native实现。所幸,Mono为IL提供了跨平台的NativeCode交互机制。

在Win和Linux(Android)平台上,Mono提供了以dll和so为基础的动态链接库交互C++代码形式,而在IOS平台上则是以AOT为基础的静态链接库交互形式,而这种混合编程的方法,便是让Unity3D与Havok交互的基础。
 


如图:结合的主要思路就是,Havok作为一个子系统,以插件的形式和Unity3D结合,并通过Mono进行交互。

结合的具体过程:两个系统的更新流程

由于Unity3D依然负责整个游戏的主更新流程,那么便需要将Havok的更新整合入Unity3D的流程中。一个比较合理的更新流程应该是逻辑对象先更新,然后将物理参数传入物理引擎,逻辑对象更新完成之后,物理引擎开始进行物理模拟,物理引擎返回模拟结果,Unity3D使用模拟结果进行渲染。
 


要实现正确的物理效果,必须保证Havok的正确更新时序,但是多个MonoBehaviour本身更新时序就是混乱的,给结合带来了一定的难度。解决方案是,建议将整个游戏所有的逻辑对象更新收归于一个MonoBehaviour中,场景中GameObject上挂接的其余MonoBehaviour仅用于配置参数,不做任何的逻辑更新。

结合的具体过程:两个系统关键对象的对应关系

更新流程的结合可以保证两个系统能运转起来,但是要实现具体功能,则必须明确这两个系统之间的功能对象以及他们的对应关系。

Unity3D的游戏世界是以Scene为单位的,而在手机游戏账号转让Havok中对应的概念是HavokWorld,同一个HavokWorld中的对象才会相互碰撞。Unity3D中的游戏对象是以GameObject附带各种组件来表现,而在Havok中,刚体以HavokRigidbody表示,车辆以HavokVehicle表示,布料以HavokCloth表示,并没有一个直接对应关系,因此,需要在概念上加以封装,然后再对应。

如果我们以CGameScene封装了UnityScene,CGameEntity封装了游戏逻辑对象,CHavokWorld封装了物理世界,CHavokEntity封装了物理功能对象,那么,以一个刚体碰撞对象为例,他们之间的对应关系应该是:


对象关系明确之后,对象之间的更新时序也可以相应明确:
 


简单描述上图中,一个刚体对象的整个功能流程是:CGameWorld中的CGameEntity在一系列逻辑更新之后,准备好了一系列的物理更新参数(可能是需要改变的额外力大小,或者是需要改变的质量大小);然后CGameEntity将这些参数设置给物理对象CHavokEntity,CHavokEntity将参数分解,交给具体的实现对象(hkpRigidbody刚体实现对象);当所有的CGameEntity都传递好参数之后,CGameWorld通知CHavokWorld,开始模拟;等模拟结束之后,所有的CGameEntity再纷纷从CHavokEntity中获取模拟的结果(由hkpRigidbody维护的位置,朝向等最终模拟结果),而这些模拟结果,最终会被设置给GameObject的Transform,拿去做下一步的逻辑处理或者直接渲染。

结合的具体过程:物理资源制作流程的结合

Havok拥有自己的资源描述格式:HKX。HKX可以存放从包围盒到刚体对象(hkpRigidbody实例)等很多信息,HKX拥有文本和二进制两种模式,但是任何一种模式都不被Unity3D直接支持。被结合入Unity3D的Havok物理引擎要想访问到HKX格式的资源有两种方法:

一.将HKX文件直接放到Unity3D的StreammingAssets目录下,在Havok的C++代码层面通过不同平台的IO API去读文件。

这样的不便之处在于需要自己维护StreammingAssets目录下的大量文件,也不能使用Unity3D的异步IO机制。
 


二.利用Unity3D的ScripableObject机制,将HKX文件内容序列化到UnityAsset中,让Unity3D在IO之后以byteStream的形式传给Havok。

好处在于,可是使用Unity3D编辑器强大的文件管理机制,以及异步IO系统。弊端在于byteStream传递过程中可能带来内存的额外开销(包括GC以及内存峰值)。
 


结合的具体过程:物理场景的编辑流程结合

Unity3D以灵活好用的编辑器著称,所以应该将场景中物理对象的编辑结合入Unity3D编辑器。提供一个可行的方案:

以Unity3D原有的GameObject场景编辑模式为基础,在需要物理表现的GameObject上,绑定物理描述脚本,脚本中描述了物理对象的包围体资源和初始化物理信息。物理对象的初始位置可以使用GameObject的初始位置,这样当PlayScene的时候,Unity3D便可以通知Havok根据该物体的初始位置以及描述脚本中的信息去创建物理对象,进行模拟。
 


如图,物理描述脚本EntityRoadBlockParam中包含了路障对象的包围体,质量,碰撞组等物理信息。这种形式的结合方案的不足之处在于,每一个Scene都必须包含Havok引擎完整的更新流程控制代码,无法做到像Unity3D原生物理引擎那样直接拖拽组件就能看到效果。

小技巧与经验

物理对象调试工具

Havok提供了一个可视化的工具——Havok VisualDebugger,将物理世界的信息实时显示出来,方便调试。该工具使用Socket连接的方式与HavokRuntime实时通信,当HavokRuntime结合入Unity3D之后,依然能够正常工作,省去了我们写可视化Debugger的工作量。
 


如果受限于网络环境不能使用VisualDebugger,那么手动绘制物理对象信息也是一个可选的方案,Havok提供了API可以将包围体几何信息输出(以VertexList和IndexList的形式),可以直接填入Unity3D的Mesh组件,在Gizmos或者Renderer中实时绘制,用于观察物理对象是否模拟正常。

稳定物理模拟的帧率

Havok物理引擎在模拟过程中需要一个稳定的更新间隔时间,如果这个间隔时而长时而短,会导致模拟不稳定,发生穿透,位置跳变等现象。解决的办法是,一旦发现间隔时间过长,则在过长的间隔时间之内,以固定的频率多模拟几次,我们称为稳定模拟模式。
 


该方法可以保证物理模拟的稳定性与精确性,但是弊端是可能会进一步降低游戏的帧率。在游戏更新过程中还是应该尽量保证帧率的稳定,避免物理引擎进入稳定模拟模式。

异步物理模拟以提升效率

Havok默认是多线程模拟的,因此,可以对于游戏过程中仅作为表现的物理对象做异步更新,异步更新流程如图:
 


异步更新的好处是可以用逻辑更新和渲染更新的时间做多线程模拟(T1 + T2时间段),降低表现物理层的模拟时间,这个方案会导致渲染层晚一帧得到物理模拟结果。但是,如果物理对象的模拟数据需要拿去做逻辑更新,那么还是需要使用同步模拟机制,否则会增大系统的复杂性。

性能分析

Havok结合到Unity3D之后,性能是一个需要关注的问题。我们做了一个Profile,对比Havok和Unity3D原生的Physx物理性能,用例如下:
 


在场景中堆置168个Block,以一定的间隔时间给每一个Block施加一个随机力,用来扰动这些Block,使他们相互碰撞,观察模拟耗时,在Sansung Note4(3) 手机上,分析结果如下:

PhysX_Discrete离散模式
 


Havok_Discrete离散模式
 


Physx_Continue连续模式
 


Havok_Continue连续模式
 


从分析结果上可以看出,在离散模式下,Havok和PhysX的模拟消耗差不多;但是在连续模式(4)下,PhysX的数据有点离谱,PhysX的连续模拟模式在手机上完全无法使用,而Havok则有高出离散模式一倍的开销。

(1)大多数使用PhysX的游戏并不会使用到GPU加速功能,原因有两点:1,大多数次世代3D游戏GPU负担都非常重,并没有余力做太重度的物理模拟;2.与显卡进行数据传输也是有开销的,轻度物理模拟若算上这一部分开销,在GPU端做并没有占到很大便宜。

(2)Havok的授权很严格,试用需要联系其商务代表。

(3)Samsung Note4 Spec :

PLATFORMOSAndroid OS, v4.4.4 (KitKat), v5.0.1 (Lollipop), upgradable to v5.1.1 (Lollipop)

ChipsetQualcomm Snapdragon 805 Exynos 5433

CPUQuad-core 2.7 GHz Krait 450 (Snapdragon 805)

GPUAdreno 420 (Snapdragon 805)

Mali-T760 (Exynos 5433)

MEMORYCard slotmicroSD, up to 128 GB

Internal32 GB, 3 GB RAM

(4)连续模拟模式(Continuous Simulation),用于解决子弹穿纸类的问题,需要在高速小物体位置更新过程中,使用迭代计算或者射线检测等手段求的高精度碰撞检测与处理结果。

  • 2
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值