GT 大神 | 如何高效渲染流体效果(绝对干货)

流体效果 相信大家都不陌生,实现方式中的一种是将粒子渲染成 metaball 。

什么是metaball

metaball 就是粒子加上其周围的 密度场 (density field)。两个 metaball 靠近时,其密度场会叠加。当屏幕上某个像素的"密度"大于阈值时,将其着色,小于阈值的像素按透明处理。

一个简单的 metaball 片元着色器实现如下:

void mainImage(out vec4 fragColor, in vec2 fragCoord)
{
    vec2 uv = (fragCoord * 2. - iResolution.xy) / iResolution.y;

    // 指定两个metaball的坐标以及半径
    float r = 0.08;
    vec3 metaballs[2];
    metaballs[0] = vec3(-0.4, 0.0, r);
    metaballs[1] = vec3(0.4, 0.0, r);
    
    float density = 0.0;
    float sum = 0.0;
    for (int i = 0; i < 2; i++) {
        // 当前uv在第i个metaball密度场内的密度值
        // 密度场和距离相关,公式可以视情况调整
        density = metaballs[i].z / distance(metaballs[i].xy, uv);
        
        // 累加密度值
        sum += density;
    }
    
    // 不显示密度和小于阈值的片元,阈值可以视情况调整
    sum = step(0.8, sum);
    fragColor = vec4(vec3(sum), 1.0);
}

如果要渲染有一定体积的流体,需要实时渲染几十上百甚至上千个metaballs,此时渲染的效率就需要考虑进来。

在Cocos论坛里已经有不少相关的实现,本文将对两种不同的方案进行学习分析并提出优化方案。相关链接均放在文章底部

优化方案只针对运行效率,本文不讨论渲染的视觉效果优化。
方案同样适用于流体之外的其他粒子特效。

方案1:box2d + shader

实现原理

  1. 通过 box2d 产生一批粒子。Cocos Creator的物理引擎封装了box2d,通过以下代码可以创建box2d的粒子组:

var psd = new b2.ParticleSystemDef();
// ... 粒子半径、阻尼等初始化代码,具体写法可参考box2d API文档
cc.director.getPhysicsManager()._world.CreateParticleSystem(psd);
  1. 将所有粒子的坐标通过uniform变量一次性传入shader。shader写法和本文开头类似,需要根据粒子数量增加循环次数。

分析

片元着色器程序需要遍历所有metaball,500个metaball的情况下需要执行上千条指令。每一帧每个片元都需要执行这么长的程序,并且往往这种渲染方式需要全屏幕渲染,GPU压力将非常大。

方案2:cc.Node + 物理碰撞

实现原理

  1. 每个粒子是一个cc.Node,并挂上 物理碰撞组件 。

  2. 每个粒子用一张圆形渐变图渲染到内存纹理,圆形渐变图等效于粒子的密度场。

  3. 用shader处理内存纹理,剔除小于阈值的像素。

分析

cc自带的碰撞检测的性能相对于box2d的粒子组碰撞检测效率要差一些,前者算法时间复杂度是O(N^2),后者在渲染同半径的粒子组时可以优化为O(NlogN),具体算法可参考文末PPT链接。在metaball数量较多的情况下差异会显现出来。

另外由于使用cc.Node包装了粒子,对引擎带来一定的overhead,如render-flow遍历时需要逐粒子做RenderData更新(相对于碰撞检测来说这部分可以忽略)。

方案3(优化方案):box2d + 自定义assembler

实现原理

  1. 跟方案1一样,使用box2d产生粒子组。

  2. 在assembler里获取所有粒子坐标,批量组装成顶点数据。
    针对每个粒子生成一个四边形,附带它在世界坐标里的原心位置,同时省略了uv和color属性。
    顶点格式如下:

var vfmtPosCenter = new gfx.VertexFormat([
    { name: gfx.ATTR_POSITION, type: gfx.ATTR_TYPE_FLOAT32, num: 2 },   // 粒子顶点(1个粒子有3个或4个顶点)
    { name: "a_center", type: gfx.ATTR_TYPE_FLOAT32, num: 2 }           // 原粒子中心(每个顶点相同数据)
]);

box2d坐标空间到cc世界坐标的转换方法如下

// 获取粒子在cc世界空间里的半径大小
let PTM_RATIO = cc.PhysicsManager.PTM_RATIO;
let r = particles.GetRadius() * PTM_RATIO;

let posBuff = particles.GetPositionBuffer();
let particleCount = particles.GetParticleCount();
for (let i = 0; i < particleCount; ++i) {
   // 获取粒子在cc世界空间里的坐标
  let x = posBuff[i].x * PTM_RATIO;
  let y = posBuff[i].y * PTM_RATIO;
   // ... 拼装第i个粒子的顶点数据
}

可以学习方案2对每个粒子使用圆形纹理图,本方案为了简单起见直接在shader里画圆。

更加高效的渲染方式应该是用 GL_POINTS 模式配合纹理渲染一个粒子,但是我还没掌握在cc里实现的方法。

分析

避开了方案1的GPU瓶颈和方案2的CPU碰撞计算瓶颈。
缺点是代码量相对较高。完整实现见文末Demo。

性能对比

测试环境:华为P9手机,chrome访问,开发模式
测试数据均来自cc自带调试面板数据的目测。

数据解释

方案1的Game Logic很低,但是帧率较低,结合其实现原理不难推断出是GPU压力影响了整体帧率;

方案2的Game Logic偏高,主要是物理碰撞检测导致的CPU压力;

方案3整体运行相对更加流畅。在粒子流动的过程中fps较高,但是当粒子积压在场景底部时fps降低。这是因为在流体里面物理计算量和粒子之间的连接点数成正比。在水流动过程中连接点较少,当粒子全部落到底部趋于静止时每个粒子周围都有多个连接点,计算量最大。

代码低级优化

进一步对方案3进行profile,可以发现,最耗时的仍然是 粒子碰撞检测 部分,其中最耗时的部分是box2d里寻找粒子之间的连接点,见下图。

经实际运行统计,在1000个粒子的场景下将产生7000+个碰撞点,函数内部循环次数加到14000+。这是一帧的运算量,所以内部循环是热点代码。
可以做一些代码低级优化进一步提升性能,包括

  • 将函数调用展开,包含大量的向量计算函数

  • 用临时变量代替公共表达式,减少重复计算

优化后的profile如下图,在整体CPU耗时占比中下降了10%,但是仍然是大头。

iOS微信小游戏测试数据

方案3 Demo在iPhone SE2上实测,1000个粒子流动过程中为60fps,粒子积压在底部时为5fps。直接在Safari浏览器里面跑可以达到60fps。

由于iOS微信小游戏环境无法开启jit,在计算密集型场景下效率非常差,目前没有较好的解决方案。

Demo地址

https://github.com/caogtaa/CCBatchingTricks

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值