Hello,

I've been doing some research on particle system design lately and am curious how a "channel" based particle system is implemented. The only description I can find is just about how it saves space by allowing particles to not hold data they don't need for their system.

Actually, the only two references to this type of system I can find are http://bit.ly/qoUdIt and http://bit.ly/ouFNHV .

Is it actually called something else normally?

Thank you.

What they are describing is similar to multiple audio tracks overlayed to produce a final product.

So a laser burning a wall would be:

Channel A: sparks effects
Channel B: Beam effects
Channel C: Smoke effects
Chnnel D: Hot spot overlay blended onto wall surface

For a channel based system, you are building heirarchies of control where you can selectively disable entire groups from rendering. The particles themselves in this case are just triangle stripped quads.
so it can be like

Particle System Manager:
particle Top level controller
Particle effect controller
Particle effect controller
particle effect controller
particle Top Level controller
...


Then you could register each effect controller within groups like above, BEAMS, SPARKS, SMOKE (using enum bitflags)
then you could selectively disable groups of particle controllers across all particle systems

many games use this for audio with voice, sfx, music channels with their own amplitude sliders. When a sound is to be played, it's sent along with a channel tag for proper volume adjustment.

make that, the particles render side are triangle stripped quads. The particles will probably need lifetime value, velocity, position for the controller to use in path and brightness/blending determination.

You could make a very powerful system here that could even selectively disable groups of effects for different preset Game Detail levels in an options menu.

[font=arial, verdana, tahoma, sans-serif][size=2]
Thank you for your input so far. I feel my brain juices flowing faster already.[/font]

I can think of a few ways of implementing "allowing particles to not hold data they don't need for their system", one of which being to have several parrallel arrays, one main array for data all particles have, and then seperate ones for each subtype of particle. The problem is, you would probably end up with branching in this situation, as you need to ask each particle which update functions it supports; maybe you can give each particle a single function pointer which you use to update that particle.

A better way of dealing with this is to have seperate arrays for each type of particle. This is what I do. I have particles which bounce off of things, which require a raycast (sparks, bits flying off my models) and particles which are only affected by gravity (fire, smoke). These go in two different object pools, each with a single update function for the entire pool.

Are you suggesting an entirely different particle structure for every situation?
I don't think I fully understand your implementation. Do you store say, a bounciness factor in your array for the types of particles that bounce? What happens when you want to add functionality from another pool that maybe uses bounciness.

I might sleep on this because I don't think I'm getting it, and I am pretty.... pretty.... pretty tired.

And I'm not sure how the implementations might work with data driven design. I would like to be able to parse a file and create a particle system.
I think I want something like http://developer.valvesoftware.com/wiki/Particle_System_Overview , but the way it is described in that article, it sounds like particles each store a mapping from type to data, which would be incredibly expensive. Some more system wide pools like you describe are definitely the way to go.

You could make a very powerful system here that could even selectively disable groups of effects for different preset Game Detail levels in an options menu.

That's a very interesting idea. I never considered different game detail levels.

A 'particle struct' is one way to do it, however from a performance point of view it isn't good as it prevent any sort of SIMD operations on the particles.

Instead in your emitter you reserve blocks of memory for each attribute of the particles you want (x, y, z, r, g, b, a for example) and then use SIMD instructions to perform the operations to animate/simulate the particle.

However if this is your first particle system you probably want to go with a struct to learn how to do it and then worry about SIMD related optimisations later.

A 'particle struct' is one way to do it, however from a performance point of view it isn't good as it prevent any sort of SIMD operations on the particles.

Instead in your emitter you reserve blocks of memory for each attribute of the particles you want (x, y, z, r, g, b, a for example) and then use SIMD instructions to perform the operations to animate/simulate the particle.

However if this is your first particle system you probably want to go with a struct to learn how to do it and then worry about SIMD related optimisations later.

[font=arial, verdana, tahoma, sans-serif][size=2]I'm designing for the iOS so I'm not concerned with SIMD right now. But I will keep that in mind.[/font][font=arial, verdana, tahoma, sans-serif][size=2]I think the only thing I really confused about with this system is how to manage the data for particles.[/font][font=arial, verdana, tahoma, sans-serif][size=2]Would I hold pointers to the available types in a particle group, and only allocate when adding a particle "operator" (taking from Valves terminology) that requires data not currently available?[/font]

I found a few more resources that might be worth sharing on the topic if anyone cares.
The Particle System 'Magical Box' uses a modular system for some parameters. I find their method to be too inconvenient though. It is described here.

Also, on the Blender site, a user describes a Modular Particle System, and includes (incomplete) source code. But this method seems too expensive. Found here.

A 'particle struct' is one way to do it, however from a performance point of view it isn't good as it prevent any sort of SIMD operations on the particles.
Instead in your emitter you reserve blocks of memory for attribute of the particles you want (x, y, z, r, g, b, a for example) and then use SIMD instructions to perform the operations to animate/simulate the particle.

However if this is your first particle system you probably want to go with a struct to learn how to do it and then worry about SIMD related optimisations later.

This is exactly what my first attempt at a particle system did. I had a struct to keep track of each particle's life, etc, but had a separate array just for vertex data. This system was also geared towards its devices, and I'd strongly recommend SIMD.
I haven't worked with ASM before, but I'd like to apply SIMD to my operations. Any ideas on how to learn how to write ASM for ARM CPUs for iPad 2? The vfpu libraries I've found online don't do the trick.

EDIT: I just realized that iOS 4 has the "Accelerate framework" available to us. I'll have to look at that and ifdef all my math operations.

[quote name='phantom' timestamp='1316635244' post='4864330']
A 'particle struct' is one way to do it, however from a performance point of view it isn't good as it prevent any sort of SIMD operations on the particles.
Instead in your emitter you reserve blocks of memory for attribute of the particles you want (x, y, z, r, g, b, a for example) and then use SIMD instructions to perform the operations to animate/simulate the particle.

However if this is your first particle system you probably want to go with a struct to learn how to do it and then worry about SIMD related optimisations later.

This is exactly what my first attempt at a particle system did. I had a struct to keep track of each particle's life, etc, but had a separate array just for vertex data. This system was also geared towards its devices, and I'd strongly recommend SIMD.
I haven't worked with ASM before, but I'd like to apply SIMD to my operations. Any ideas on how to learn how to write ASM for ARM CPUs for iPad 2? The vfpu libraries I've found online don't do the trick.

EDIT: I just realized that iOS 4 has the "Accelerate framework" available to us. I'll have to look at that and ifdef all my math operations.
[/quote]

I'm double posting to elaborate on this more. When I did my particle system, I called my class a "ParticleEmitter", which is accurate. Now, what I'm thinking about doing is making a ParticleSystem class that holds a list of ParticleEmitters. Emitters can emit particles from the particle system's position, from particle collisions made by other emitters, and each contain different properties. This would allow you to perform the laser simulation you were talking about earlier!

Here's the emitters you'd need to reproduce the described laser effect:
-Laser emitter spawning from the particle system's 3D position
-Smoke emitter spawning particles from the laser particles' collisions to a wall (can even base the color off the wall's material you're hitting)
-Decal emitter that simply places laser hole decals onto the wall which are spawned by laser particle collisions (not screen-aligned polygons, face the same way as the wall)
-Sparks emitter spawns particles from the laser's collision points, and bounce onto the brown, and burn out over time

I'm going to enhance my particle system to support something along these lines later tonight.