[solved] SPS question - adding meshes or instances after creation

[fenomas]

I have a question about using an SPS to manage merged scenery - i.e. trees and bushes and whatnot.

To start with, let's say that my scene has 50 trees and 50 bushes. They are all static, so rather than use instances I want to merge them all into one big "scenery" mesh. I'd like to use SPS for this, for convenience so that I don't have to manually mess with vertex lists, etc.

So, I create an SPS, call "addShape(tree, 50); addShape(bush, 50);", and then I set each particle position, and I call "buildMesh()". Once created, the scenery is essentially static, so there's no need for any update functions, particle recycling, etc.

Now, my question:  Suppose that later on I need to add a flower to this scenery mesh, or I need more trees beyond my initial number. Is it possible to add new shapes to the SPS after creation like this, or do I need to dispose and recreate the SPS?

Follow up: if it is possible, would it make sense in my situation? If there is a performance benefit to having the SPS be immutable, I'd rather have it perform faster in the general case even if there's a cost to re-creating it. But if there's no performance benefit I'd rather update it incrementally.

Thanks!

[jerome]

quick answer : the SPS can be seen as an API to access/modify one big mesh from its subparts (the solid particles)

So, it has one fix-sized geometry once created. This means you can't add any particles once built. If this need exists, then two options :

- dispose and recreate a new SPS with more particles if you feel OK with this delay (or create the new one before disposing the first and just swap them when ok)

- create in advance all the particles in a single SPS, even if they aren't visible initially (you can manage the per particle visibility and/or the per particle processing : you can choose to update only some kinds of particles or only some ranges of particles to go faster)

An immutable SPS is simply an non-updatable mesh. Its performance gain is the same than the one in the comparison between updatable/non-updatable meshes.

The performance differences are comparable to other/any updatable/non-updatable meshes

Moreover, an immutable SPS doesn't store the particle data (positions, rotations, velocities, colors, uvs, etc), so it's also less consumed memory. It's really designed for creating things that will never evolve once created, like maze walls, asteroid fields, trees and buildings in the distance, etc.

Note well that a standard (not immutable) SPS is updated only when you call setParticles(), what is not required to be called each frame. So I think the performance gain between an immutable SPS and a standard one is really really low if you don't update the standard one at all (or very rarely).

Depending on the frequency or the probability of the need for the landscape update, I would opt for single SPS with a large pool of possible things to be spawned.

example here (not static but same principle) : http://jerome.bousquie.fr/BJS/Starfighter/

The blue laser lights in the distance, the laser impacts on the enemies, the enemy explosions, the enemy laser crosses, and the stars are all the same SPS. 

[fenomas]

Ok, thanks!

In my case the player can add meshes to the scenery, so it's probably not feasible to pre-allocate a pool since I can't know what will be needed. So it sounds like I will need to re-create the SPS each time it changes.

But on the other hand, I might as well make it immutable - since there's no need to leave the duplicated vertex arrays in the JS heap if I won't be updating them.

Does that sound right?

[jerome]

fully right !