ParticleContainer and interaction manager

[Hachi]

Hey,

 

It seems that the PIXIs interaction manager does not work at all, or fully, with particleContainers? Like in this plunkr example: http://plnkr.co/edit/B2MT9d078lDDHk2bS5rd (you can replace the particleContainer with Container and it works fine).

My problem is not actually specifically the same as the plunkr issue as I am using the processInteractive function manually, but I also encounter weird issues of worldTransform not getting generated correctly (more precisely the tx and ty) with my actual app and trying to investigate it. I would like to know what is the extent of support for particleContainer with interaction manager. Should I just come up with my own implementation for detecting the click or use normal containers?

 

-Hachi-

[xerver]

http://pixijs.github.io/docs/PIXI.ParticleContainer.html

 

The ParticleContainer class is a really fast version of the Container built solely for speed, so use when you need a lot of sprites or particles. The tradeoff of the ParticleContainer is that advanced functionality will not work. ParticleContainer implements only the basic object transform (position, scale, rotation). Any other functionality like tinting, masking, etc will not work on sprites in this batch.

Nothing that isn't position, scale, rotation, or uvs does not work in ParticleContainer; by design.

[d13]

 Should I just come up with my own implementation for detecting the click or use normal containers?

ParticleContainers have limited options - by designed, as Xerver mentioned - specifically so that they perform well in extreme performance environments.

But I just use ordinary Containers for everything.

They perform as well as ParticleContainers if you're just pushing a few hundred sprites around, and I haven't yet found a situation where using a ParticleContainer has given me a noticeable performance boost.

This is very specific to each application however - so you have to test in the context of your game or app.

 

If you're having performance problems with and using ParticleContainers is the only thing that saves it, it's likely a warning that you need to optimize in other areas. 

[Hachi]

Well it seems to have some issues, just when doing a basic x and y change, nothing special. At least when using hitareas. I believe so, after that plunkr shows pretty much the same issue I have, or at least similar.

For me the issue was actually so, that I manage the hit detection manually using processInteractive, but the displayObject.worldTransform.applyInverse uses wrong matrix tx and ty values (seems unaltered). For some reason seems like those are not updated correctly when particleContainer is created. Currently with my engine, after I test it a while, the tx and ty get updated to correct values, but they are not correct at the start.

 

ParticleContainers have limited options - by designed, as Xerver mentioned - specifically so that they perform well in extreme performance environments.

But I just use ordinary Containers for everything.

They perform as well as ParticleContainers if you're just pushing a few hundred sprites around, and I haven't yet found a situation where using a ParticleContainer has given me a noticeable performance boost.

This is very specific to each application however - so you have to test in the context of your game or app.

 

If you're having performance problems with and using ParticleContainers is the only thing that saves it, it's likely a warning that you need to optimize in other areas. 

The object count that I will try to support with the engine is big (like easily over 50k objects), but that should be manageable by caching the objects and not using all of them actively.

Though I am really not sure if I really need the particleContainer as I can manage most of my optimizations with cacheAsBitmap. Originally I made a prototype with easel and encountered heavy issues with performance, which is why I wanted to test the optimized layers in PIXI. But this test was couple years ago - with easel - which mean no webgl. I think I will just go with regular Containers and if I really encounter issues that can't be solved I will return to particleContainers.

Thank you for the answers and the help!

[Hachi]

I actually found the solution to the issue, now that I just stumbled upon the DisplayObject.updateTransform-method (https://pixijs.github.io/docs/core_display_DisplayObject.js.html) (. Which fixes the issue.

 

Also I noticed the same thing happens when the container is cached (cacheAsBitmap = true): http://plnkr.co/edit/eqbN7LcLZECxJHv8JCho

So just calling DisplayObject.updateTransform, when ever you create ParticleContainer or move cached content, should fix the matrix to correct values and fix the issue.

 

It seems that particleContainer nor cached content uses updateTransform automatically. I assume strongly that this is intended behaviour, but can you guys just enlighten me, why doesn't the particleContainer or cached content call the method automatically, but normal container does?

[xerver]

So just calling DisplayObject.updateTransform, when ever you create ParticleContainer or move cached content, should fix the matrix to correct values and fix the issue.

Which completely defeats the purpose of ParticleContainer. If you need to use more advanced features that just normal transform, use a container. Same thing with cached content, if we called update transform everytime what benefit would you get from it being cached? The whole point of these features is to *not* do those extra operations because you don't need them to render. If those optimizations aren't needed don't use them. But definitely do not use the optimization *and also* hack in code to make it act like the normal container.

[Hachi]

@xerver thank you for the reply.

 

http://pixijs.github.io/docs/PIXI.ParticleContainer.html
 

Nothing that isn't position, scale, rotation, or uvs does not work in ParticleContainer; by design.

I only figured that since I'm not using any advanced graphical features, like filters, it should work fine. Didn't realize it applies to other features too.

But now that you mention it, it makes sense even in my case. The game map that I have won't need to have updated matrix, when it is moved, only when it is stable / static (click and mouseovers). So in that sense I should get it even more optimized, when I do the movement without updateTransforms in between.

 

Which completely defeats the purpose of ParticleContainer. If you need to use more advanced features that just normal transform, use a container. Same thing with cached content, if we called update transform everytime what benefit would you get from it being cached? The whole point of these features is to *not* do those extra operations because you don't need them to render. If those optimizations aren't needed don't use them. But definitely do not use the optimization *and also* hack in code to make it act like the normal container.

Just to comment the cached content: The gain that I hoped to get from cached content, isn't regarding matrix calculations, though this way I will get that too. The point was to gain optimizations in the actual drawing of the graphics to the webgl / canvas. So not individual objects are drawn one after the other on to the canvas, but the big bitmap once.

But once again. Thank you! Actually very good insights for me, things that I didn't think of yet .

[d13]

Hi Hachi,

 

Just to re-inforce what Server said: Pixi is crazy-optimized for you from the start so that we don't have to do all our old-skool hacks like those caching tricks.

Pixi does a lot of that stuff for you anyway under the hood, plus a whole bunch of extra voodoo.

So by adding your own pre-optimizations on top of all that you're likely just adding more weight and will slow things down.

 

ParticleContainers run as close to the metal as is possible for a WebGL 2D renderer in November of 2015 - they're state of the art.

If you can't push 50k sprites around at 60fps using Particle Containers, you've reached the HTML5 rendering performance limit.