AFAIK
- Instanced meshes have their world matrices, bouding boxes, bounding spheres and frustum tests computed each frame.
The final performance, CPU side, is more related to the global number of instances. - Solid particles have their lighter dedicated world matrices (and, optionnally their Bboxes, BSpheres) computed only on the call to setParticles() . The frustum test isn’t enabled by default.
The final performance, CPU side, is more related to the global number of vertices.
So, numerous high poly instanced meshes should be better than the SPS. In other hand, numerous low poly (<50 vetices) solid particles should be better than instanced meshes. Cylinders being high poly meshes, instances seems to be the right choice.
That said, dealing with high number of high poly objects is quickly painful regarding the FPS perfs.
Knowing that a screen has a limited area and that the user can’t see all the meshes at once, I would suggest two tricks :
- maybe reducing the global number of managed meshes. Who can make the difference at sight between 50K and, say, 30K meshes especially if they aren’t visible at once ? It’s a big difference for the CPU.
- recycling meshes : a logical data map could describe where and how are all the meshes at the current time and only the visible ones (so just a part of them are initially built) are rendered using a pool af pre-built meshes.
That’s the way used in this example : 3000 solid particles, recycled according to the camera position, to render more than 70K ones Test Babylon SP Terrain