Introduction

Particle systems are used to simulate fluids, clouds, fire, smoke and many other environmental effects. They are not affected by aliasing problems and help generally to reduce it in a typical game scene.

Particle interaction is a very difficult task that is not often even targeted for accomplishing. Without it particles are treated separately making the simulation available for parallel computation. Hence, KRI particle system engine is designed to work on GPU only.

Elements

• Particle: a small piece of the world. It's usually drawn as a primitive (triangle or quad) in polygonal engines. KRI uses point sprites to draw particles, reducing the vertex processing amount, but opening some problems with spatial transformations.

• Attribute: a property that each particle in a system has, such as Position, Speed & Acceleration.

• Emitter: a particle source object, can be a point (a spatial node), a line (mesh edges), a mesh surface or even a 3d volume in space.

• Behavior: a rule to change particle attributes over time, including the death signal. In KRI behaviors may carry their own attributes and responsible for setting up initial attribute values on particle birth event.

• Manager: a group of emitters, which share the same list of behaviors and attributes, and all the particles emitted by them and living at the moment.

Manager

Particle manager serves as coordinator for a set of identical particle emitters. It contains the actual GLSL programs used for particle processing tasks (init, update). Hence, each emitter that linked to a single manager has the same set of behaviors.

The manager and each emitter contain a copy of the particle data block. When the emitter's data is updated, the manager's block is a data stream destination, while the emitter's block is the source. After processing, the emitter swaps his data block with the manager, storing the most recent copy. Manager's block serves as a temporary storage.

Particle task

The particle task instance contains of the following data:

• root shader: the one with a main function defined
• extra shaders: feature-implementing and behavior shaders
• method dictionary: information about methods that have to be extracted from the behaviors and linked to the root

Hair kit

Hair is built by a special particle system array, each representing a particular level of the fur blade. Each level's processing uses 2 previous levels data in order to reconstruct blade's base, ending and derivation. For the first 2 levels this data is artificially translated from the surface properties, that are the base for hair. This surface data is generated by a separate render (based on the hair tag existence) and contains the world space position & orientation.

Layers are stored & updated individually as particle systems and doesn't relate to each other from the user's perspective. They are loaded in the order of the increasing length, which guarantees proper updating and drawing (in the case of alpha samples).

For drawing, several renders exist: baking into the light map and applying the light. Both generate lines or triangles for each layer, building the continuous fur blade.

For updating the standard behaviors can be used (gravity, damping) as well as special ones: fur_bend (bend), fur_norm (normalize) and fur_main (advance position).

Native loader recognizes hair particles and loads them correctly. All you need to use them is just provide a proper export and fill up the render stack.

Conclusion

The proposed particle engine allows the processing of thousands of particles per frame, using the combination of different emitters and behaviors at a time.