pixijs / particle-emitter Goto Github PK

Looking at the example and the implementation, I wonder if the definition here forparticleConstructor should be

public particleConstructor:typeof Particle;

instead of

public particleConstructor:(p:Particle, emitPosX:number, emitPosY:number, i:number)=>void;

When I try and use particleConstructor as per the example, it raises a type error

Type 'typeof PathParticle' provides no match for the signature '(p: Particle, emitPosX: number, emitPosY: number, i: number): void''

If you would be happy with this, let me know and I'll raise a PR

Right now ParticleUtils.getBlendMode is using blendModes as a default and will only fall back to BLEND_MODES if blendModes doesn't exist. As a result PIXI is throwing a deprecation warning. Hoping we can get rid of this unnecessary noise.

EDIT: After playing around a bit more, seems there are quite a lot of functions using deprecated API and doing the same as above. This hurts performance quite a bit as console.[anything kind of log] is extremely slow.

Hi!
First of all thanks for this project. It's awesome!
I have been trying to use your editor, but I can neither upload my own pictures nor download the code on Chrome (v 39.0.2171.71). However Firefox works.

Hello,
I have just started coding games please help in the following context. I want the emitter to emit 3 different types of particles the Documentation says use Texture Array, by doing so they only get emitted one after the other and not all mixed together. Can you suggest me a way?

None of the examples are working anymore, seems like the libs folder has gone AWOL.

setTexture is now deprecated, please use the texture property, e.g : sprite.texture = texture;

It says in every requestAnimationFrame().

PIXIv3 : v3.0.11
pixi-particles: v1.6.6

The starting color option and the end color option is not working.
I am using the white Pixel25px.png from the site.
How ever no matter that I set:
"color": {
"start": "1f62ff",
"end": "3d6aff"
},

It still shows only a horrible white pixel. Instead of a colored one.

Any help please?

Sorry to be such a noob at this, but as I've never worked with particles before this is all new to me! I've got 3 or 4 cool effects I'm using - 3 are burst type things that only run once when something happens, and 1 is an ongoing bubble generator that runs all of the time.

Do I need to do something to clean up the "run once" emitters? Is it ok to just keep creating them over and over again, or should I create them all in the beginning, and then start and stop them?

thanks in advance for any advice!

Trying this project out for a PIXIjs v4.3.0 project. I'm using pixi-particles 2.0.0.

I'm loading a rain system, taken from your interactive generator with some tweaks from the base config.

Following the example on the readme, I've initialized the emitter with my container and emitter config, set emit = true and am calling the update method.

Yet with just these few steps, it's breaking with the error:

Cannot read property 'x' of null:
node_modules/pixi-particles/dist/pixi-particles.js:1519
		var curX = this.ownerPos.x + this.spawnPos.x;

Here's an example of my class:

const rain = require('../particles/rain.json');

// Load pixi particles, which patches PIXI
require('pixi-particles/dist/pixi-particles');

module.exports = class Weather {
    constructor() {
        // Initialize a render container
        this.container = new PIXI.Container();

        this.emitter = this.initRainEmitter();

        PIXI.ticker.shared.add(this.tick, this);
    }

    initRainEmitter() {
        return new PIXI.particles.Emitter(this.container, rain);
    }

    start() {
        this.raining = true;
        this.emitter.emit = true;
    }

    tick(delta) {
        if (this.raining) {
            this.emitter.update(delta);
        }
    }
};

This class is then loaded in my game by a parent container, like this:

this.weather = new Weather();
this.container.addChild(this.weather.container);
this.weather.start();

Lastest version on NPM is v1.6.6

This looks really cool!

You should publish it on npm (probably as pixi-particles), and add it to the plugin list on our Wiki: https://github.com/pixijs/pixi.js/wiki/Pixi-v3-Plugins

Let me know if you need help setting up the npm stuff, don't mind making a PR for it.

Hey I need to change the rotational properties later on.

I've got 2 objects animating left and right, up and down.

I want to keep the emitter going from this X to that X, this Y to that Y.

How?

I've got emitter.updateOwnerPos() so far, but need more info on that function?

I'm running into an issue where I'm attempting to load the pixi-particles.js file that is downloaded via Bower, like so:

In package.json (setting up alias for browser):

"browser": {
  "pixi-particles": "./lib/pixi-particles/dist/pixi-particles.js"
  ...
}

In source file:

var PP = require('pixi-particles');

I'm receiving an error saying it cannot find the module. Is this enabled when using PixiParticles?

Thanks

I've been trying to create an imploding effect. Basically particles being creating in a circle spawn type and moving inwards toward the center. Is that current possible?

The documentation says for PIXI.particles.Emitter says the following:

// The PIXI.Container to put the emitter in
// if using blend modes, it's important to put this
// on top of a bitmap, and not use the root stage Container

I am using blendmodes, and things look great when the world is black, but when the particles render over brightly colored terrain, it looks awful. I understand the need to render the particles onto a separate bitmap and then render that bitmap onto the scene, but I'm unsure of how to do this.

Container has a "cacheAsBitmap", but that just takes a snapshot at a single instance in time.

I also tried passing in a RenderTexture to PIXI.particles.Emitter to no avail. It fails when trying to add children to the RenderTexture.

How do I back a Container by a bitmap?

When a particles acceleration is set, it would be handy if you didn't just reference the emitters acceleration but rather you used .clone() or set the x and y. This would allow some behaviours that give particles unique acceleration values.

Let me know what you think!

Hi!
It seems the editor is down (http://cloudkidstudio.github.io/PixiParticlesEditor/) :)

Spawn Type is it able to replace with a new type?

such as

var emitter = new PIXI.particles.Emitter();
emitter.spawner = ringSpawner;
emitter.spawner = pointSpawner;

Is there any way to tell an emitter to destroy itself once it's done (burst type of situation)?

Hi!
Just to tell you that I've just released wrappers of your lib for pixi.js related Haxe projects thanks to @adireddy (https://github.com/adireddy/haxe-pixi).
++

Thank you very much for all your work on this. It's really awesome. Apologies for the long explanation of the issue but i I tried to include as much details as I can.

I am working on a game and making use of PIXI and PIXI-Particles. It will be a mobile/tablet game wrapped in either Cordova/Crosswalk or Cocoon. At the moment I am using Cocoon's Canvas+(with screencanvas enabled). I am using PIXI-Particles to create an explosion animation.

The issue I have is the initial time it takes for PIXI-Particles emitter to work smoothly. The first time the emitter runs (the first explosion) it causes a massive frame-drop and the animation is laggy and slow. This gets better with the next run of the emitter, but still some lagging. After a few runs it works smoothly. Having said that, occasionally while playing the game the emitter animation(explosion) gets laggy.

I noticed that the emitter works well if the start/end color is set to "0xFFFFFF". Any other color(s) causes big lags on initial runs.

I had a look at the code for both PIXI and Particles. This is what I've found.

This removes endColor if it's the same as startColor.
https://github.com/pixijs/pixi-particles/blob/master/src/Emitter.js#L536

//if it's just one color, only use the start color
if (config.color.start != config.color.end)
{
  this.endColor = ParticleUtils.hexToRGB(config.color.end);
}
else
  this.endColor = null;

This prevents any color tinting operation if endColor is not set.
https://github.com/pixijs/pixi-particles/blob/master/src/Particle.js#L274

this._doColor = !!this.endColor;

And https://github.com/pixijs/pixi-particles/blob/master/src/Particle.js#L381

if (this._doColor)
	{
		var r = (this._eR - this._sR) * lerp + this._sR;
		var g = (this._eG - this._sG) * lerp + this._sG;
		var b = (this._eB - this._sB) * lerp + this._sB;
		this.tint = ParticleUtils.combineRGBComponents(r, g, b);
	}	

And when the particle Sprite is created, it's tint value is set to the startColor:
https://github.com/pixijs/pixi-particles/blob/master/src/Particle.js#L281

this.tint = ParticleUtils.combineRGBComponents(this._sR, this._sG, this._sB);

The sprite itself initially have a tint of 0xFFFFFF.
https://github.com/pixijs/pixi.js/blob/master/src/core/sprites/Sprite.js#L75

this.tint = 0xFFFFFF;

When the sprite is rendered, a tint is applied IF the Sprite object's tint IS NOT 0XFFFFFF:
https://github.com/pixijs/pixi.js/blob/dev/src/core/sprites/canvas/CanvasSpriteRenderer.js#L127

if (sprite.tint !== 0xFFFFFF)
            {
                 if (sprite.cachedTint !== sprite.tint)
                {
                    sprite.cachedTint = sprite.tint;
                    sprite.tintedTexture = CanvasTinter.getTintedTexture(sprite, sprite.tint);
                }
.
.
.

And the tinted Sprite is cached to speed things up.
https://github.com/pixijs/pixi.js/blob/dev/src/core/sprites/canvas/CanvasTinter.js#L28

        if (texture.tintCache[stringColor])
        {
            return texture.tintCache[stringColor];
        }

Now I am not actually sure if this is possible, but is there a way of setting the initial Particles' sprite texture color/fillColor to anything but 0XFFFFFF? This way, the initial tinting at CanvasSpriteRenderer.js#L127 can be avoided and would massively improve the animation speed on first runs of the emitter.

Obviously this would only be useful if the start/end colors are the same. Otherwise tinting is required to transition a particle from one color to the other.

Is this feasible? It seems to me that the baseTexture.source needs to be set somehow but I couldn't figure it out.

Since 2.1.0 I'm getting

Cannot find module './ParticleUtils' from '/Users/marek/workspace/be-the-king/node_modules/pixi-particles/dist'
Cannot find module './Particle' from '/Users/marek/workspace/be-the-king/node_modules/pixi-particles/dist'

when trying to build a project with pixi-particles. I've looked through the changeset, but I couldn't find what has caused this problem. Any ideas?

I'm building a pixi videogame using es6 and babel. I've used this boilerplate https://github.com/magnonellie/pixi-boilerplate and I've added pixi-particles as dependency.
I'm importing pixi and pixi-particles as following:

import * as PIXI from "pixi.js";
import * as PIXIParticles from "pixi-particles";

I've no problem using PIXI.Container or PIXI.Particles.Emitter. But PIXI.particles.PathParticle results to be undifined. How should be included? is it not part of the PIXI.particles namespace

I don't get this, why is it that I have less control over the emitter? I need something like emitter.fireOnce = true. How can I control my emitter to fire particles only once.

HI.

Thx for updating new PixiParticle .

particleContainerPerformance can see different screen between particleContinaer and normal Container.

it seems because of draw order...

particleContainer draw newPartcile under old Particle.
but Container draw newParticle upper old particle...

so i can see different screen;;

thx.

Having a middle value for alpha and scale would be very useful. For example, I might need to first fade in a particle, then fade it out. So I'd do:

    "alpha": {
        "start": 0.0,
        "middle": 1.0,
        "end": 0.0
    }

Currently this does not seem possible with this engine.
Hence, I propose an optional "middle" property for alpha, scale and color.
Being optional meaning that the property could be omitted and the emitter work as it does now.

Hi, need to change properties such as lifespan.

If an object moves away from another object, I need the lifespan to be equal to their distance.

So,

emitter.lifespan(this.x - that.x);

How does one achieve this?

Calling particle.destroy nullifies particle.next causing the for loop to exit after destroying the first particle.

Hey!

I have a problem with error:

TypeError: Cannot read property '_uvs' of undefined

Its show really randomly, hard to create a reproduction. The problem is with AnimatedParticle.

TypeError: Cannot read property '_uvs' of undefined
    at SpriteRenderer.render (http://localhost:5000/bower_components/pixi/bin/pixi.js:18475:22)
    at Sprite._renderWebGL (http://localhost:5000/bower_components/pixi/bin/pixi.js:17948:29)
    at Sprite.Container.renderWebGL (http://localhost:5000/bower_components/pixi/bin/pixi.js:7744:14)
    at Container.renderWebGL (http://localhost:5000/bower_components/pixi/bin/pixi.js:7749:30)
    at Container.renderWebGL (http://localhost:5000/bower_components/pixi/bin/pixi.js:7749:30)
    at WebGLRenderer.renderDisplayObject (http://localhost:5000/bower_components/pixi/bin/pixi.js:14661:19)
    at WebGLRenderer.render (http://localhost:5000/bower_components/pixi/bin/pixi.js:14634:10)

Do you have any advice what to look for to better track the issue? So I can say more?
Using the latest 1.6.6

Cheers,
P.

Following hot on the heels of #23, using PIXI.ParticleContainer throws a deprecation warning. Changing both instances of ParticleContainer = PIXI.ParticleContainer to ParticleContainer = PIXI.particles.ParticleContainer || PIXI.ParticleContainer should resolve the issue an retain backwards compatibility.

I was getting a PR ready, but I noticed you have no dev dependencies nor a build process defined.

Having a particle emit frequency is great for most cases, but I'd also like to be able to say: each update the chance for a particle to spawn is x. Along with that, specifying the amount of rolls would also help greatly. That is: in this update, roll 5 times and each one under 0.2 (for instance) spawns a particle.

This will allow for some more interesting effects to be obtained, I believe.

The email I send you months ago seems filtered... maybe. But I just noticed you can still receive messages here. So it's not actually an issue -- much more like a request.

Hi Andrew,

I've been working on a game by using Pixi.js and I like your Pixi Particles system. Thanks for the amazing library you guys made!

Our project is written in Haxe, so I made a Haxe externs for your library. I think @adireddy removed externs from his pixi-externs lib since Pixi.js v3 released. (don't know why but I can no longer find anything in his repo)

Therefore, if you don't mind would you please add my extern project page to your README.MD? It maybe easier for the others who needs this library in Haxe to find.

The project page:
http://github.com/Rollo-Liu/pixi-particles-haxe/

This is the lib page on Haxelib:
http://lib.haxe.org/p/pixi-particles/

If there is any problems please let me know.

Many thanks,

Chuan

At least for Pixi 4, using requestAnimFrame(update) throws and error. When I used instead requestAnimationFrame(update) - all is good.

Being able to set max velocity, to avoid endless acceleration would be nice

Hi,

Is it possible to use this with the new PIXI.ParticleContainer?
I've tried, but cant really get a good result (bad preformance).

When i profile the script it spends 50% of the profiling time in ParticleBuffer.uploadStatic

Thanks.

Hi

I'm not sure if this is right place to post but anyway. I would like to ask if there is possibility to update
interactive particle editor so it can use AnimatedParticle. Our artist does a lot of testing in this editor, and it would be better if he could see result in real view. It would be acceptable even pass additional parameters as url parameter if you would not have time to update user interface. If i understand correctly only (or at least) framerate and loop parameter are needed to be configured, specially for animated particle.

cheers

.mrtn

Hello,

When updating pixi.js to 3.0.10, pixi-particles throws deprecation warnings in the console setTexture() is deprecated, use sprite.texture = texture. Updating pixi-particles to 1.6.5 did not change anything.

I can easily fix that and PR but I also noticed you are working on v4 compatibility. Is it still relevant to make a PR in the coming days for that ?

Awesome job by the way, I love this lib !

In Pixi v4, currently in rc1, PIXI has created its own PIXI.particles namespace. This module, in conjunction with PIXI v4, overwrites all of the necessary stuff you need in there.

I would recommend checking if PIXI.particles already exists, and if it does, simply merge your keys in with it instead of overwriting it entirely.

Is there any way to make an emitter move along a path? or I must write my own logic? Thanks

Sorry I must be missing something really obvious, but how do I change a burst or stream from 1 direction to another? For example the bubble spray example - how would I simply reverse this to spray downwards instead of up?

While the samples are all lovely, lack of basic controls like changing direction make this editor very hard to actually use.

Is it possible to get a realistic looking fireworks display using pixi-particles?

hello..

i wonder you have plan to add gravity in particle and particle tool..

becuase gravity useful..

thx a lot

what it was:

on line 176 :
for(i = 0; i < art.length; ++i)
{
data = art[i];
art[i] = output = {};
output.textures = outTextures = [];
textures = data.textures;
for(j = 0; j < textures.length; ++j)
{

            tex = textures[j];

what it should be:

for(i = 0; i < art.length; ++i)
{
data = art[i];
art[i] = output = {};
output.textures = outTextures = [];
textures = art;
for(j = 0; j < textures.length; ++j)
{

            tex = textures[j];

Because data.textures doesnt return an array, hence textures.length will throw an error

Hey

When I cloned the repo and installed everything, everytime I tried to do a build it would give me errors about missing packages. As a hack, I dumped everything it mentioned into the package.json itself, versionless, and the builds then worked!

Here's what I dumped in

"grunt-bower-install-simple": "",
"grunt-simple-version": "",
"grunt-text-replace": "",
"grunt-contrib-clean": "",
"grunt-contrib-concat": "",
"grunt-contrib-connect": "",
"grunt-contrib-jshint": "",
"grunt-contrib-less": "",
"grunt-contrib-qunit": "",
"grunt-contrib-uglify": "",
"grunt-contrib-watch": "",
"grunt-contrib-yuidoc": "",
"grunt-gh-pages": ""

I can see why you have done this but i think it would be a bit more practical if acceleration was an empty PIXI.Point regardless of the wether or not the emitter uses acceleration.

This became apparent to me when i wanted to randomise the acceleration between frames and found that acceleration was actually null when not used.

See these two animated gifs for a comparison:

Good:
https://cl.ly/0T3m3S2o3t3D

Bad:
https://cl.ly/1G181J2x1z0Y

The first one is much brighter and has crisper edges. The second one looks more dull and blurry.

Steps for easy reproduction:

{
	"alpha": {
		"start": 1,
		"end": 0
	},
	"scale": {
		"start": 0.4,
		"end": 0.4,
		"minimumScaleMultiplier": 10
	},
	"color": {
		"start": "#3be5ff",
		"end": "#3be5ff"
	},
	"speed": {
		"start": 10,
		"end": 10,
		"minimumSpeedMultiplier": 20
	},
	"acceleration": {
		"x": 0,
		"y": 0
	},
	"maxSpeed": 0,
	"startRotation": {
		"min": 0,
		"max": 360
	},
	"noRotation": false,
	"rotationSpeed": {
		"min": -1,
		"max": -1
	},
	"lifetime": {
		"min": 1,
		"max": 1
	},
	"blendMode": "screen",
	"frequency": 0.001,
	"emitterLifetime": -1,
	"maxParticles": 10000,
	"pos": {
		"x": 0,
		"y": 0
	},
	"addAtBack": false,
	"spawnType": "point"
}

Go to http://pixijs.github.io/pixi-particles-editor/ and load the above json into the editor.

Compare that to the latest version of pixi & latest version of pixi-particles that I have running at: http://playglitter.com/particles

If you set the spawn frequency to an invalid number ( < 0, and possibly a NaN ) then the update loop could end up crashing the page. Perhaps there needs to be a sanity check (custom setter?) on frequency to enforce 0 if NaN or < 0?

Hi

We're using pixi particles a lot and we're quite happy with such features in our games. For designing particles we've been using pixi particles editor but our graphic artist needed upgrade. So i decided to to create new editor. (Just putting together angular, bootstrap, pixi and pixi particles. I have only basic knowledge about all modules that i used. Ok, maybe pixi, and pixi particles a little deeper).

I've run to a problem:
I have tested same emitter and image in both particle editors, mine and yours.

But result is different. problem is when blend mode add is set. Could you please give me a hint what has changed in particles, or even pixi? I'm googling around and asking around for a while and cannot find a solution

I'm attaching image and emitter to post
Archive.zip

When webgl renderer is used particles are different. In new editor is much brighter. In canvas result is the same.

Thank you for your cooperation

.mrtn

I'd love to be able to specify the range of directions particles should move (startRotation) without actually having the particles rotate themselves. I'm working on a low-fi roguelike mmo and rotated particles don't really fit in aesthetically. I'll hack it in for now but if it's something you feel would be useful, a config option would be really nice.