Particle system

Hi,

I could not found a particle system, so I guess it is not available.
Could this be implemented? (Maybe take a look at SDL.Net->Particle*)

~ Agon

kanato
Posted - Tue, 07/29/2008 - 10:47

There is no particle system in AgateLib at the moment. I haven't really thought about doing one, although I wouldn't be against having one in there, if someone wanted to write one and contribute it. SDL's particle system seems like it would generate a lot of garbage for the GC to worry about, which at least with the current state of Mono's GC, could be a problem for running on Linux. So I'd like a particle system for AgateLib to be a little bit more smartly designed for a garbage collection system.

caeonosphere
Posted - Wed, 04/15/2009 - 20:00

I could also use this feature, if anyone's up to the job.

Tom

Agon
Posted - Thu, 04/16/2009 - 09:44

Well, I could try to hack a particle system together on the weekend.
Would be interesting and I could improve my math.

We could start with a list of what a particle system should be able to do.

Particle manager
Stores all particle emitters.

Particle emitter
Emits particles which are manipulated by particle manipulators.

Particle
Stores a surface or sprite and a (world/view/emitter?) position.

Particle manipulator
Manipulates the out put of particles by adjusting the speed, direction, fade out/in (transparency), color, (shader) ....

My experience with particle systems and graphic programming is low.

jblfireball
Posted - Thu, 04/16/2009 - 11:42

Those certainly are the main players. Would be a neat feature to have.

Jon

kanato
Posted - Fri, 04/17/2009 - 10:58

I would say, keep it simple at first, and just have the particle emitter and the particle classes. It sounds like the manager isn't much more than a List and the stuff in the manipulator could just as well be a part of the emitter, maybe as virtual functions so they could be overridden if desired.

Agon
Posted - Fri, 04/17/2009 - 11:34

I'm working now on the design concept of the particle system.
My goal is to have a particle system in 2D which is highly expandable.

Currently I have 4 classes:
ParticleSource:
Stores emitters. I think this is in other particle systems the emitter.

Emitter:
Emits copies of sample particles in one direction by a given speed. A emitter can be attached to a ParticleSource or a particle.

Particle:
Stores position, speed/direction, age and an image.

Manipulator:
Manipulates particles by applying the position to a math function like this:
y = sin(x) + y
Or any other way...

Emitters and manipulators are abstract classes which allows to create own emitters/manipulators.
For example a emitter could emit randomly in a loop 3 sample particles in a random direction and with a random speed.
A Manipulator forces the particles along a sinus wave.
One of the sample particles has a emitter attached which emits after a the particle life time of 3 seconds 10 copies of it self.

Agon
Posted - Fri, 04/17/2009 - 11:37

Well the manager or in my example above the ParticleSource is a class with a position, angle and a list of emitters.
You are right, I should start simple and implement first a simple particle class and an emitter.

Agon
Posted - Thu, 04/23/2009 - 06:42

I'm still working on the particle system and I'm making progress.

Should the life of a particle be counted down by each update to the particle (~each frame)
or through a timer?
Could a timer for each particle decrease the performance noticeable?

Has AgateLib a timer which counts down if Agate's core is alive and triggers an event then the timer reaches zero?

jblfireball
Posted - Sat, 04/25/2009 - 19:33

I'm no particle guru, but here are my two cents.

It seems like any way you do it, particles are always going to be at least a little bit costly.

I think a per-update ticker would be better, if a game loop is running slowly, chances are the game is also running slowly, and the particles should too. I suppose that depends on how the game is designed but a per-update seems more natural and synchronous.

Jon Leah

Agon
Posted - Fri, 05/08/2009 - 04:18

The current design is adjusted around update, draw methods and events for manipulators.
I did a test with 1000 pixel particles which get spawned in ~3 seconds and were manipulated by a GravityManipulator which increases there speed with each update.
So the particles were almost in movement. I got constant 59-60fps. Well, the algorithm to determine the new position of a particle was Euler which is really short and fast.
I will change the algorithm to Verlet time correct in future.
Means, the particle system is far from complete...

jblfireball
Posted - Sun, 05/10/2009 - 15:03

That's great news Agon! I see your branch and I'll check it out soon!

jblfireball
Posted - Sun, 05/10/2009 - 15:04

Posted Twice, my bad.

Agon
Posted - Fri, 05/15/2009 - 07:00

I need to warn you it is 100% experimental and the API/design will change for sure.
I will continue developing in the next 3 days.

Agon
Posted - Sun, 05/17/2009 - 12:00

I continued developing a bit and the result can be viewed in the attached picture.
Nothing spectacular, some pixel particles flying around.

In the demo there are two gravity manipulators, one changes the x direction each update and the other adds force to y.
I limited the particle amount which can be simulated by the pixel emitter to 1000 particles in the demo.
I'm still using the Euler method to update the position and velocity of the particle. I will change this in future because this method is not accurate.

Agon
Posted - Sun, 08/16/2009 - 04:17

Well Im continuing this one...
Some old news: I added surface particles. Added a fadeout manipulator. Optimized general particle handling.

Im working on sprite particles now. The Euler method will be kept since this is for visual feedback and not for physic simulation.

Agon
Posted - Thu, 09/17/2009 - 08:47

SpriteParticles and -Emitters are now working.

The complete ParticleSystem is really a basic system, nothing fancy.
If you want super fancy explosions you need to write some code lines.

To performance:
10.000 PixelParticle, ~50 SurfaceParticles and ~80 SpriteParticles are working but with lags.
The problem is with such a huge number of particle that hundreds of PixelParticles are reseted per update which takes time.
But normally in 2D you don't need 10.000 particles besides normally you use surface particles which are covering more pixel on the screen.

After all the particle system is basically finished and has some example manipulators.

I attached a screenshot of the current particle test while running.

Torrent
Posted - Fri, 02/19/2010 - 15:04

Where would I get your code. It sounds really cool, and I'd like to see what you've done.

I'm working on a fantasy style game, and something that could do limit magic-style effects could be useful.

kanato
Posted - Fri, 02/19/2010 - 15:29

The particle system is in the SVN head, which can be checked out with
svn co <a href="https://agate.svn.sourceforge.net/svnroot/agate/trunk" title="https://agate.svn.sourceforge.net/svnroot/agate/trunk">https://agate.svn.sourceforge.net/svnroot/agate/trunk</a> agate
or you can browse it here: http://agate.svn.sourceforge.net/viewvc/agate/trunk/AgateLib/Particles/