基于GPU 的游戏粒子系统设计

基于GPU 的游戏粒子系统设计摘要：在MMORPG游戏中经常出现同屏显示成千上万的粒子特效，传统引擎虽然使用多线程来计算粒子的运动，但是也很难应付大规模的计算量（考虑到一般配置）,更何况MMORPG中还空出许多CPU去处理逻辑。

提出基于GPU进行粒子计算的粒子系统,利用GPU的并行计算多个对象,实现并行化高效的粒子系统。

关键词：粒子系统；GPU；并行计算1 系统原理在游戏设计中，基于粒子系统可以实现火、爆炸、烟、云、雾等效果。

粒子系统主要用来解决由大量按一定规则运动（变化）的微小物质组成的大物质在计算机上的生成与显示的问题。

经常使用粒子系统模拟的现象有火、爆炸、烟、水流、火花、落叶、云、雾、雪、尘、流星尾迹或者象发光轨迹这样的抽象视觉效果等。

粒子系统的实现：①每个粒子是一个带纹理的三角形/多边形，粒子系统由多个粒子组成；②粒子按一定规则运动；③每个粒子有自己的属性，如位置、速度、质量、尺寸、年龄、运动轨迹斜率、颜色等；④粒子系统更新循环划分为两个不同的阶段：参数更新/模拟阶段以及渲染阶段；⑤参数更新/模拟阶段根据粒子系统信息更新每个粒子的速度、位置、尺寸、颜色等信息；⑥渲染阶段根据粒子属性重新绘制粒子；⑦每个粒子都有自己的生命，年龄超过最大年龄的粒子会被销毁，系统会生成新的粒子。

2 系统设计2.1 框架分析ParticleFactory是粒子工厂类，负责创建和销毁粒子，同时管理了当前创建的粒子。

Iparticle为粒子的接口类，所有粒子都从它派生出来，它定义了粒子的基本接口：Play、Stop、GetProperty和SetProperty。

MMO_Particle表示使用MMO_计算的最终生成面片的粒子，MMO_MeshParticle表示使用MMO_计算的基于网格的粒子。

BaseGpuParticle表示使用GPU计算和更新粒子。

每一个粒子对象都有一个指向ParticleProperty类的指针。

ParticleProperty保存了粒子的属性参数，包括基本的颜色、大小、旋转角度等，还有受力、发射器。

多个粒子对象可以指向同一个ParticleProperty对象。

ParticleController是粒子控制器，它管理了引擎中众多的粒子控制器，同时提供与外部交互的接口以用于实现某些特殊的效果，比如武器划动的轨迹效果等。

2.2 CPU vs GPU传统游戏引擎提供的是基于CPU的粒子系统，但是考虑到MMORPG中有可能同屏显示成千上万的粒子特效，效率问题不能不考虑。

引擎中虽然使用多线程来计算粒子的运动，但是也很难应付大规模的计算量（考虑到一般配置）。

更何况MMORPG 中还有空出许多CPU去处理逻辑。

于是笔者想到了用GPU进行粒子计算。

肯定许多人会问，用GPU不是比CPU更复杂吗？其实恰恰相反，GPU的粒子比CPU简单得多。

引擎中的粒子必须要有模拟器、发射器、力、控制器还需要多线程调度任务，可谓庞大复杂。

而GPU粒子只需要一个MMO_SingleShaderMaterial和一个MMO_Mesh，不必担心GPU粒子的灵活性，笔者实现了3种GPU粒子效果：烟雾、火焰和龙卷风。

每一种都开放了大量可控参数，比如烟雾就有浮力、重力、风力、速度、扩散值、原始大小、目标大小、原始颜色、目标颜色还有纹理，其中纹理可包含多帧。

如此多的参数，是否需要很复杂的GPU程序呢？其实不然，在笔者的实现中，vertex shader的HLSL代码只有20行，pixel shader代码有4行。

Vertex shader使用vs1.1版本即可。

为什么代码会这么少？这是因为GPU编程与CPU编程是不同的，CPU 通常逐个计算单一对象，而GPU则是并行的流式计算多个对象。

当使用CPU编程时，总是想到建立一个缓冲然后创建粒子，保存属性，每帧更新，删除粒子等。

而GPU编程完全不同，它没有创建删除粒子，保存其状态的概念，也不能够创建缓冲来保存粒子的属性等。

在GPU编程中，处理好一个粒子就等于处理好多个粒子了。

但是GPU也并非没有缺点，比如GPU实现的粒子是很难互相访问数据的。

在游戏开发中，我们常常要在性能与效果上做出取舍。

笔者认为对于大部分常见的效果用GPU粒子就能做到简单高效，对于少部分特殊效果可以用的CPU模拟计算的粒子实现。

因此在粒子系统中，提供了BaseGpuParticle类，用于实现GPU模拟计算的粒子。

2.3 粒子的属性无论是CPU粒子还是GPU粒子，都可以有大量的属性参数，这些属性参数实际上不需要每个实例都保存一份，比如场景中许多相同的火焰，它们只是位置、转向、缩放值不同而已。

这一概念很类似场景的物体与物体的材质的关系。

因此粒子系统中统一把材质的属性做为ParticleProperty类管理。

许多参数不是固定的，也就是说可以加上或减去某项属性，比如某个力，可以加上也可以减去。

为了方便设置，ParticleProperty类并不需要手动的加入或删除某个力或发射器，而是直接设置力的大小，当力作用为0时自动把力删除，发现没有这个力时自动加上。

引擎中每一个粒子的属性可以有位置、颜色、线速度、角速度、大小、旋转角度、生命值、纹理坐标等。

这些数据存放在MMO_PSParticleSystem对象中，每一个MMO_PSParticleSystem 代表了一组一定数量的粒子，这个粒子的数据在MMO_PSParticleSystem对象创建时即被指定，并且创建后不能更改，同时MMO_PSParticleSystem对象中所保存粒子数据的缓冲在创建后也不会重新分配。

MMO_PSParticleSystem中提供了获取当前粒子数据缓冲的接口，但是并不提供线程安全的方法，如Lock、Unlock。

这是因为MMO_系统的运行机制是保证线程安全的。

但是当程序需要获取MMO_PSParticleSystem的数据时，要注意先调用ForceSimulationToComplete方法以保证所有粒子更新的线程任务已经完成了。

值得注意的是，粒子的位置属性可以分为世界坐标系或模型坐标系。

当指定为世界坐标系时，MMO_PSParticleSystem的位移（translation）与旋转（rotation）属性将不起作用，但是缩放（scale）值除外。

注意这并不意味着粒子不用乘以世界矩阵，只是世界矩阵为单位矩阵而已，原来的世界矩阵被存放在MMO_PSParticleSystem::m_kUnmodifiedWorld成员中。

缩放值的作用通过粒子生成器（MMO_PSAlignedQuadGenerator）实现而不是世界矩阵。

当使用模型坐标系时，粒子的位置属性与普通的网格一样。

注意这一点十分有用，比如场景中有相同十个火把，它们的更新过程是相同的，使用模型坐标系时需要一个MMO_PSParticleSystem对象就够了，可以通过改变位移、旋转和缩放值使火把看起来有些区别。

3 系统的实现3.1 网格类网格类（MMO_Mesh）表示引擎中一切由顶点和图元组成的网格，而粒子也不例外。

MMO_Mesh中管理了多个MMO_DataStreamRef对象；而MMO_DataStreamRef其实就是指向MMO_DataStream对象的智能指针；网格类的MMO_DataStream默认都为MMO_DX9DataStream，即每个DataStream绑定了一个D3D的Buffer，可以是顶点缓冲或索引缓冲，非D3D托管的Buffer会有一份在内存中的数据。

MMO_DX9DataStream::UpdateD3Dbuffers方法负责把内存中的数据更新到D3D的Buffer中，那么粒子系统只需更新内存中的数据，然后调用UpdateD3Dbuffer方法即可。

事实上引擎正是这样实现的，MMO_PSParticleSystem继承至MMO_Mesh，它把粒子的各种属性保存为独立的缓冲里，交给粒子模拟器去更新这些数据，更新结束后使用MMO_PSFacingQuadGenerator生成粒子的顶点与三角形，并将这些几何数据存入MMO_DX9DataStream中。

每次渲染时，MMO_Mesh一旦检测到MMO_DX9DataStream 的数据改动了（标志为Dirty），就调用UpdateD3Dbuffer更新D3D 的对应缓冲。

3.2 网格修改器面向对象的游戏自然不允许外部随意的更改MMO_Mesh 的数据。

实际设计中通过一个特殊的网格修改器类（MMO_MeshModifier）。

一个MMO_Mesh中可含有多个MMO_MeshModifier（最多7个）,每一个MMO_MeshModifier 绑定到MMO_Mesh之后，就会将相应的MMO_SPTask的输入输出流绑定到MMO_Mesh的DataStream上。

实际上MMO_MeshModifier是一个虚基类，里面有几个重要的方法：MMO_MeshModifier::Attach：将自己绑定到MMO_Mesh上，同时初始化相应的MMO_SPTask，把相应的输入输出流也绑定到MMO_Mesh上。

MMO_MeshModifier::Detach：解除对MMO_Mesh绑定，同时也解除输入输出流的绑定。

MMO_MeshModifier:: SubmitTasks：将相应的MMO_SPTask 提交给MMO_，注意这里只是提交一些轻量级、可同步的单独任务。

如果需按顺序实现的任务，还得自己维护一个MMO_SPWorkflow。

MMO_MeshModifier:: CompleteTasks：强制完成任务。

这里会等待MMO_完成指定的任务。

需注意的是此函数在任务完成后并不更新D3D Buffer。

网格修改器为处理网格内部数据提供了便利，粒子系统中的粒子模拟器（MMO_PSSimulator）继承至网格修改器。

与一般网格修改器不同，模拟粒子的计算量大，因此粒子模拟器中由多个MMO_SPTask来完成计算任务，通过维护了一个或多个MMO_SPWorkflow来管理这些Task。

参考文献：\[1\] 张芹，吴慧中，张健.基于粒子系统的建模方法研究\[J\].计算机科学，2003(8).\[2\] 马骏，朱衡君.基于动态纹理和粒子系统的喷泉模拟［J］.北京交通大学学报，2005(1).\[3\] MACEDONIA M.The GPU enters computing’s mainstream\[J\]. IEEEComputer,2003(10).。