Thoughts about Spritesheet particles?

[st3v0]

At the moment this particle emitter supports picking a random texture from the textures array every time it wants to draw a particle on the screen. What about adding an enhancement where we could also list an object which is a collection of textures which plays like a spritesheet on the particle, for example;

var emitter = new PIXI.particles.Emitter(
    container,

    // The collection of particle images to use
    [
           // We could allow mixing of static and spritesheet particle textures...
            PIXI.Texture.fromImage('image.jpg'),
            // Here we add the spritesheet animation for a particle
            {
                frames: [
                    PIXI.Texture.fromImage('frame-1.jpg'),
                    PIXI.Texture.fromImage('frame-2.jpg'),
                    PIXI.Texture.fromImage('frame-3.jpg'),
                    ...etc,
                ],
                fps: 30 // default to 60 if not supplied
            }
        ],

    // Emitter configuration
    {...}
);

The particle still obeys the same config settings as all other particles, however it's texture is pulled from the frames based on its elapsed lifetime. Using the fps and frames.length its easy to calculate the duration of the animation in seconds.

duration = frames.length / fps

From this we can calculate the exact frame which should be displayed at any elapsed time, ie.

texture = frames[ ((elapsedSecs % duration) * fps) >> 0 ]

So if the particle has existed for 13.4 seconds and it's duration is 4 secs (120 frames @ 30fps) ((13.4 % 4) * 30) >> 0 = 42nd frame This means the animation will just loop forever or until it's destroyed

Then as you position, scale, ...etc the particle you just set its texture also if more then 1 was declared for the particle.

The only reason I bring this up is because our artist want to be able to create particles which have animation like for example a 3D flipping coin.

[andrewstart]

See AnimatedParticle. One of the examples for it is even flipping coins - https://pixijs.github.io/pixi-particles/examples/coins.html

[st3v0]

Cool, I must have overlooked that somehow. However it looks like it's not possible to mix particle types, is that right? I also now see you have a PathParticle. Would it not be better to combine all these into a single particle (not literally of course) I mean have the ability to define an emitter which has a mix of some static particles, and animated particles all of which use a defined path, or a bespoke path defined per particle?

[andrewstart]

Correct - one particle type per emitter so that particles can be cleanly recycled, and have less branching in the emitter. Use multiple emitters to have multiple types of particles going from the same location.

Because path following and animation are slightly more complex and many emitters don't need them, I want base particles to not have that code for performance reasons. I could however see reworking the subclasses into behaviors that could be combined (base particle + path behavior + animation behavior). Doing so would make it a little easier to add custom behaviors as well.

Having a unique path per particle, in the current system, would require making a copy of the PathParticle class and in the init() function generate a path for that particle.

[andrewstart]

Paths & animations can finally be combined with release 5.0.0