Sign in to follow this  
zfvesoljc

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

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

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

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Partner Spotlight

  • Forum Statistics

    • Total Topics
      627668
    • Total Posts
      2978540
  • Similar Content

    • By Finalspace
      I am playing around with ImGui, adding a UI to my level editor, but i am having trouble with mouse clicks in ImGui triggers a click in my actual editor (Because it uses the same input states).
      Right know i have just a main menu bar and the editor rendering is behind that. When i click on a menuitem for example, and select another sub item and click, i place a block in my editor - just because the input events are the same for both ImGui and my editor.
      So i have a few questions:
      1.) Is there a way to detect when ImGui has taken any action/hover in the previous frame, so i can skip the input handling for my editor? (This way i can prevent the issue i have right now)
      2.) Can i add a imgui window which fully fits the rest of the entire screen - after a main bar has been added? (Do i manually need to calculate the size?)
      3.) Should i make the entire editor with ImGUI only - so i wont get any input fuzziness problems?
    • By irreversible
      I'm writing some code for automatic function argument type deduction using a tuple. I'm then iterating over it to narrow down and check each argument separately. I spent a cozy evening tinkering with getting by-value, const value and const references to work, until I discovered that some functions need to return more than one result. This is where I need to identify non-const lvalue references, which a tuple has difficulty in handling.
      As far as I can tell most problems out and about on the web focus on creating fairly simple stand-alone tuples that only contain lvalue references using std::tie. In particular, this stackexchange thread outlines how that can be accomplished. 
      Problem is, I have a packed array of types, which may or may not contain one or more lvalue references interleaved with other types. forward_as_tuple is suggested here and there, but I'm unsure how to use it. 
      Here's there relevant code:
      // split the return type from the argument list template<typename R, typename... Args> struct signature<R(Args...)> { using return_type = R; using argument_type = std::tuple<Args...>; // 1 }; template<typename FUNCSIG> editor::nodetype_t& CreateNodeType( IN const char* category) { // instantiate the argument list tuple. No need to post any further code as this // is where things fail to compile signature<FUNCSIG>::argument_type arglist; // 2 } // the below snippet outlines how CreateNodeType() is called: #define DEFINE_MTL_NODE(function, category, ...) \ auto& nodeType = CreateNodeType<decltype(function)>(category); // a sample function for completeness. I'm intentionally not using the return value here. void Lerp( IN const math::vec3& ColorIn1, IN const math::vec3& ColorIn2, IN float Alpha, OUT math::vec3& ColorOut) { .. } void main() { DEFINE_MTL_NODE(Lerp, "Color"); } Either the line marked with 1 or 2 needs to be something else, but apparently my C++ level is not high enough to figure out what. PS - to further complicate things, I'm stuck on C++11 for now.
      Ideas?
    • By noodleBowl
      I got a quick question about buffers when it comes to DirectX 11. If I bind a buffer using a command like:
      IASetVertexBuffers IASetIndexBuffer VSSetConstantBuffers PSSetConstantBuffers  and then later on I update that bound buffer's data using commands like Map/Unmap or any of the other update commands.
      Do I need to rebind the buffer again in order for my update to take effect? If I dont rebind is that really bad as in I get a performance hit? My thought process behind this is that if the buffer is already bound why do I need to rebind it? I'm using that same buffer it is just different data
       
    • By noodleBowl
      When it comes to the copy, move, and assignment operators of a child class how is it supposed to look?
      If this is the implementation of my parent class
      //Default constructor Buffer::Buffer() { buffer = nullptr; } //Copy constructor Buffer::Buffer(const Buffer& other) { buffer = other.buffer; buffer->AddRef(); } //Move constructor Buffer::Buffer(Buffer&& other) { buffer = other.buffer; buffer->AddRef(); other.release(); //Free the buffer resource of the other instance } //Destructor Buffer::~Buffer() { release(); } //Copy assignment Buffer& Buffer::operator=(const Buffer& other) { if (&other != this) { release(); //Free the buffer of this instance buffer = other.buffer; buffer->AddRef(); } return *this; } //Move assignment Buffer& Buffer::operator=(Buffer&& other) { if (&other != this) { release(); //Free the buffer of this instance buffer = other.buffer; buffer->AddRef(); other.release(); //Free the buffer of the other instance } return *this; } And this is the implementation of my child class. Is this correct?
      I'm really just wondering about the at the copy, move, and I'm not too sure about the assignment operators
      //Default constructor VertexBuffer::VertexBuffer() : Buffer() { } //Copt constructor VertexBuffer::VertexBuffer(const VertexBuffer& other) : Buffer(other) { } //Move constructor VertexBuffer::VertexBuffer(VertexBuffer&& other) : Buffer(other) { } //Destructor VertexBuffer::~VertexBuffer() { } //Not sure how to handle the copy/move operators. //Do I treat them as there own operators and copy the Buffer assignment operators code? VertexBuffer& VertexBuffer::operator=(const VertexBuffer& other) { } VertexBuffer& VertexBuffer::operator=(VertexBuffer&& other) { }  
    • By SeraphLance
      After seeing this talk (and combined with similar experiences in other languages), I got to thinking just how many times I pointlessly copy variables around.  I'm sure it's a lot, and I'm sure more experienced C++ programmers are better at catching these things (especially given how off-handed he remarks these -- like they're "duh" to everyone in the room), but it feels like I'm a bit lost as to how to actually find these sorts of mistakes.  Right now it sort of feels like an "experience through code review" thing, and that's a bit disconcerting.  Are there tools or techniques to track this sort of thing, so that I can find whether I'm spuriously making copies where I didn't intend to?
      In context, the very first example he gives is the sort of thing I'd do if I thought I was being clever.
  • Popular Now