Contents

Performance and Requirements

Creating the Data Structure

The Process Manager

The Particle Manager



Now that we have covered the technology behind an individual particle system, it's time to create a manager class to control all of our various particle systems. A manager class is in charge of creating, releasing, updating, and rendering all of the systems. As such, one of the attributes in the manager class must be an array of pointers to particle systems. I strongly recommend that you build or use an array template, because this makes life easier.

The people who will work with the particle systems you create want to add particle systems easily. They also don't want to keep track of all the systems to see if all of the particles died so they can release them from memory. That's what the manager class is for. The manager will automatically update and render systems when needed, and remove dead systems.

When using sporadic systems (systems which die after a given time), it's useful to have a function that checks whether a system has been removed yet (for example, if it still exists within the particle manager). Imagine you create a system and store the pointer to this particle system. You access the particle system every frame by using its pointer. What happens if the system dies just before you use the pointer? Crash. That's why we need to have a function which checks if the system is still alive or has already been deleted by the particle manager. A list of functions needed inside the particle manager class is shown in Table 3.

Table 3. Particle manager class functions
Init Initializes the particle manager.
AddSystem Adds a specified particle system to the manager.
RemoveSystem Removes a specified particle system.
Update Updates all active particles systems and removes all system which died after the update.
Render Renders all active and visible systems.
Shutdown Shuts down the manager (removes all allocated systems).
DoesExist Checks whether a given particle system will exists in the particle manager (if it has not been removed yet).

This was constructed from sparks and a big real-time calculated flare explosion (not just a texture).

This image is hte same as the above one, but with some extra animated explosions (animated textures) and shockwaves, which are admittedly very small and may be difficult to see in this image.


The AddSystem function will probably have just one parameter: the pointer to the particle system which is of the type of our particle system base class. This allows you to add a smoke or fire system easily depending on your needs. Here is an example of how I add a new particle system in my engine:

gParticleMgr->AddSystem( new Smoke(nr
SmokeParticles, position, ...) );

During the world update function, I call the particleMgr->Update() function, which automatically updates all of the systems and releases the dead ones. The Render function then renders all visible particle systems.

Since we don't want to keep track of all particles across all of our systems every frame to see whether all particles have died (so the system can be removed), we'll use the Update function instead. If this function returns TRUE, it means that the system is still alive; otherwise it is dead and ready to be removed. The Update function of the particle manager is shown in Listing 2.

In my own particle system, all particles with the same textures and blend modes assigned to them will be rendered consecutively, minimizing the number of texture switches and uploads. Thus, if there are ten smoke systems visible on screen, only one texture switch and state change will be performed.

This electricity has its own render function. A hierarchy tree was constructed to represent the electricity flow using branches and sub-branches. It is a thunderstorm lightning effect with the branches animated. Particle shapes are being constructed for every part in the electricity tree.

A rain effect, using stretched shapes for the particles. The rain also splats on the ground by calling the sparks system with adjusted settings and texture.



Design, Then Code

Designing a flexible, fast, and extensible advanced particle system is not difficult, provided you take time to consider how you will use it within your game, and you carefully design your system architecture accordingly. Because the system I discussed uses classes with inheritance, you can also put the individual particle system types into .DLL files. This opens up the possibility of creating some sort of plug-in system, which might be of interest to some game developers.

You can also download the source code of my particle system, which I have created for Oxygen3D, my latest engine. This source is not a stand-alone compilable system, but it should help you if you run into any troubles. If you still have any questions or remarks, don't hesitate to send me an e-mail.


Discuss this article in Gamasutra's discussion forums

________________________________________________________

[Back To] Performance and Requirements