I have a SOA particle buffer, that I'm accessing by an index (I build a temp class which has references to the vectors inside the arrays). When particles die, I collapse the structure, copying particles to keep a continues array of data. Now, for some cases, an emitter would need to keep a reference (basically an index) or a handle of some sort to a specific particle (parent particle, sub emitter relationship). Any ideas how to nicely/fast do that? Preferably I would like to have a bi-directional link, at the moment, particles keep a list of affected emitter(s), which works in a way, but I need to do a dirty way of checking if emitter is still valid.

Any ideas would be appreciated.

Firstly I'd be asking whether there was really a need to keep such child->parent references, do the children really need to know what the parents are doing? Usually the emphasis in particle systems is on efficiency, and keeping the flow one way (parent->child) if possible would seem more efficient.

As a caveat I've only done simple particle systems, and I've always had emitters emit either simple particles or more emitters (in a separate list), independent of the parent after being created. Instead of a back reference to the emitter I'd maybe have some preset particle / emitter types that don't ever get destroyed so any info on their behaviour is never changed. Or simply have the different particle types in their own separate lists so you can run through them quickly without any branching.

However going with your suggestion, we can come up with ideas for ways of doing the back-references, but the best answer may depend on the types of particle system, the numbers of particles / emitters involved, how you want to do it (CPU or GPU maybe?), because this can affect things like the cost of branching / jumping around cache. The 'best' solution for 64 particles on a CPU might be quite different to the best solution for a million on a GPU for instance. Maybe you could flesh out your question with some more context?

Depending on the number of particles vs the number of particles to track, it may be useful to store the latter separately from the former, and accept non-contiguous access there.

On 08/08/2017 at 10:29 AM, Hodgman said:

In the case of a particle system, generally you only want to be able to keep track of all-of-the-particles, not reference any individual one of them

In the situations where you do need such a feature, generally I've seen a non-compacting array of indices. "ID's" are the indices into the "index array". When compacting the pool, you update the index array entries for any items that were moved. When accessing the pool though, you now have a double-indirection -- e.g. data[indices[id]]

Well, this is a situation where I need such a feature

Another way would be to create a combined particle-emitter object, which would act as both, but since particle is not really an object, I'd have to have a separate loop for those objects...

I also saw the double indirection array as a possible solution and will probably try that first.

On 08/08/2017 at 0:25 PM, lawnjelly said:

Firstly I'd be asking whether there was really a need to keep such child->parent references, do the children really need to know what the parents are doing? Usually the emphasis in particle systems is on efficiency, and keeping the flow one way (parent->child) if possible would seem more efficient.

As a caveat I've only done simple particle systems, and I've always had emitters emit either simple particles or more emitters (in a separate list), independent of the parent after being created. Instead of a back reference to the emitter I'd maybe have some preset particle / emitter types that don't ever get destroyed so any info on their behaviour is never changed. Or simply have the different particle types in their own separate lists so you can run through them quickly without any branching.

However going with your suggestion, we can come up with ideas for ways of doing the back-references, but the best answer may depend on the types of particle system, the numbers of particles / emitters involved, how you want to do it (CPU or GPU maybe?), because this can affect things like the cost of branching / jumping around cache. The 'best' solution for 64 particles on a CPU might be quite different to the best solution for a million on a GPU for instance. Maybe you could flesh out your question with some more context?

cpu powered, spike is 200 emitters/5k particles