Well I suspect that the problem comes from me not understanding the Particle system fully, however:
I have bullets someone shoots and they have a hit effect, now the effect is only one particle, however if a few dozen of those effects are at the same time, the performance suffers extremly, wich I don’t really understand.
[java] @Override
public void init() {
if(mat == null){
mat = new Material(ClientApplication.getInstance().getAssetManager(), “Common/MatDefs/Misc/Particle.j3md”);
mat.setTexture(“m_Texture”, ClientApplication.getInstance().getAssetManager().loadTexture(“Smoke.png”));
}
emit = new ParticleEmitter(“Emitter”, Type.Triangle, 1);
emit.setMaterial(mat);
emit.setParticlesPerSec(0);
emit.setGravity(0);
emit.setStartColor(ColorRGBA.Cyan);
emit.setEndColor(ColorRGBA.Blue);
emit.setHighLife(0.1f);
emit.setLowLife(0.1f);
emit.setStartSize(1);
emit.setEndSize(10);
emit.setSelectRandomImage(true);
emit.setInWorldSpace(false);
emit.setInitialVelocity(Vector3f.ZERO);
emit.setVelocityVariation(0);
emit.setImagesX(15);
emit.emitAllParticles();
TimedInvocation.Add(this,“free”,1500);
this.attachChild(emit);
}
public void free(){
emit.killAllParticles();
this.detachAllChildren();
this.removeFromParent();
}
[/java]
The question is, how can I improve the performance of it? (Also if I comment the emitter out everything runs fine without performance loss, so I don’t think its the rest of my code) Thanks for reading.
Are you having separate emitter for every bullet mark? Isn’t there a possibility for reusing single emitter with each particle representing one hit mark ?
i have thought about that as well, but i don’t know how to do this.
Its easy, I did a helper class for that in jME2 once. Its basically just a class that wraps a list of emitters that gets extended up to a limit of say 100 emitters (depending on how many are requested at once/in one tick). Now each time you want an explosion or something you just tell the class where and when and it will attach the emitter, play the emitter animation and then remove the emitter and put it back in the list for the next request.
Edit: In TestWalkingChar I also use only one emitter for the explosions, if you know it you can see that the “old” explosion stops when the new one starts but in fact its barely noticeable.
Hm well so a object pool is a good idea, so you think as well that the creation of the emitter is the time consuming thingy
Definitely, also it strains the garbage collector unnecessarily.
Perhaps you’re leaking particle emitters? Make sure to detach them from the scene after they finish playing.
Maybe its that TimedInvocation thing, I see that the effect happens for 0.1 seconds (the high life parameter), but you’re detaching after 1.5 seconds?
Also since you’re not using particle rotation, you can use point sprites for that instead (see TestExplosionEffect on how to use them).
Nope the timed invocation works fine, also it only lags if i have many effects at once, not if i have many but over time. (many is somewhere betwenn 50-150 depending on machine)
What happens if there are a lot of explosions but they are not visible on the screen?
Well it is a bit realted, I think I found the reason, when i constantly shoot the Textures(m) add up to several 100, then there is a lag and they go down to somewhere around 100-200 (Without shooting scene only has around 10)
Ah okay. It might be that texture duplication bug reported recently.
There is a culling issue too with particle emitters, it can be related. (i added it some days ago in the bug tracker).
If it is a texture duplication bug, then manually caching texture/material in some kind of statiic variable is a workaround for now - seems to work ok (as long as you don’t want to modify per-instance parameters of course).
The texture duplication bug has been fixed already.
Try testing with the version in SVN and see if you still have the “Textures (M)” go up.
Well it does, however when i create a testcase with the very same effect it does not.
So I guess I hold somewhere a reference and have a leak caused, (I still wonder how that is possible when using only the assetloader for loading however)
That’s odd, the leak can only happen if you’re loading unique textures every frame. Since everything is cached, there’s no way that number can keep going up.
Make sure you properly updated your jME3 version, you might still be using the old jars for your main project I am guessing.
right I had to rebuild ^^, now everything is working fine and fast