Reducing Calculations Solid Particle System updateparticles

[MasterSplinter]

I'm having some framerate issues (granted there are 240k vertices)...

 

Getting about 58 on Desktop... Drops to 15 Chrome on  Laptop and then 8 on Firefox on Laptop...

 

http://crab.strangled.net/

 

I think this is the issue -- I need a method of skipping calculations... I tried Jerome's suggestion of waiting to calculate every 3 frames but this causes a stutter...  Any suggestions welcome!

 

Thanks in advance!

  SPS.recycleParticle = function (particle) {    if (particle.idx > particleCount) {      particle.alive = false;    }    else {      particle.alive = true;    }    if (!particle.alive) {      if (particle.scale.y == 0) {        return;      }      particle.scale.x = 0;      particle.scale.y = 0;      particle.scale.z = 0;      particle.position.x = Math.random() * 6;      particle.position.y = Math.random() * 6;      particle.position.z = Math.random() * 6;      return;    }    else {      particle.position.x = Math.random() * 6;      particle.position.y = Math.random() * 6;      particle.position.z = Math.random() * 6;      particle.velocity.x = (Math.random() - 0.5) * speed;      particle.velocity.y = Math.random() * speed;      particle.velocity.z = (Math.random() - 0.5) * speed;      var scale = scaleValue - 3 * (Math.random());      particle.scale.x = scale;      particle.scale.y = scale;      particle.scale.z = scale;      particle.rotation.x = Math.seededRandom() * 3.5;      particle.rotation.y = Math.seededRandom() * 3.5;      particle.rotation.z = Math.seededRandom() * 3.5;      particle.color.r = Math.random() * 0.6 + 0.5;      particle.color.g = Math.random() * 0.6 + 0.5;      particle.color.b = Math.random() * 0.6 + 0.5;    }  };

[jerome]

Maybe a PG could help ...

 

Generally, the leads to improve the performances are :

- skipping un-needed calculations or processes. You can also set some properties to false : http://doc.babylonjs.com/overviews/Solid_Particle_System#sps-management

-  being careful about NOT creating new objects within the render loop and taking care about the GC : http://doc.babylonjs.com/overviews/Solid_Particle_System#garbage-collector-concerns

 

And if it's not enough, maybe lower the number of vertices or the number of particles : 240 K vertices is a big amount, the sps will have to iterate over it 240 K times per frame. There might be here just a JS engine speed limitation reached depending on the browser or device you are using, simply due to the CPU capacity.

 

I keep an old laptop and test my programs with it. If the program runs at 30 fps or more on it, it's generally the proof for me that this program could then run almost everywhere at a decent framerate 

[jerome]

about your code here :

 

You choose when you want to call sps.recycleParticle(). It's not called for each particle by setParticles(). So I can call it for only the particle to be recycled, I guess... this is a first limitation.

 

Line 16 to 18 : is there a need for positioning dead particles at this moment ?

Line 28 : you've got thousands and thousands particles, I guess. So don't declare a local variable here, that will be allocated each call and deleted then by the GC when leaving your function.

Instead use a higher scope permanent variable or SPS.vars.scale what is designed for this goal : http://doc.babylonjs.com/overviews/Solid_Particle_System#garbage-collector-concerns

 

If the particles don't need to change their own colors each time they are recycled, you could set the SPS optimizers after the first call to setParticles().

SPS.computeParticleRotation = false;  // prevents from computing particle.rotation SPS.computeParticleTexture = false;   // prevents from computing particle.uvs SPS.computeParticleColor = false;     // prevents from computing particle.color 

Then the next calls to setParticles() won't compute the rotation, texture, color updates for each particle and will just keep the current set values.

[MasterSplinter]

I fixed the stuff you mentioned...  It gets me up to about 19-20FPS on the laptop.  One thing I was hoping you could explain.  I have 10,000 cubes in this scene -- but it is saying I have 240 vertices.  Where is that calculation coming from?

[jerome]

Well a BJS cube (as a 3js one) is 24 vertices : 6 sides of 4 vertices each.

You can't reuse the vertices (for 3 common sides for instance) on a cube because of the rule :

a vertex == a normal

 

Normals aren't shared by the sides on a cube. 

 

[EDIT] Do you really need 10 000 different solid objects on the same scene ?

The user eye won't make the difference if there are only 6000 maybe, or if you fake some plenty of them if less objects but aggregated ones.

Or if you display in the fustrum only, say, 4000 objects, and recycle/  position / scale them quick when the cam moves in order to fake they are far more numerous in the environment than there are really in your pool.

 

What I mean is that this number of iterations seems to be huge for the CPU of this laptop and adding any other process (game logic, IA, collisions, etc) will need some more CPU anyway.

 

The SPS is only one mesh, so a fast draw call (in other words, you can't get more perfs in the render process) and a big iteration over the particles and their vertices. The embedded optimizers just allow to skip some internal computation if they are not needed.

Then the chase of memory allocations within the render loop, which will trigger the GC, is the next lead to explore : the browser profiler is your friend.

Finally the last lead to improve the framerate stays the number of iterations, so the number of particles or vertices.

 

Sometimes, just lowering under a certain limit (ex : from 10 000 to 6000) can get to recover 60 fps. It's not necesseraly a linear gain.

 

[EDIT 2] a PG would help to check if we can improve something ;-)

[MasterSplinter]

Well a BJS cube (as a 3js one) is 24 vertices : 6 sides of 4 vertices each.

You can't reuse the vertices (for 3 common sides for instance) on a cube because of the rule :

a vertex == a normal

 

Normals aren't shared by the sides on a cube. 

Makes perfect sense lol silly me!

[MasterSplinter]

I agree that you can't tell the difference.  

 

This is for someone and I think they want to see what kind of performance I can get out of a browser.  According to the specifications this seemed like the best solution.  If I could I just billboard these things create 3 different sprites and only have 40k vertices.

 

THREE can't even do this stuff.

[jerome]

Arf...

If you need only 2D or billboarded things, you might then use the standard BJS Particle System, what is more performant !

[MasterSplinter]

It has to be 3D

[MasterSplinter]

Here is the src:

 

https://rawgit.com/wpdildine/Cubenado/master/app/index.html

[jerome]

Reading your code, I can't see many things to improve...

unless maybe setting once for all the particle colors at initialization time (random color for each) and then never update the color again : you won't see the difference between randomly setting the colors once at the beginning and randomly setting them each call to recycle()

 

Nevertheless, you could then set computeParticleColor to false after an initial call to setParticles() before the render loop for instance and thus skip a tiny part in the iteration process.

 

I really like your demo with this nice control panel.

[jerome]

thinking about something more

10K cubes are 24K vertices and 16K triangular facets, so a big number for computeNormals() also

 

So if you don't need the normals to be updated once the mesh is built, you could also freeze them : sps.mesh.freezeNormals()

This would accelerate the speed, but will also have an effect on the light reflection.. depending on if you need it or not : standard particles are 2D and don't have normals, don't reflect the light as well in bjs as in 3js

[MasterSplinter]

Thanks!  I went a bit css crazy with the control panel.  

 

I'll probably make that change you suggested.  It seems to get me about 2 fps boost but aside from that I don't think there is a whole lot more I can do without lowering the particle count. 

[MasterSplinter]

thinking about something more

10K cubes are 24K vertices and 16K triangular facets, so a big number for computeNormals() also

 

So if you don't need the normals to be updated once the mesh is built, you could also freeze them : sps.mesh.freezeNormals()

This would accelerate the speed, but will also have an effect on the light reflection.. depending on if you need it or not : standard particles are 2D and don't have normals, don't reflect the light as well in bjs as in 3js

 

Okay, just pushed those changes -- I guess I can't really complain about 10k cubes getting 20fps on a non gaming laptop.  Probably, the best I'll get without cheating.

[jerome]

last lead again, if the material doesn't change : material.freeze()