Jump to content
  • Advertisement
Sign in to follow this  
zfvesoljc

C++ Movable struct, how to keep reference to it

This topic is 398 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement

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]]

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
On 8/8/2017 at 8:15 AM, zfvesoljc said:

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?

If I understand, your generic problem is: you have an object container with an object inner inside. You destroy container and poor inner goes with it. Too bad you need to keep referencing it so you're blasted and you need to reconstruct.

All fine and dandy but... you have misunderstood your resource ownership . If inner is owned by container then when container goes it brings its owned resources with it and user systems are screwed.

In the general sense of particle systems that sounds bogus but maybe you're more like "replicating" objects somehow so what you do?

Review your container to use external resources allowed to exist by themselves. When newOwner takes control of them, pull em out of container or mark them 'non-owned'. When container goes belly-up it either destroys its owned resources or they get destroyed by some external function doing the check at higher level.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!