Particle System Design?

Question

I'm designing my own particle System engine, this is for learning purposes, I don't really want to use an existing engine.

Right now I generated beautiful particles, but I want to layout the engine to make it easier to work with them.

I have been thinking on a Class "Particle System",

that class would contain the following references:

particlesList: A list of the particles that compose the system.

systemEmitter: The system emitter for the particles, the Emitter class should be able to perform several particle emission techniques, like for example, emitting from lines, points, randomly emitting from a polygon. Also this class should do Emission Controlling, like emitting towards a point, away from a point, in a direction and time to emit.

particleController: Manages for example rotation around a point, variable particle sizes, variable particle colors, areas around the system to which the particles react in different ways, collision detection ( with other objects or within the particles if becomes necesary ).

Particle Renderer: In charge of drawing this system , Variable Blending types, particle textures, particle types like triangles, circles, custom...

This four items , would compose the particle system Class. Some FX may require more than one particle system, for example a Fire FX, could use one system for the fire, one system for smoke and one system for sparks.

This is what I have in my mind, but I would really love to know if this design approach is good, or if you see I'm missing something or could/should do something different. I haven't thought about some easy way to "save" FX, like for example what would be the best way to tell my engine, "draw Fire", "draw explosion" , "draw fountain", etc, maybe storing FX information in xml files would be a good idea, etc..

Opinions are really welcome, and as I stated before, I really want to build this, instead of using another engine, for learning reasons.

Answer 1

This set-up should be fine. What I hope you're thinking about is what data will make up a particle that will be in the particle class. You'll want to only have the bare essentials so you only have to read/write as little memory as possible when running the system.

As far as making it data driven that should be pretty straight forward. I would suggest an xml and binary format option for loading. so you can tweak stuff easily while developing (and not having a tool). Once you have a tool or are done tweaking I would convert the xml to binary for quick loading.

You may also want a manager class that handles the creation and updating of these particle systems. This would also allow you a place to handle other functionality that has to do with all your systems. Some examples of this is limiting the amount of particle systems or particles that can be managed for performance reasons or having a collision plane that all systems should take into account.

You mention this is for education purposes and in that regards these things are pretty nit picky (but important if you are to use this in a game that is particle heavy).

I am assuming this is using a API like DirectX or OpenGL to render. In that respect I would have the particle effects all share the same pool of memory for your vertex information. This help the rendering speed a lot. I would also keep track of a bounds of the area affected by a particle system for use with frustum culling (AABB or Circle).

A huge part of updating a particle system is how attributes go from one value to another. The more dynamic you can make the interpolating of values the better your effects can look. Simply linearly interpolating could be good enough, but It may be better to have a dynamic graph that is used to interpolate the values. For example instead of going from 0 to 255 blue in a second, it may be cool to go 0 to 128 in 0.2 seconds then 128-255 in 0.8 seconds. Adding that will greatly increase the options on how your effects look.

Besides that I think you have a pretty good idea about what you want to do. Your mention of rendering different types of particles tells me you are thinking about this in the right way. I've seen people make particle engines just focusing on rendering a billboarded quad. Having the option to emit 3d geometry really makes things look great. You may also want to think about (if you haven't already) having the ability for your system to take model information and dynamically split the it into separate particles to be emitted. Actually exploding a model looks greatly better then displaying some explosion particle and fading out the object or switching it to a damaged state.