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

最新推荐文章于 2024-05-15 09:45:10 发布

晓衡的成长日记

最新推荐文章于 2024-05-15 09:45:10 发布

阅读量1.4k

点赞数 3

文章标签：算法 opengl 编程语言 shader unity

原文链接：https://forum.cocos.org/t/topic/97137

版权

流体效果 相信大家都不陌生，实现方式中的一种是将粒子渲染成 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

实现原理

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

var psd = new b2.ParticleSystemDef();
// ... 粒子半径、阻尼等初始化代码，具体写法可参考box2d API文档
cc.director.getPhysicsManager()._world.CreateParticleSystem(psd);

将所有粒子的坐标通过uniform变量一次性传入shader。shader写法和本文开头类似，需要根据粒子数量增加循环次数。

分析

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

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

实现原理

每个粒子是一个cc.Node，并挂上 物理碰撞组件 。
每个粒子用一张圆形渐变图渲染到内存纹理，圆形渐变图等效于粒子的密度场。
用shader处理内存纹理，剔除小于阈值的像素。

分析

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

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

方案3（优化方案）：box2d + 自定义assembler

实现原理

跟方案1一样，使用box2d产生粒子组。
在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+。这是一帧的运算量，所以内部循环是热点代码。
可以做一些代码低级优化进一步提升性能，包括