Hi,

I'd like to hear your opinions on my particle system. Not so much the rendering (basic directx instanced particles, cpu side for now, I'll move everything to gpu soon), but more about the idea behind spawning, movement, and physics.

My first particle system was crappy and hard to use, so I decided that I want a modular, easy to use particle system that allows me to render everything from smoke to snow to dust without having to create unique classes for different types of particles. What I came up with is a particle system that, aside from different parameters like position and texture, has 4 components:

- SPAWN: These components, all structs that inherit from the struct SPAWN, are used for spawning particles in certain volumes. SPAWN has a virtual GetPosition()-method that returns a random point inside that given volume. Volumes are point, AABB, sphere, cone, etc... On particle creation & resetting (no complete erasure & reallocation of particles) that method is called and the particle is placed.

- MOVE: The MOVE-structs all have a method called GetDirection(), inherited just like the spawn-components. They determine in which direction and how fast the particles move on creation and resetting. Some types are line, sphere, cone. The GetDirection()-method doesn't return a random point inside the volume as the movement-vector, but determines a direction from a random point inside the volume, and then caluclates a random strenght between two given values StrenghtMin and StrenghtMax.

- VOLUME: These structs, restrict particle movement. If particle exits the volume, it gets reset, therefor these structs only have a method GetInside(Point) which tests if a particle is inside. These are just 3d shapes while SPAWN and MOVE can also be 2d like circle..

- FORCE_FIELD: These are very experimentual. I'm trying to have different force field types like point, plane, etc, that adds forces to particles. Each field has 3 components on its own:

- VOLUME: Same as for the emitters volume, but here its used to determine if a particle should be affected by the force field.

- STRENGHT: Used to determine the strenght of the force based on the particles distance to the force field. For now there is only one struct, STRENGHT_LINEAR, which interpolates the distance between ForceMin and ForceMax given DistMin (lower dist always return ForceMax) and DistMax (greater dist always returns ForceMin). Has the method GetStrenght().

- DIRECTION: Determines the direction of the force. For now there is just DIRECTION_LINE and DIRECTION_LINEFROM (which uses the direction from the volume to the particle as force direction), but I am not really restricted. I could have sinus waves, turbulence, etc.. The method for this component is GetDirection().

Based on these 3 components, the forcefield generates a force for a particle. If it is inside the volume, strenght and direction are multiplyed and returned.

So, what do you say? I'm really satisfied with that, because it works just as I expected. Although my physics handling is very primitive, I managed to have explosions, snow, rain, a wall of fire, a flamethrower, smoke, and many more just by adjusting some settings. However I would like to know what you think about it. Would you want to use such a particle system in your project? Is it a practical approach or just a beginners choice of how to handle particle systems? I see more pro's than conts:

pros:
- easy to use (using helper functions you need 8 function calls to set up a emitter with all parameters, and a force field
- allows a wide range of particle types
- user could easily write own types for movement, spawing, etc..
- straightforward to choose spawn/movement/.. type, no screwing around with obscure parameters to see what happens

cons:
- a lot of virtual calls on particle creation/resetting (though I don't know if thas a huge problem, removing virtual didn't increased performance much for 20000 particles on my pc)
- it has to be clear which type of component will be used (every component has a non-virtual SetProperties()-method, therefor you can't just create a SPAWN-instance, but have to create SPAWN_AABB and call SetProperties() if you want a AAAB to spawn particles. Again, I'm not really sure if this is a problem, using helper functions you don't even have to care about that part.

Any opinions? Maybe some issues I overlooked, or something I could improve? I already got everything coded out, so if someone is interested, I could post a demo application with some source code, or maybe a runtime-libary (but first I want to finish moving the whole thing to the gpu for performance-sake, only being able to render 100k particle on a C2D E8400 before the game starts going slow-mo isn't that great, I figured).

Similarly, we have implemented a particle system like mentioned above: effect, list of emitters and particles for each emitter. Effect is basically a render object and emitter holder. An emitter as the name implies, defines where and how are particles created. A particle is a point in space with direction velocity, color, texture info, etc...

Both emitter data and particle data have a bunch of evaluators (line/curve editor), which are driven with emitter/particle life, ie: size, color, alpha, velocity, gravity, etc... To get better re-usability, we've added "instance data", so that some specific options are not set (locked) on data, but there where data is used (ie: when emitter data is linked under effect data, an emitter instance data slot is created, under which the emitter data is linked).

Biggest problem we reached was when we tried to create fireworks effect - where a "particle" is also an emitter. We had to add the concept of child emitters. On a particle data we define a new emitter data link, and it's "active evaluator". This defines when the child emitter will be active in accordance to particle life. This way we can nest as much as wanted, but for sanity, memory and performance reasons the depth is limited to 3.

Each emitter can also hold various engine objects like lights, flares, sounds, etc... whose properties can be also evaluated (ie: light color, intensity and range).

The editor is written with inhouse UI (sadly ), and the system is job friendly.


edit: current biggest wish by designers is ability to animate particle movement, so they can create fancy movement like spiral, tornado, etc.. we are probably just going to import animation keyframes from an external tool (ie: maya), and interpolate particle movement based on that. note, that this will be just the "base" particle position, something like:
newpos += animationdelta + (velocity * dt)
so that you can still modify the particle movement even if particle movement is animated

[quote name='zfvesoljc' timestamp='1321372267' post='4884195']
edit: current biggest wish by designers is ability to animate particle movement, so they can create fancy movement like spiral, tornado, etc.. we are probably just going to import animation keyframes from an external tool (ie: maya), and interpolate particle movement based on that. note, that this will be just the "base" particle position, something like:
newpos += animationdelta + (velocity * dt)
so that you can still modify the particle movement even if particle movement is animated

Just add paths that can be emitted for particles to follow, and have a setting that adjusts how much the particles can deviate from the path.
A path can be a bezier curve or a more efficient series of connected line segments.
[/quote]

Line segments were something I was aiming at with keyframes. But I still have to use progressive update with position delta, since particles are dynamic - their behaviour can be affected by outside forces and even collisions. ie: a wind tornado like effect can be "pushed away" when a nearby explosion goes off and spawns a temporary force area (spherical), particles gain extra inertia, the "tornado" particle movement paths get disrupted, but as the inertia falls of, they start resuming their animated path again.

Sorry if it was already mentioned but for those curious, what engine would that be? You say it's commercial but I don't see a link if anyone were curious as to the full feature set and cost.