best method for a particle system?

[deepthought]

i want t create a particle system for explosions and trails and other effects. question is,  how should i store my particles? it seems like a bad idea to use classes. maybe should i use a 2 dimensional array, one dimension is the particle, the second is which attribute?

[philfrei]

it seems like a bad idea to use classes.

Why?

[namrog84]

I just had assumed youd make a Particle class
give it some functions/properities like location, direction,  fade out,  velocity, lifetime(till death),  grow/shrink

then somewhere particle generator just make a ton of them

then apply other effects like wind/gravity to them

There is no reason you cant generate an array or list of some sort with thousands of particles in it.

Because they typically dont collide or interact with many other things directly, they shouldn't have a huge performance hit? Or that's what I thought.  They are basically just basic simple moving sprites/images.  in a JGO sprite battle they could have something like 100k+ images colliding/bouncing around on the screen, with the best one and plenty with 10k-50k.

Games published by our own members! Check 'em out!

[pitbuller]

Use pooling. Classes are fine if you dont create and destroy them whole the time.

[theagentd]

I recently experimented with particle systems. With 250.000 particles I get 62 FPS on a laptop with an i5-2410M and a Geforce GTX 460M.
 - Lifetime of 100 frames.
 - Gravity and fake air resistance.
 - Bounds checking to bounce particles on window edges.
 - They are drawn drawn as colored smoothed points.

Using a glPointSize up to 12 or 13, my test is CPU bottlenecked. The slowest part is actually filling the data buffer with particle positions+colors to submit using glBufferData, as it involves calls to native functions. Also, by load balancing between 4 threads (I have a dualcore with hyperthreading) I get a 2.2x performance boost (28 fps with one thread). I use pooling. NOT using pooling is actually faster by a pretty large margin, but produces HUGE hitches due to the GC.
Basically, if you only want a few thousand particles you shouldn't really worry much.

[Rejechted]

I recently experimented with particle systems. With 250.000 particles I get 62 FPS on a laptop with an i5-2410M and a Geforce GTX 460M.
 - Lifetime of 100 frames.
 - Gravity and fake air resistance.
 - Bounds checking to bounce particles on window edges.
 - They are drawn drawn as colored smoothed points.

Using a glPointSize up to 12 or 13, my test is CPU bottlenecked. The slowest part is actually filling the data buffer with particle positions+colors to submit using glBufferData, as it involves calls to native functions. Also, by load balancing between 4 threads (I have a dualcore with hyperthreading) I get a 2.2x performance boost (28 fps with one thread). I use pooling. NOT using pooling is actually faster by a pretty large margin, but produces HUGE hitches due to the GC.
Basically, if you only want a few thousand particles you shouldn't really worry much.

I assume this is a lot slower if you are drawing textured quads instead of points.  What do you mean by the GC?

[Orangy Tang]

Are you rendering large GL_POINTs? Those have never been fast in my experience, textured quads would almost certainly be faster.

IMHO big particle systems should be done with vertex shaders, so you can just feed static data to be drawn. Dead easy for simple ones, and you can even add some basic collision/interaction.

Complicated particle systems that require lots of interaction or elaborate physics are probably best done on the CPU still, but I generally find these kind of system require much less particles so they're less heavy. Combining the two will get great results, eg. an explosion could be a big smoke effect (done on GPU) along with a handful of smaller sparks/embers (done on CPU with world collision).