[solved] Some performance related questions

  1. what sort of performance does particle emitter deliver ? i created 3 (cloud+rain) particle emitters, outputting 20 partilcles each (20x6) and one core was maxed out (i have a quad core, x4 amd 3.4ghz) and the fps dropped from 99 (which is what i set max to) to about 40 fps;

    so what am i doing wrong ? or is it possible to multithread emitters ?
  2. my current project so far is fairly empty in terms of models, a shop, a tree on fire, a fence, a campfire, some simple water and a platform like terrain(model, not terrainQuad) and Oto, now pretty much each of these have their own controls various character controls or rigidbodycontrols, on top of that i’ve added ghost controls on some items to implement game-mechanics (i,e:
  • simple water has a ghost control attached to it where if a Player instance overlaps it, it will create a water splash effect (particle emitter)
  • within the shop i added a ghostcontrol area where if a player steps in it, his health increments

    ) … various things like that, the game so far reaches around 150mb or so, my question is if i add in say 10x more objects like these with their various controls, would the performance degrade alot and if so how would i go about resolving that ?

    thanks in advance

there might be something in an update loop which is very demanding, or your actions in your collision event listeners are being fired a lot when they only need to be fired once, i don’t know i’m just making assumptions. The stuff you post doesn’t sound like it should have a drastic effect on FPS. A testcase would be nice. Do you have any post processing effects?

this is what my update loop is doing:

[java] Vector3f camDir = cam.getDirection().clone().multLocal(0.6f);

Vector3f camLeft = cam.getLeft().clone().multLocal(0.4f);

walkDirection.set(0, 0, 0);

if (left) { walkDirection.addLocal(camLeft); }

if (right) { walkDirection.addLocal(camLeft.negate()); }

if (up) { walkDirection.addLocal(camDir); }

if (down) { walkDirection.addLocal(camDir.negate()); }





physics.findTargets(); //this is for ai characters, in tests i havent spawned any yet




physics class…

public void updateTime(float tpf){

time = time +tpf;

if(time >= 1){

for(int j=0;j<removalQueue.size();j++){





time =0;



public void checkHealth(){

for(int i=0; i<players.size();i++){

if(players.get(i).getHealth() <= 0){






public void updateProjectiles(float tpf){

for(PhysicsProjectile pp : projectiles){



for(int i=0; i<projectiles.size();i++){







public void updateEffects(float tpf){

for(Effect e: effects){



for(int i=0; i<effects.size();i++){








for(int i=0; i<effectsQueue.size();i++){




}catch(Exception e){

System.out.println("line 92");





some info:

Effect (is an extension of particleemitter (Cloud and rain is an Effect) with a timer set to it (ttl, check against time+=tpf)

projectiles are physics attached particleemitter fireball, when i spawned the 3 rain clouds, no projectiles were created.

i have a queue because i want it so when i throw a fireball into a rain cloud it should spawn a steam Effect which lasts about 3 seconds.

most of these for loops have sizes of about 3-8 max.

oh, i use PhysicsTickListeners for my ghostcontrols which detect if theres anything overlapping and then does an action on it, (i.e. my raincloud has a rainControl, which uses a physicsTickListener to see if other ghostControl objects are overlapped and if any of them are called “Fire” it will put them out and remove the particleemitter from scene (the removalQueue() in the first update loop)

hmm, the best thing to try, is comment out some things and see which affects the FPS the most, then you should be able to isolate the issue.

i added in a new thread, where in physics, i put all the effects update into a new thread, i just created 10 rain clouds, performance is steady, cpu 10% now. im gonna migrate all my physics udpates in seperate threads, wooo, cant believe how wonderful threads are (ive used them before but on proper time intensive tasks, e.g. like 5 mins each)

oh nice, glad you fixed it. I also need to get used to threads, i’ve avoided them best I could :stuck_out_tongue:

only problem i have is closing the threads, the executor is stubborn and wont shutdown, even with shutdown() / shutdownnow()

---- edit:

fixed, was catching in a try and catch exception.

Err, you can run physics in a separate thread out of the box you know that right? Check the javadoc for BulletAppState. Also we will multithread ParticleEmitters from the jme side automatically in the future. I’d not mess about too much in the update loop yourself as this might make your app uncompatible with such future updates.

yeah im only breaking up the update loop like the wiki says, and creating new executor service within the loop so that there are no scene not ready errors.

i thought physics was already multi-threaded ? do i need to set it ?

(im trying: bap.setThreadingType(ThreadingType.PARALLEL):wink:

same performance, i think it always already using parallel.

Yep, you need to set that, then all physics spaces are computed in parallel to rendering (and in parallel to each other), by default the physics spaces are worked off sequentially before rendering.

1 Like

ah good to know, my main bottleneck was updating time based objects, but thats all working fine now, i spammed particle emitters / projectiles, reached about 500 objects (in that info on the bottom left of the screen) and it maintained 80-99fps (99 is max).

my next stress test is AI path finding.

thanks for the help, shall i put solved in the title ?

1 Like

if its solved then sure :]