如何读懂UWA性能报告?—物理篇

如何读懂UWA性能报告?—物理篇

接着昨天渲染模块的讲解,今天为大家梳理下物理模块。一般来说,该模块的开销都是比较小的,但秉着“勿以恶小而为之,勿以善小而不为”的原则,我们将结合UWA的性能报告,再给大家强调下必须注意的几个优化点。

当然,纸上得来终觉浅,绝知此事要躬行,www.uwa4d.com等你来体验。


抛砖引例

打开物理模块的界面,我们可以看到更详细的性能数据,下图所示的是某卡牌回合制手游在红米2上的性能表现:
UWA Tech Doc
我们可以看到报告中的四个考核值为:“CPU均值”、“Contacts数量峰值”、“静态碰撞体峰值” 和 “动态碰撞体峰值”。需要说明的是动态碰撞体是指带有RigidBody的Collider,而静态碰撞体指不带有RigidBody的Collider。

“CPU均值” 目前主要是Physics.Simulate每帧的平均CPU耗时,一般我们建议在3ms以下。但同时我们也需要关注测试的主体范围(5%~95%)内的数值,通过UWA报告右上角的“分析 & 建议”即可查看,该游戏的主体范围值集中在0.1~3.5ms之间,相对偏高了。

UWA Tech Doc
另外,我们可以在报告中看到物理函数Physics.Simulate的趋势图,即Unity引擎中物理引擎的主要性能体现(Unity 5.x版本中多了个Processing,其实就是把Simulate拆开了)。对于Unity引擎而言,其4.x版本所使用的物理引擎为Nvidia PhysX 2.8,5.x版本所使用的物理引擎为Nvidia PhysX 3.3。


引起 Physics.Simulate 开销较大的几个因素

1.Rigidibody
该组件可使得游戏对象在物理系统的控制下运动。对于移动设备而言,建议Rigidibody数量控制在50以下。同时需要注意的是,大家常常会用Rigidbody组件配合CapsuleCollider,通过RigidBody.velocity来移动。这些会造成物理计算,特别是网格有很多Mesh Colider的时候,物理计算相当高。因此,我们建议尽量用Transform.Position代替物理计算。如果大家的地形是凹凸不平又要有重力的表示,也可以用Navmesh去做,它所引起的工作量在于烘焙Navmesh,并且尽可能地贴合地表 ,但是可以完全不用物理计算。

2.Contacts & Colider
Contacts数量为碰撞对(Contact Pair)数量。任意两个发生碰撞的碰撞体都会产生一个“碰撞对”。一般来说,Contacts数量越大,则表明碰撞物体的数量越多,即物理系统的CPU开销越大。那么碰撞体数量控制在多少以下比较合适呢? 一般来说,碰撞体数量(静态碰撞体和动态碰撞体两者)均控制在100以下,当然越低越好。


几个注意点

1. 如果你是用NGUI制作UI,则在NGUI界面打开后,往往会有Physics一下涨高的情况。这是因为NGUI为了实现点击事件的检测,在每个UI上都设有Rigidbody,所以当UI Widgets摆在同一深度并存在相互叠加的情况时,会造成较多不必要的Contacts。但实际上UI根本不需要任何物理计算,所以大家需要看看能否把UI层之间的碰撞检测关掉。那是否有方法确定这些开销是NGUI造成的呢?推荐的做法是:通过报表,看到趋势图中的较高值后去找它对应的场景图,如果发现对应的场景都是UI,就可以判断Physics的碰撞矩阵中UI和UI之间是相互碰撞的。

2. OntriggerXXX(如OntriggerEnter)。这种情况一般是在脚本中触发了其他的逻辑调用,例如在主角被碰撞从而受到伤害时,创建一个伤害数字的UI,这些均有些实例化的逻辑计算,当然这些也会算到Physics开销中。所以如果你报告中的物理模块的数据都是正常的,但是物理开销依然很大,则需要大家再着重检测这个部分逻辑代码了。

今天的分享就到这里,明天我们继续讲解UWA测评报告中的动画模块,感谢各位开发者的关注。

  • Techniques for Game Development 20 发表在 2019年03月11日 回复

    [...]Before optimization, the subject needs to know some basic physical value recommendations first, not all devices can smoothly run 100 freely made skinned mesh models. Therefore, it is recommended to re[...]