PIXI.ParticleContainer support about particle-emitter HOT 21 CLOSED

I don't think there is anything in the library that should cause poor performance using one - each Particle is just a Sprite(MovieClip) that gets moved around, and ParticleContainer should just ignore features it doesn't support. That being said, I haven't had the chance to use Pixi V3 yet and have always been using tinted particles anyways. If you can find out that we are doing something that specifically harms ParticleContainer performance, I'd be happy to change it.

from particle-emitter.

Hi Andrew, that was a prompt response! I've done some testing and now i cant blame that its just the ParticleContainers fault. I'm getting mixed results on both Containers and ParticleContainers.

Maybe its just that i need to optimize even more. I don't know if its because i need to preload the textures/sprites. because it can run really bad, and after some time and a browser refresh it's smooth. (I'm testing on a i7 with a GTX980, and the goal is to support alot lower systems)

When I'm making an explosion, i put it together with 3 different emitters,
one that will burst fragments (about 40 particles) normal blendmode.
the explosion (about 30 particles) screen blendmode.
and following smoke (about 30 particles alive) normal blendmode.

so one explosion will burst with about 70-80 particles, and the continue smoking for 5 seconds with max 30 particles on screen.

You can see it in action here http://52.26.28.242/ (I've added 100bots just to force the issue)
and you might have some delay, its US hosted.

Currently theres no render culling, i want to optimize it as much as possible before doing culling.

Do you have any "pro-tips" on what i can do to optimize it?

• Would it make sense to put all the particles on the same texture ( even though they exist in different emitters and have different blendmodes? )
• Can i somehow preload a bunch of particles?
• Does it have additional render cost if "addAtBack = true"?
• Is there anything else i should have in mind?

Sorry if I'm asking to much.

from particle-emitter.

Optimization tips:

• Putting particles on the same texture never hurts. Different blend modes might prevent proper sprite batching, but being in different emitters would not. On a related note, putting the tank chassis and turret in one spritesheet would also help, as each tank could be batched into one draw call instead of 2.
• No, each emitter creates new particles as it needs them, which shouldn't be a problem when you recycle them.
• addAtBack shouldn't have a cost - it decides if it adds particles to your container with addChild(child) or addChildAt(child, 0).
• Recycle everything - You are recycling emitters, which is good. It looks like you are making new temporary point objects each frame for each player though, which generally isn't good. The memory graph of your game slowly builds to a larger GC event, instead of the flat sawtooth graph that is your goal.
• While preloading textures wouldn't hurt, it shouldn't be causing a performance issue because they just don't display until they are loaded. Preloading textures and switching to spritesheets would go hand in hand, though.
• Given the amount of text you are showing, it would probably be good to switch to a bitmap font, so that all the text can be batched together into one draw (assuming it is on the same layer, with nothing from outside that spritesheet). Additionally, it means you won't need to upload a new texture to the GPU every time you update the score or otherwise redraw text. (Alternatively, use a DOM scoreboard)
• While JQuery is easy to use, I am told it isn't the best for performance, particularly for things you are doing every frame.

Overall, your game seems to run pretty well though. I'm not sure if temporary poor performance is due to the GC, loading assets, or something else. I was looking at it in Chrome on a 2010 iMac equipped with an i3 and an ATI Radeon HD 5670.

from particle-emitter.

Really, thank you for taking the time to look at it. Much appreciated!
I don't normally code games, so I'm probably doing some rookie mistakes!... small mistakes hit really hard when they are repeated 60-120 times every second :)

I'll try using texture-packer, and put all my sprites on one sprite-sheet, And I'll have a look at using bitmap fonts. The scoreboard is temporary, it would make sense to put that in a DOM element, since it is updated at a much lower rate then the actual game.

• What jQuery in my Animation() loop? I actually tried not to use it every fame. :) The only jQuery I find is in the Server.SetData() function, but that only happends when you die.
• Temporary point objects, Do you mean stuff like this?
  var player = Players[id];
  var pos = {
  x: Lerp(player.body.position.x, player.target.x, lerp),
  y: Lerp(player.body.position.y, player.target.y, lerp)
  }
  var angle = Lerp(player.body.rotation, player.target.angle - 1.57, lerp);
  var gunAngle = Lerp(player.gun.rotation, player.target.gunangle - 1.57, lerp);

You're telling me that every time i use "var xxx =" in my Animate() function, i should rather declare "var xxx" outside the loop and then just reuse it "xxx = yyy"?

Once again. thank you!

from particle-emitter.

You are correct, I thought that JQuery was being used more often but it is just on initialization and death. You are using $.each() when redrawing the scoreboard, which while not slow, is creating a new function each redraw.

Creating local variables is fine when it is a basic type like a number, and really only an issue when you are making new objects - var pos = {}. Generally you should make as many helper points as you need at one time, and just set their x and y values again for each use. This is happening in animate() and Server.SetData(). It is also happening in Vector.Distance(), which would be fine with two vars for x and y instead of an object.

from particle-emitter.

Ahh, i wasn't looking at the scoreboard part. I'll remove this when i make a new scoreboard, there really no sense using jQuery for these kind of loops anyway.

jQuery was actually only included for making GUI stuff, which i haven't made yet :) but habits is a bad thing :)

Okay, so ill stop declaring objects inside my update functions, and just split it up to simple var's, (or if needed declare and reuse my helper objects outside the loops!)

I have some work to do ;)

Thank you and have a very nice day!

from particle-emitter.

Hi Andrew, I just want to keep you updated.

I've done all the optimization you suggested (except the scoreboard which will be remade).
Everything runs on two textures now(one for the bitmaptext and one for everything else), and i think it has helped a lot!

I'm still a bit confused though, when i check with "WebGL Inspector" it still has 1000+ lines in the Trace/draw-call section.
I reduced it a lot by putting all the text on its own "layerText". and updating the positions manually.

But everything below that layer is from the same texture, shouldn't that leave me with only 2-4 draw-calls (dependent on how the blend-modes is handled)? Maybe i should put each Emitter with different particles/blend-mode on its own layer aswell?

And also my initial question showed itself again.
http://52.26.28.242/ (regular container)
http://52.26.28.242/particlecontainer.html (Changed "layerSmoke" to particleContainer)

And just as I'm testing it now the issue isn't happening ......
But what happens is, sometimes the game just starts freezing on frames(when all the bots starts shooting). until it eventually halts.
When i profile the page it shows that 50% of time is spend in "SpriteRenderer.flush()". with the normal Container its only about 3%. I've tried setting the ParticleContainer size to 1,000,000, but that doesn't change anything.

I might just have to settle with the normal container, but it just tempting if the particlecontainer actually was able to improve the performance.

from particle-emitter.

Hi Andrew,

This might be the explanation to why I'm getting worse performance in the ParticleContainer
http://www.html5gamedevs.com/topic/15333-performance-issues-going-from-v2-to-v3/

"Adding/removing sprites from a ParticleContainer causes a reupload of all the properties, even the static ones, which is pretty expensive. If you are adding/removing sprites to/from particle containers all the time then you are likely getting worse performance than a normal container, since it has to recalculate and reupload everything every time you do a child change like that. (obviously multiple changes in a single frame only result in a single upload)."

I'm not sure how you handle the particles, but maybe this means that you need to treat the particles different, if using a ParticleContainer.

from particle-emitter.

This is good to know. Adding and removing child is exactly what I am doing. It sounds like for ParticleContainers I should be setting the alpha of dead particles to 0, and adjusting the children array directly when reusing them. I'll try to find some time to take care of that.

from particle-emitter.

Yes, or maybe set the Sprite.renderable = false.
Wouldn't the particles still cause calculations if you only change the alpha to 0?

Edit:
updateTransform is still called if renderable=false, so it should probertly be visible=false
"The visibility of the object. If false the object will not be drawn, and the updateTransform function will not be called."

from particle-emitter.

According to your link, visible=false is also ignored for children of ParticleContainer.

from particle-emitter.

Thats correct, but he mentions it as a bug, so it still might be the correct solution in long therm.

from particle-emitter.

I've updated the master branch (no release yet) with an entirely untested change that will hopefully fix ParticleContainer performance by not adding and removing children all the time.

from particle-emitter.

Hi Andrew,

I just tested it, and it isn't working at all, not just ParticleContainers, but in general.
#1821: for (var i = this._activeParticles.length - 1; i >= 0; --i) {

throws Uncaught TypeError: Cannot read property 'length' of undefined

from particle-emitter.

And this is why you check your code for dumb bugs. I've fixed the error that was preventing Emitters from initializing and this time made sure the examples still ran.

from particle-emitter.

Its working now, and it isn't causing performance problems.

But its acting wierd, i don't know if thats a general problem using ParticleContainer, og if its PixiParticles that isn't resetting scales/alphas probertly.

http://52.26.28.242/

After a very short time, all the smoke starts flickering. And if you look at the "MuzzleFlash Smoke" it will spawn huge particles. Like the scale isn't resetting.

from particle-emitter.

Hmm. I guess just use a Container, and I'll try to figure out what's going on when I can get a chance.

from particle-emitter.

I will do that for now :)
And check back later to see if you found a solution.

Have a nice weekend

from particle-emitter.

If you are still working on this, did you enable property uploading in your ParticleContainer? It seems to work fine for me when I use:

emitterContainer = new PIXI.ParticleContainer();
emitterContainer.setProperties({
    scale: true,
    position: true,
    rotation: true,
    uvs: true,
    alpha: true
});

from particle-emitter.

Yes I was aware of though settings. I just set them directly when initiation of the ParticleContainer.
I just tried it out again, and actually I'm not seeing any problems now, hmm.

I have changed pixi to 3.0.8 (dev version) in the meantime, I don't know if that maybe fixed it, or if i was doing something else wrong at the moment.

from particle-emitter.

Since it works, great! I'm closing this issue until someone finds more ParticleContainer problems.

from particle-emitter.