众所周知,物理开销一直是 CPU 的一个大头,而且还很容易出问题。对于开放世界,该如何进行物理运算,以及采用什么方案计算碰撞。
本文针对这个问题做了一些细微的研究,算是对 Unity 下的解决方案有了一个大致的方向。
1、现有物理方案
目前 Unity 里可用的物理方案(现成的)有3种:
- Unity 默认的 PhysicsX:默认的物理,大家用得最熟的就是这个;
- Unity Dots Physics:在 Dots 系统中的物理;
- Unity Havok Physics:基于 Havok 的物理系统;
这里我们对三种方案都进行一个测试:
1、底部放置一个 Mesh (地形),尺寸约 2000*100*800,顶点数 1229,三角面 2171 :
2、之后在空中 100*100 区域的范围洒落 球/立方体 碰撞:
3、等方块/球落地后基本稳定、帧数不变之后,记录当前的实体数量;
4、记录帧数刚好在 60/45/30 时对应的实体数量;
注:这里的测试方案我是选择了对于物理系统最不友好的方式(大量物体都积累在同一区域相互碰撞),如果物体均匀分散,性能压力会小很多。但进行压力测试时,都是考虑的最差情况。
这里我在小米9上进行了真机测试,结果如下:
三种物理系统的差别并不算大,Havok 的性能会好一些,而 Unity.Physics 和 默认的 PhysicsX 没有太大差异。究其原因,Unity 的默认碰撞 PhysicsX,其实也是多线程。
2、开放世界物理方案
通过上文的测试,无论采用什么方案,如果数量到达了数千的地步,都是接受不了的。如果考虑到开放世界中的场景丰度:石头、树木、关卡交互等,数量可以非常庞大。考虑到 小米9 并不是支持的最低端手机,因此建议同时激活的带碰撞的物体要一直控制在 1000 以下。我后面也没有纠结物理系统了,就直接使用 Unity 的 PhysicsX 就行了(会的人多,实现起来简单),即便使用其他的方案也不会有质变。
之前看到一个方案,就是通过射线检测来替代物理碰撞(《腾讯游戏开发精粹Ⅱ》第10章 物理查询介绍及玩法应用、第11章 基于物理的角色翻越攀爬通用解决方案),也能大大降低性能消耗。我这里简单介绍下这个方案的思路:
在玩家的移动方向上打射线(不一定只能从上往下打),越靠近玩家射线的精度越高。在计算时,先在最远处检测,如果检测到有障碍,便激活中距离的检测(精度更高、性能开销也越大);如果在中距离检测到了,便激活近处的射线检测(此时检测到的数据就与玩法相关,以实现爬墙、跳跃等规则)。
这种分级射线检测的好处,在玩家处于空旷地块时,可大幅减少射线检测的频率。此外,使用射线代替碰撞,能减少大量物理开销,也能减少因为物理碰撞产生的各种飞天遁地等表现异常。
3、岛屿轮廓的碰撞
我们的地形数据是生成的高度图,岛屿形状其实并不能在 CPU 中体现,自然也无法获取到类似于网格这种的碰撞数据。需求上,有需要船只会被岛屿边缘弹开(有类似推开的物理效果)的功能。针对海岛,我设计了基于有向距离场(Signed Distance Function,以下简称 SDF)的碰撞方案。
关于 SDF,建议先参考以下文章:
-
海水波浪计算:在岛屿靠近岛屿区域时,海浪高度(强度)减弱,且海浪不能漫过岛屿。
-
行船碰撞计算:开船不能直接撞上岛屿,也不能直接生硬拦停,通过SDF图可以拟合渐变实现碰撞转向的效果。
因为这个值需要在CPU、GPU都读取,在Unity2020+中可以使用 RawBuffer 辅助两边的数据共享。这里使用实时在线生成的方式生成SDF图,由GPU进行计算。
动态生成的好处是能支持动态的阻挡物,而且全局唯一一份(只在船或相机附近生成)固定大小的图,更为节省内存。但缺点是生成的结果不能立即拿到,需要一定时间进行生成,可能在2s左右才能获得最终结果(由于海洋主题中,船只的行进都是较慢的,所以问题不大)。
以玩家(相机)为中心,生成一张 1024*1024 的贴图,数据存储为 RGBA 32 bit,也就是每个像素4个字节。其中RG表示最近障碍物的距离,BA表示法线。整张图的重构逻辑依旧是AOI的九宫拆分:
SDF图的重建逻辑:初始化时,以玩家(相机)为中心生成一张1024*1024的贴图。玩家从A点移动到C点:当玩家在B点(黄色区域时)仍使用当前数据。当玩家移动到C点(离开黄色区域)则开始按照C点为初始点构建新的图(重新构建时有4~6个格子的数据可以复用,但一般还是直接整张图重建)。
在 ComputeShader 中,每帧进行一次迭代,每个像素计算周围8个格子,类似于流场的做法。虽然理论上,最坏情况需要 52 万次才能迭代完成,但实际应用中收敛次数不会这么多,具体需要测试。预测会在2~3s内完成收敛(迭代30~60次)。
之后,CPU 和 GPU 都可以通过 SDF 图数据来计算了。
4、总结
对于开放大世界的物理碰撞,根据现有解决方案,需要将带物理的物体控制在 1k 以下,就能很好地在手机上运行并支持玩法。
对于特殊的需求(例如翻墙、攀岩)等,通过射线手段进行辅助检测,减少物理碰撞的开销。基于 GpuTerrain 实现的地形,则需要通过生成 SDF 图的方式来辅助碰撞,基本上能满足需求。
对于一些对碰撞精度要求较高的需求,也可以通过取巧的方式来实现。(例如,如需要玩家在前进过程中自动绕开一些小型灌木。这种如果不能上物理和寻路、RVO,可以将灌木的数据记录在地块信息图中,在玩家经过时播放一个向左/向右的躲避的动画,在表现上与玩家绕开障碍就一般无异了)