What's the most efficient approach to multiple emitters on a scene?

[carlos.lunetta]

Hello all!

I have a question regarding what would be the best practice/most
efficient method regarding having multiple emitters in a given scene.

Each emitter has its own clock, properties and sprites; the renderer
(DisplayObjectRenderer) and container can be the same one though.

What is the best idea?

- They all share the same renderer and container
- They all share only the container
- Each emitter with its own container

Thanks for any feedback!

[Allen Chou]

Basically, if all emitters share the same renderer, they are sharing the same container, since the container is generally determined solely by the renderer.

If this is the case, then you have more aspects to be considered to determine "if it is REALLY necessary to create multiple emitters."

There are some classes at your disposal that can combine multiple initializers and actions. So if you find it easier to factor out common initializers and actions using these classes, you might want to reduce the number of emitters to just one.

Particle masking is your friend for initializer and action factoring. The Mask initializer assigns a newly create particle an integer mask value, 1 by default. A particle is affected by an action only if the BITWISE AND value of the mask values of the particle and the actions is NONZERO.

The CompositeInitializer and CompositeAction classes pack together multiple initializers and actions, respectively. You may pack actions that are common to all particles in to a composite action, and assign the action a mask value that covers all particles. And you may pack some specific action that affects particles with certain mask values into another composite action, and assign a specific mask value to that composite action.

The SwitchInitializer chooses just one initializer from an array of initializers to initialize a newly created particle. You can combine this class with composite initializers to create an effect that particles are initialized by different set of initializers randomly. You can make use of the switch initializer to initialize particles with different mask values, different position, or even different display object classes, all done in a single emitter.

The resource cost of using just one single emitter is generally lower than using multiple emitters. You only use multiple emitters when you really cannot factor out common particle properties and behaviors using the special initializers and actions mentioned above.

As for the case of each emitter having its own container, yes, just use multiple emitters as you see fit, since each renderer can generally refer to one container.

[carlos.lunetta]

Hi Allen!

In my case, the scene has groups of particles with different clock
settings, sprites and asynchronous (user triggered) start actions - I
guess it's not viable to solve it with initializers/actions...

Thanks for the explanations!

[Allen Chou]

Yeah, if your have difficulty in factoring your initializers and actions, simply don't bother trying to squeeze everything into one single emitter. Just use multiple emitters.

[carlos.lunetta]

The problem I'm having is that every time multiple emitters are in
place, things freeze... pointing to the emitter.step();

at idv.cjcat.stardust.common.particles::ParticleListIterator/next()
at idv.cjcat.stardust.common.emitters::Emitter/removeDeadParticles()
[D:\as3Classes\stardust\src\idv\cjcat\stardust\common\emitters
\Emitter.as:277]
at idv.cjcat.stardust.common.emitters::Emitter/step()[D:\as3Classes
\stardust\src\idv\cjcat\stardust\common\emitters\Emitter.as:151]
at ParticleLayer/__mainLoop()

Any ideas why would this happen? I'm using a separate renderer/
container for each emitter... Is there any static property on the
emitter that may get scrambled?

[Allen Chou]

Ah, that's a bug discovered not long ago. Check out the SVN repository. The problem is fixed in the latest revision. I'll upload the latest revision to the Download section as soon as possible.

[carlos.lunetta]

It fixed it!
Thanks a lot Allen, you're the best!

[carlos.lunetta]

Strange, it won't freeze or send any error messages - but the
particles don't clear out; as soon as a new object is created (with
new emitter, renderer, container) the old one freezes as is, and the
new one starts to work. Any ideas?

[carlos.lunetta]

oops, nevermind. It had to do with the naming of the new instances
(they must be different!)
Thanks again and sorry for the hassle!

[Allen Chou]

Okay...it DID panicked me. Glad you've found the solution :)
The latest revisoin, 1.1.138 Beta, is now available in the download list.
http://code.google.com/p/stardust-particle-engine/downloads/list

[carlos.lunetta]

On a further investigation of the issue I had before, I found out that
if I use a unnamed object, or a static method, or a dictionary with
weak references, apparently the object gets GC'ed before all particles
are cleared from screen.

If I use an array to store the objects, a dictionary with strong
references or unique vars, all works. If I delete them after all
particles are removed, all works fine too, it gets GC'ed.

But this is not anything alarming, just a notice that there may be
some trouble with unnamed particle instances (an instance of the whole
engine, renderer, container, emitter, all the works)

[Allen Chou]

Hey, thanks for the info. It sure is something that needs to be considered while constructing particle systems :)