By David K. McAllister

Version 1.10

December 22, 1998

The Particle System Application Programmer Interface (API) is a set of functions that allow C++ programs to simulate the dynamics of particles. The Particle System API is intended for special effects in interactive and non-interactive graphics applications, not for scientific simulation, although principles of Newtonian physics have been used to implement the particle dynamics where applicable. The style of the API is intended to be similar to that of OpenGL (from Silicon Graphics, Inc. and the OpenGL Architecture Review Board). OpenGL is currently the standard 3D graphics API because of its cleanness, clarity, and ability to represent a variety of graphics hardware while completely abstracting the hardware away from the application programmer.

This API consists of four sets of functions. These are calls that set the current state of the library, calls that act on groups of particles (these functions are called Actions), calls that operate on and manage particle groups, and calls that create and operate on action lists. The documentation is divided into four sections for the four kinds of functions.

Particles

For the purposes of the Particle System API, a particle is not just a very tiny speck. Particles can be drawn as anything - water droplets, birds, tumbleweeds, even people. The Particle System API is generally useful for operating on many similar objects that all move and change according to the same basic rules, no matter what the objects and rules are.

A particle in the abstract sense used by the API is merely an entity with a small set of attributes such as position and color that ultimately dictate the particle's behavior and appearance. Here are the particle attributes: The position, represented as three floats, tells where the particle is. The color is represented as three floats. The velocity consists of three floats telling the direction and speed of the particle's movement. The size is one float representing how large the particle is for purposes of drawing. At present, the size attribute does not affect the particle's behavior (under gravity, for example), and should not be interpreted as mass in particle physics equations. The age attribute is one float representing the amount of time since the particle's creation. The secondary position, or positionB attribute, specifies another position in space for this particle. It usually represents the particle's initial position, or the particle's destination. See pRestore for a use of positionB.

Particle Groups

A particle group is a system of particles that are all acted on together.

It can be considered a dynamic geometric object.

The dynamics are provided by the particle actions. From the point of view of the graphics system, a particle group is just another model to be drawn. The Particle Groups section of the documentation explains the functions that create and deal with particle groups.

State

As in OpenGL, some calls actually do something and some calls modify the current settings (the current state) that describe the behavior of the calls that do something. Each of the following calls modifies the current state of the Particle System API. Most elements of the current state are used to specify attributes of particles to be created.

Actions

Actions are the core of the Particle System API. They are the functions in the API that directly manipulate the state of particles in particle groups. They perform effects such as gravity, explosions, bouncing, etc. to all particles in the current particle group. A program typically creates and initializes one or more particle groups, then at run time it calls particle actions to animate the particles and finally calls a pDrawGroup function to draw the group of particles onto the screen.

The Particle System API uses a discrete time approximation to all actions. See pTimeStep for information on improving simulation quality by varying the time step, dt.

Action Lists

Action lists are blocks of actions that are applied together to a particle group. They are conceptually similar to scripts or procedures. They can also be thought of as similar to display lists in OpenGL. An action list abstracts the specifics of a particular effect and allows complex effects to be treated as primitives like actions (except that an action list cannot be an action within another action list). Action lists also allow effects to be simulated much more efficiently on certain parallel machines, such as PixelFlow. Also, action lists can be optimized by a particular implementation of the Particle System API. For example, common sequences of actions can be detected and replaced by efficient code that handles all those actions in one pass.

Domains

A Domain is a representation of a region of space. For example, the pSource action uses a domain to describe the volume in which a particle's random initial position will be. The pSink and pBounce actions use domains to describe a volume in space for particles to die when they enter, or to bounce off, respectively. Domains are used as parameters to many functions within the API. See the Domains section of this document for more.

This is a description of all calls that set the current state of the Particle System API. These state values dictate the properties of particles to be created by pSource or pVertex. The one exception is pTimeStep.

The special value of s2, -1.0, means to set s2 equal to s1. Since the default value of s2 is –1.0, this makes it possible to set the size of particles to an exact value instead of a range by specifying only a single parameter.

This value can be positive, zero, or negative.

The Particle System API uses a discrete time approximation to all actions. This means that actions are applied to the particles at a particular instant in time as if the action's effect accumulated over a small time interval, dt, with the world being constant over the interval. The clock is then "ticked" by the length of the interval and the actions can then be reapplied with the particles having their updated values. This is the standard method of doing almost all time-varying simulations in computer science.

How does the time step, dt, relate to the application's frame rate? The easiest method is to apply the actions once per frame. If the application prefers to keep time in terms of seconds, dt can be set to (1 / frames_per_second). But more often, it is easier for a time unit to be one frame instead of one second. In this case, dt should be 1.0, which is the default.

For higher quality, the application can apply particle actions more than once per frame. This provides smoother, more realistic results in many subtle ways. Suppose the application wanted to compute three animation steps for each rendered frame. Set dt to 1/3 its previous value using pTimeStep, then loop three times over all the action code that gets executed per frame, including the calls to pMove. If using action lists, this can be simply a loop over the pCallActionList call. The run-time results should be about the same, but with fewer discrete approximation artifacts. Surprisingly enough, the actions themselves usually take a small percentage of the CPU time, so using a finer step size usually does not impact frame rate very much.

In terms of numerical integration, particle actions can be thought of as the first derivative of unknown functions dictating the particle attributes over time. In order to compute the particle attributes, these derivative functions must be integrated. Since closed form integration doesn't make sense for most actions, Euler's method is used instead. Euler's method is simply the method just described - the evaluation of the derivative functions at a particular time and then incrementing the current particle values by these derivative results times dt. In Euler's method, the smaller the dt, the more accurate the results.

This is shorthand for pVelocityD(PDPoint, x, y, z).

This is shorthand for pVertexBD(PDPoint, x, y, z).

Set the domain from which the positionB of each particle will be randomly chosen when it is created. But if pVertexBTracks is set to true (the default), then the positionB will instead be the same as the initial particle position.

Specify how the positionB of each new particle emitted will be chosen. The positionB is the destination position or initial position of particles. See pRestore for a use of positionB.

If doCopy is true then when a particle is created its positionB will be the same as its initial particle position (the default).

If doCopy is false then when a particle is created its positionB will be chosen from the VertexB domain.

Actions modify the position, color, velocity, size, age, and secondary position of particles. All actions apply to the current particle group, as set by pCurrentGroup.

Remember that the amount of effect of an action call depends on the time step size, dt, as set by pTimeStep. See pTimeStep for an explanation of time steps.

Particles are tested to see whether they will pass from being outside the specified domain to being inside it if the next pMove action were to occur now. If they would pass through the surface of the domain, they are instead bounced off it. That is, their velocity vector is decomposed into components normal to the surface and tangent to the surface. The direction of the normal component is reversed, and the components are recomposed into a new velocity heading away from the surface.

The normal component is multiplied by the resilience parameter and the tangential component, if its magnitude is greater than cutoff, is multiplied by (1 - the friction parameter) when being composed into the new velocity vector.

The cutoff parameter can allow particles to glide smoothly along a surface without sticking.

If copy_pos is true, sets the positionB of each particle in the current particle group to be equal to the current position of that particle. This makes each particle "remember" this position so it can later return to it using pRestore. If copy_vel is true, sets the velocityB of each particle in the current particle group to be equal to the current velocity of that particle. This is useful for computing the orientation of the particle when rendering it using pDrawGroupl.

If a particle's velocity magnitude is within vlow and vhigh, then multiply each component of the velocity by the respective damping constant. Typically, the three components of damping will have the same value.

Causes an explosion by accelerating all particles away from the center. Particles in the shock wave are accelerated away from the center by an amount proportional to magnitude. As with most acceleration actions, the amount of acceleration falls off inversely with (r^2). But when r is small, the acceleration would be infinite, so epsilon is always added to r.

The shock wave of the explosion travels outward from the center at the specified velocity. The shock wave has a thickness of lifetime, which is the amount of time for which the shock wave will affect any piece of space.

age is used to calculate the radius of the shock wave. For pExplosion calls in action lists, age is the initial age of the explosion. It is incremented by dt after each call. For immediate mode, age is the current age of the explosion, and it is up to the application to increment the age parameter for each call to pExlosion.

This allows snaky effects where the particles follow each other. Each particle is accelerated toward the next particle in the group by an amount proportional to grav. As with most acceleration actions, the amount of acceleration falls off inversely with (r^2). But when r is small, the acceleration would be infinite, so epsilon is always added to r.

Each particle is accelerated toward each other particle in the group by an amount proportional to grav. As with most acceleration actions, the amount of acceleration falls off inversely with (r^2). But when r is small, the acceleration would be infinite, so epsilon is always added to r.

The gravity acceleration vector is simply added to the velocity vector of each particle at each time step. The magnitude of the gravity vector is the acceleration due to gravity. For example, pGravity(0, 0, -9.8) specifies gravity in the negative Z direction.

For each particle, chooses an acceleration vector from the domain and applies it to the particle's velocity. The amount of acceleration applied is directly proportional to grav. As with most acceleration actions, the amount of acceleration falls off inversely with (r^2). But when r is small, the acceleration would be infinite, so epsilon is always added to r.

The domain from which acceleration vectors are chosen is the current velocity domain.

maxRadius defines the sphere of influence of this action. No particle further than maxRadius from the center is affected.

Removes all particles older than ageLimit. But if kill_less_than is true, it instead removes all particles newer than ageLimit. ageLimit is not clamped, so negative values are ok. This can be used in conjunction with pStartingAge(-n) to create and then kill a particular set of particles.

Removes all particles whose velocity magnitudes are less than speedLimit. But if kill_less_than is false, it instead removes all particles whose velocity magnitudes are faster than speedLimit.

This action actually updates the particle positions by adding the current velocity to the current position. This is typically the last particle action performed in an iteration of a particle simulation, and typically only occurs once per action list.

The velocity is multiplied by the time step length, dt, before being added to the position. This implements Euler's method of numerical integration with a constant, but specifiable step size. See pTimeStep for more on varying the step size.

p and axis define an infinite line, where p can be any point on the line and axis is any vector parallel to the line. For each particle, this action computes the vector to the closest point on the line, and accelerates the particle in the vector direction. The amount of acceleration applied is directly proportional to grav. As with most acceleration actions, the amount of acceleration falls off inversely with (r^2). But when r is small, the acceleration would be infinite, so epsilon is always added to r.

maxRadius defines the infinite cylinder of influence of this action. No particle further than maxRadius from the line is affected.

For each particle, this action computes the vector to the center point, and accelerates the particle in the vector direction. The amount of acceleration applied is directly proportional to grav. As with most acceleration actions, the amount of acceleration falls off inversely with (r^2). But when r is small, the acceleration would be infinite, so epsilon is always added to r.

maxRadius defines the sphere of influence of this action. No particle further than maxRadius from the center is affected.

For each particle, chooses an acceleration vector from the specified domain and adds it to the particle's velocity.

Reducing the time step, dt, will make a higher probability of being near the original velocity after unit time. Smaller dt approach a normal distribution of velocity vectors instead of a square wave distribution.

For each particle, chooses a displacement vector from the specified domain and adds it to the particle's position.

Reducing the time step, dt, will make a higher probability of being near the original position after unit time. Smaller dt approach a normal distribution of particle positions instead of a square wave distribution.

For each particle, sets the particle's velocity vector to a random vector in the specified domain.

This function is not affected by dt. If you can think of an appropriate way for this to vary with dt, let me know.

Computes a new velocity for each particle that will make the particle arrive at its positionB at the specified amount of time in the future. The curved path that the particles take is a parametric quadratic. Once the specified amount of time has passed, the particles are clamped to their positionB and their velocities are set to 0 to freeze them in place.

If pRestore is called in immediate mode, it is the application's responsibility to decrease timeLeft by dt on each call. When in an action list, timeLeft gets decremented automatically.

The positionB attribute of each particle is typically the particle's position when it was created, or it can be specified within a domain. This is controlled by pVertexBTracks, pVertexB, and pVertexBD. The positionB can be set at any time to the particle's current position using the pCopyVertexB action.

If kill_inside is true, deletes all particles inside the given domain. If kill_inside is false, deletes all particles outside the given domain.

If kill_inside is true, deletes all particles whose velocity vectors are inside the given domain. If kill_inside is false, deletes all particles whose velocity vectors are outside the given domain.

Adds new particles to the current particle group. The particle positions are chosen from the given domain. The particle colors, sizes, initial ages, velocities, and secondary positions are chosen according to their current domains. See pColor, pColorD, pSize, pStartingAge, pVelocity, pVelocityD, pVertexB, pVertexBD, and pVertexBTracks.

When pSource is called within an action list, the particle attribute domains used are those that were current when the pSource command was called within the pNewActionList / pEndActionList block instead of when pCallActionList is called. Note that this is unlike OpenGL.

particleRate is the number of particles to add per unit time. If particleRate / dt is a fraction then pSource adjusts the number of particles to add during this time step so that the average number added per unit time is particleRate.

Modifies the color and alpha of each particle to be scale percent of the way closer to the specified color and alpha. scale is multiplied by dt before scaling the sizes. Thus, using smaller dt causes a slightly faster approach to the target color.

Modifies the size of each particle to be scale percent of the way closer to the specified destSize. This makes sizes grow asymptotically closer to the given size. scale is multiplied by dt before scaling the sizes. Thus, using smaller dt causes a slightly faster approach to the target size.

When called within a pNewActionList / pEndActionList block, this action is a shorthand for:

pSource(1, PDPoint, x, y, z).

However, when called in immediate mode, this action uses a slightly faster method to add a single particle to the current particle group. Also, when in immediate mode, exactly one particle will be added per call, instead of an average of 1 / dt particles being added. Particle attributes are chosen according to their current domains, as with pSource.

center and axis define an infinite line, where center represents the tip of the vortex and axis is any vector parallel to the line. All particles are rotated about the line by an amount theta = magnitude / (r^tightness), where r is the distance from the vortex tip to the particle, so particles closer to the tip are rotated faster.

maxRadius defines the sphere of influence of this action. No particle further than maxRadius from the vortex center is affected.

A particle group is first created using pGenParticleGroups, which will return the identifying number of the generated particle group. Unless otherwise specified, all other commands operate on the current particle group. You specify which group is current using pCurrentGroup. The maximum number of particles in the group is specified using pSetMaxParticles. The particle group is then acted upon using the functions listed in the Actions. Some actions will add particles to the particle group, and others will modify the particles in other ways. Typically, a series of actions will be applied to each particle group once (or more) per rendered frame. The particles are then actually drawn. This is similar to the process of rendering a display list in OpenGL, and should be done at the same stage of the application's execution as drawing geometry. To draw a particle group in OpenGL, the application calls one of the pDrawGroup functions. Alternatively, the application can get a copy of the particle data using pGetParticles and use it for other rendering or processing methods. When a particle group is no longer needed, it is deleted using pDeleteParticleGroups.

Copy particles from the specified particle group, p_group_num, to the current particle group. Only copy_count particles, starting with number index are copied. Of course, the number of particles actually copied is bounded by the available space in the current particle group, and the number of particles actually in the source particle group. The particles are added in order to the end of the current group. index is the index of the first particle in the source particle group to be copied.

Makes p_group_num be the current particle group to which all actions and commands apply.

Deletes p_group_count particle groups, with p_group_num being the particle group number of the first one. The groups must be numbered sequentially, and must all exist. This removes the specified particle groups from existence. It does not merely change the number of existing particles or the maximum size of the group.

Calls the given OpenGL display list, dlist, once for each particle in the particle group. The display list typically contains only geometry (glBegin / glEnd blocks). Before the display list is drawn for each particle, the OpenGL state is changed. First, the display list is translated to the particle's position. Next, if const_size is false, the matrix stack is modified to scale the display list by the particle's size. Then, if const_rotation is false, the matrix is rotated so that the display list's positive X axis points in the direction of the particle's velocity vector. Finally, if const_color is false, the OpenGL current color is set to the particle's color. If const_color is true, then the OpenGL current color is set only once before drawing any particles. If const_size is true, then no scaling is ever done. If const_rotation is true then no rotation is ever done. This is useful for symmetrical models such as spheres.

This is the fastest OpenGL-based method of drawing particles. The exact results depend on the OpenGL primitive type specified. When primitive equals GL_POINTS or any value other than GL_LINES, each particle becomes a single vertex in an OpenGL glBegin / glEnd block. For GL_LINES, each particle becomes a line specified by two vertices - the particle's position and the particle's position minus velocity, yielding a line in the direction that the particle is travelling.

Generates p_group_count new particle groups and returns the particle group number of the first one. The groups are numbered sequentially, beginning with the number returned. Each particle group is set to have at most max_particles particles. Call pSetMaxParticles to change this.

Particle group numbers of groups that have been deleted (using pDeleteParticleGroups) may be reused by pGenParticleGroups.

What the summary says.

Copies count particles beginning with the index-th particle in the current particle group into application memory.

If necessary, this will delete particles from the end of the particle group, but no other particles will be deleted.

These calls create and operate on action lists, which are scripts of many actions to be applied together as a block to the current particle group. An action list is first created using pGenActionLists, and is then defined by calling particle action functions between a call to pNewActionList and a call to pEndActionList. Once the action list is created, it is run via pCallActionList. Thus, an action list is sort of a higher-level action. Complex behaviors can be stored in an action list and then called later, even as part of another action list. Action lists cannot be edited. They can only be created or destroyed. To destroy an action list, call pDeleteActionLists.

Deletes action_list_count action lists, with action_list_num being the list number of the first one. The lists must be numbered sequentially, and must all exist. This removes the specified action lists from existence.

A Domain is a representation of a region of space. For example, the pSource action uses a domain to describe the volume in which a particle will be created. A random point within the domain is chosen as the initial position of the particle. The pSink and pBounce actions use domains to describe a volume in space for particles to die when they enter, or to bounce off, respectively.

Domains are also used to describe velocities. Picture the velocity vector as having its tail at the origin and its tip being in the domain.

Finally, domains can be used to describe colors. For drawing with OpenGL, the full color space is 0.0 -> 1.0 in the red, green, and blue axes. For example, the domain PDLine, 1, 0, 0, 1, 1, 0 will choose points on a line between red and yellow. Points outside the 0.0 -> 1.0 range will not be clamped, but eventually will be clamped deep within the OpenGL pipeline.

Since data from particle systems can be used by more than just the OpenGL renderer, the floating point triple used for color can mean different things to different consumers of the data. For example, if a software renderer used colors on the range 0 -> 255, the domain used to choose the colors can be on that range. The color space does not even need to be thought of as RGB, but will be for use in OpenGL.

Several types of domains can be specified. The two basic abstract operations on a domain are Generate, which returns a random point in the domain, and Within, which tells whether a given point is within the domain. Functions such as pSource that take a domain as an argument take it in the form of a PDomainEnum, followed by nine floats. The PDomainEnum is one of the symbolic constants listed below, such as PDPoint. The nine floats mean different things for each type of domain, as described below. Not all domains require all nine floats. You only need to specify the first few values that are relevant to that domain type.

PDPoint x, y, z

This domain is a single point.

Generate always returns this point. Within always returns false.

PDLine x1, y1, z1, x2, y2, z2

These are the endpoints of a line segment.

Generate returns a random point on this segment. Within always returns false.

PDTriangle x0, y0, z0, x1, y1, z1, x2, y2, z2

These are the vertices of a triangle. The triangle can be used to define an arbitrary geometrical model and bounce particles off it, generate particles on its surface (and explode them), etc.

Generate returns a random point in the triangle. Within always returns false. [This must eventually change so we can sink particles that enter/exit a model. Suggestions?]

PDPlane ox, oy, oz, ux, uy, uz, vx, vy, vz

The point o is a point on the plane. u and v are (non-parallel) basis vectors in the plane. They don't need to be normal or orthogonal.

Generate returns a random point in the diamond-shaped patch whose corners are o, o+u, o+u+v, and o+v. Within returns true if the point is in the positive half-space of the plane (in the plane or on the side that the normal (u cross v) points to).

PDBox x1, y1, z1, x2, y2, z2

These are the minima and maxima of an axis-aligned box. It doesn't matter which of each coordinate is min and which is max.

Generate returns a random point in this box. Within returns true if the point is in the box.

PDSphere ox, oy, oz, radius1, radius2 = 0.0

The point o is the center of the sphere. radius1 is the outer radius of the shell and radius2 is the inner radius.

Generate returns a random point in the thick shell at a distance between radius1 to radius2 from point o. If radius2 is 0, then it is the whole sphere. Within returns true if the point lies within the thick shell at a distance between radius1 to radius2 from point o.

PDCylinder x1, y1, z1, x2, y2, z2, radius1, radius2 = 0.0

The two points are the endpoints of the axis of the cylinder. radius1 is the outer radius, and radius2 is the inner radius for a cylindrical shell. radius2 = 0 for a solid cylinder with no empty space in the middle.

Generate returns a random point in the cylindrical shell. Within returns true if the point is within the cylindrical shell.

PDCone x1, y1, z1, x2, y2, z2, radius1, radius2 = 0.0

The first point is the apex of the cone and the second is the other endpoint of the axis of the cone. radius1 is the radius of the base of the cone. radius2 is the radius of the base of a cone to subtract from the first cone to create a conical shell. This is similar to the cylindrical shell, which can be thought of as a large cylinder with a smaller cylinder subtracted from the middle. Both cones share the same apex and axis, which implies that the thickness of the conical shell tapers to 0 at the apex. radius2 = 0 for a solid cone with no empty space in the middle.

Generate returns a random point in the conical shell. Within returns true if a point is within the conical shell.

PDBlob x, y, z, stdev

The point x, y, z is the center of a normal probability density of standard deviation stdev. The density is radially symmetrical. The blob domain allows for some very natural-looking effects because there is no sharp, artificial-looking boundary at the edge of the domain.

Generate returns a point with normal probability density. Within has a probability of returning true equal to the probability density at the specified point.

Jonathan Leech and Russell M. Taylor II, "Interactive Modeling Using Particle Systems", Proceedings of the 2nd Conference on Discrete Element Methods, MIT, spring 1993, pp. 105-116.

Thanks to Mark Allen of NASA Ames Research Center for finding bugs, making suggestions and implementing the particle length attribute.

Thanks to Jason Pratt of CMU Stage 3 research group (makers of ALICE) for adding the PDTriangle domain. This is a powerful feature that should have been there the whole time.

Add a centralize flag to explosion

For the pspray demo, have it randomly change modes occasionally.

Explosion should not be scaled by dt since it usually hits for only an instant.

Explosion wave should be gaussian instead of square wave.

Test multiple particle groups better.

Resolve issues commented with "XXX".

Change pDraw* const_ to apply_, reverse the sense of it, and make it so if false, color isn’t touched.

Const_size isn’t used in pDrawGroupp.

Add a TOC listing all functions.

Replace the lifetime parameter of explosions with stdev and make the shock wave be gaussian instead of square. This will fix the ugly quantization effects in explosions of very dense particle clouds.

Obstacle avoidance action – this requires more thinking about object definition. Can this be done with domains?

Interpolate to a given velocity (like color and size interp)

Match velocity to near neighbors

// The above three actions will allow implementation of Craig Reynolds’ Boids algorithm.

pVelocityColor - color is f( velocity)

pPositionColor - color is f (position)

pDensityColor - color is f (density)

pRandomColor - random domain is added to color

pVelocitySize - size is f(velocity)