Click here to Skip to main content
Click here to Skip to main content
Technical Blog

Flexible Particle System - Start

, 14 Apr 2014 CPOL
Rate this:
Please Sign up or sign in to vote.
Flexible Particle System - Start
Particle System

Particle systems are awesome! Not only can you create amazing effects, but you can also optimize code and push even more and more pixels to the screen. This post series will cover how to design a flexible particle system and apply a bunch of optimizations to run it faster. Flexible means that it can be used in real applications and for a variety of graphics effects.

Introduction

For some time, I have been playing with my own little particle system. One previous post shows some effects that I was able to make using the system. Since that moment, I did not create any more effects, however I've spent this time on optimizations and improvements.

I would like to show you more, or say that I optimized the code by 100000%... but it is not that easy. Smile | :) Still I think it is valuable to share my current experience.
This post will cover the basics of the particle system and my assumptions.

Let's start!

The Series

Big Picture

What is needed to create a particle system:
Particle system components
  • Array of particles - We need some container to keep particles. Particles are dynamic things so we also need an efficient way of making a particle alive or dead. It seems that even std::vector is not enough for this purpose. Another thing is what data should one particle contain? Should we use Array of Struct (AoS) or maybe Struct of Arrays (SoA)?
  • Generators/emitters - They create (make alive) particles, set their initial parameters
  • Updaters - When a particle is alive, there has to be a system that updates it and manages its movements.
  • A renderer - Finally, we need a way to push all the data to the screen and render the whole system. Rendering particle system is an interesting topic on its own because there are lots of possible solutions and techniques.
And probably, that is all for a good start.

Stateless vs State Preserving Particle Systems

When implementing a particle system, it is important to notice that we can update particles in two ways:

Stateless Way

It means that we compute current position/data/state from initial values and we do not store this calculated state. Take a look at this simple movement equation used in a simple particle system:

pos = pos_start + vel_start*time + 0.5*acc*time*time;
This computed pos is used usually only for rendering. In the next frame, the time will change and thus we will get different value for pos.
Stateless particle system

Lots of graphics tutorials have such particle systems. It is especially visible as an example for vertex shaders. You can pass start data of particles to vertex shader and then update only time value. Looks nice, but it is hard to create advanced effects using such technique.

Pros

  • Simple to use, no additional data is needed, just start values
  • Very fast: Just create initial data, need to update particle buffer only when a particle is killed or born

Cons

  • Only for simple movement equations

State Preserving

As the name suggests, we will store the current state of particles. We will use previous state(s) to compute the current one. One of the most popular ways to do this is called Euler method:

vel = vel + delta_time * acc;
pos = pos + delta_time * vel;
State preserving particle system

Pros

  • Can be used to create advanced effects

Cons

  • Need a storage for internal/current state
  • More computations and updates needed than in stateless system
I will leave this topic, but it will come back when I show actual implementation of the system.

Assumptions/Requirements

What would I like to achieve with the system:

  • Usability - The whole system will not be just little experiment with some simple update loop, can be used to create several different effects.
  • Easy to extend - Different modules or option to create own parts.
  • Performance - Should be fast enough. This is quite a vague spec, but whole optimization part will be a great playground for testing new ideas.
    • I aim for at least 100k particles running smoothly (60fps) on my system. Would be nice to have 1M, but this will not be that easy on CPU version
  • CPU only - I know that currently GPU implementations are better, but for the experiment I choose CPU only. Maybe in the second version, I will rewrite it to OpenCL or OpenGL Compute Shaders.
    • CPU version also gives a chance to experiment with the CPU to GPU buffer transfers.
  • So far simple OpenGL 3.3+ renderer

What's Next

In the next article, I will write about particle data and its container used in the system.

Notes and Links

Here is a bunch of links and resources that helped me (or will help) in the implementation:

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Bartlomiej Filipek
Software Developer
Poland Poland
Software developer interested in creating great code and passionate about teaching.
 
Technologies I use(d): C++, C#, JavaScript, OpenGL, GLSL, DirectX, OpenCL, CUDA, Windows Api, MFC, Visual Studio and even HTML and CSS.
 
See my programming blog: www.bfilipek.com
Follow on   Twitter   Google+

Comments and Discussions

 
GeneralMy vote of 5 PinmemberIzackp18-Apr-14 4:34 
GeneralRe: My vote of 5 PinmemberBartlomiej Filipek18-Apr-14 4:52 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web01 | 2.8.150123.1 | Last Updated 14 Apr 2014
Article Copyright 2014 by Bartlomiej Filipek
Everything else Copyright © CodeProject, 1999-2015
Layout: fixed | fluid