|
by
John van der Burg
Gamasutra
June 23, 2000
This
article originally appeared in the
March 2000 issue of:
|
Letters
to the Editor:
 Write
a letter
View
all letters
|
|
 Features
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
|
|
|
|
|
