SPS picking low performance on Chrome

[OXY11]

I have a SPS with about 60.000 particles, and it works well (30fps) on Chrome, Safari and FF too. (With pick off)
If I activate the "pick" to intercept the collision with the pointer on Safari and FF, the result is more than acceptable (25fps), but on Chrome drops down to 4/5fps.

1) There is a reason to explain this difference in performance on Chrome?

2) I can not explain that even if after activating the "pick", I off it, the fps does not increase more, remain low as if the "pick" was still active. (There is a way to free the CPU computation once the "picking" is no longer needed)

[jerome]

Well, not that easy to tell without a PG to check what or where it happens for 1 and 2

60K is still a big number... and maybe your solid particles have also each many faces, so the picking algo must test among 60 000 * the number of faces, what may increase quite fast

[OXY11]

hi,

i've modified an existing PG:

http://www.babylonjs-playground.com/#2FPT1A#74

When camera is close to the SPS "pick" is active and vice versa (camera radius 90 is the point of switch)

already this PG works much worse on Chrome that of Safari or FF.
and once you have activated the "pick", even if you walk away (pick off) performance remains low

 

in my real work particles are simple planes, in billboard mode

 

 

[jerome]

ok, those are tetrahedrons, so 4 faces... multiplied by the particle number : 2000

Well, as your particles don't need to be updated each frame with setParticles(), I moved it in the rollover callback function. This function is called only when a particle is picked, to the SPS is recomputed only when needed.

this one runs at 60 fps here : http://www.babylonjs-playground.com/#2FPT1A#76

this one also with 6000 particles and a cam radius limit increased to 900 : http://www.babylonjs-playground.com/#2FPT1A#77

[OXY11]

Thank you,
I try it on my project.
Thanks again

[OXY11]

unfortunately I can not do it this way because I need to update each frame with setParticles().

actually I need to "pick" only 1/10 of the total particles. (the blue ones) here: http://www.babylonjs-playground.com/#2FPT1A#80

can I make "pickable" only a part of the total? so as to avoid unnecessary "pick" computation of the other?

This could be a solution to improve performance?

any other solution?

 

 

 

[jerome]

Actually, if all your particles are to be rotated or updated in any way each frame, you really need to call setParticles() in the render loop. The main bottleneck is here as you can see here where there's no pick detection : http://www.babylonjs-playground.com/#2FPT1A#81

30 FPS in FF for me and 60 FPS in chrome here ... on my linux, chrome is ever twice faster than FF regarding WebGL. Are you sure that your WebGL settings are correct in Chrome ?

btw, Chrome on my machines can usually deal with up to 8-10K solid particles before the FPS starts to decrease from 60 depending on the logical custom process (aka particle behavior)

The only leads to improve the perfs would be in your case :

• not to use a rollover (what tests the picked result each frame : expensive)  but rather a mouse click event so the pick process would be triggered only on user clicks
• use some SPS optimizers if possible : not compute the colors each frame (computeParticleColor = false) and just enable it when a color is to changed, then disable it back
• user lesser particles ?
• or use two mixed SPS : one for the green particles with no interaction process and all optimizers on and another only for few blue particles
• the SPS is a mesh, so if it doesn't move, you can freeze its world matrix and maybe its material also, if any

[OXY11]

I solved.
I blamed picking form the poor performance, instead was due to another wrong function.
Now 60.000 particles - 45 / 60fps
Thanks again for your help.

[jerome]

you're welcome

glad to help you and to be confirmed that your huge SPS works well