Sign in to follow this  
zfvesoljc

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

Recommended Posts

zfvesoljc    604

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
Hodgman    51234

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
lawnjelly    1247

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
Alberth    9508

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
Krohm    5030
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
zfvesoljc    604
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
zfvesoljc    604
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  

  • Similar Content

    • By evolvegames
      [attachment=35462:Screenshot_2017-03-29-14-34-31-692_com.EvolveGames.MinesweeperGo.png]
       
      Minesweeper Go is a variant of well-known classic minesweeper game.
       
      As opposed to classic version Minesweeper Go were designed by keeping in mind demands of professional minesweepers.
       
      Beta version of the game released on android play market and available here: Google Play
       
      Here is a small list of key features:
       
      - Game playback
      Each game is recorded and you can playback it any time you want
       
      - Advanced chording
      Chord can be applied recursively so players can achieve fastest board solving times
       
      - Personal comprehensive score board with various benchmarks.
       
      - Advanced benchmarks
      Minesweeper Go calculates players 3BV/s values, Taps count, Taps/s, RQP, IOS, IOE and some other stats that are valuable for advanced players
       
      - Explicit Non-Flagging (NF) mode
      Game is made with No-Flaggers in mind
       
      - 3BV control feature
      You can generate a custom minefield with predefined 3BV value
       
      - Online World Ranking table 
      All players can participate in World Ranking. Each player records can be viewed (and replayed) by other players to make sure of theirs authenticity
       
      - Cheats.
      Undo on fail, etc.
       
      Some of other features are in progress and will be implemented soon. Notable ones are here:
      - Tournament mode
      - Themes
      - Board save/restore
      - Playback speed tuning and rewinding options
       
      If you like it please leave your feedback on Minesweeper Go Facebook page https://www.facebook.com/minesweepergo
       
      Thanks.
       
      [attachment=35460:Screenshot_2017-03-25-17-46-03-282_com.EvolveGames.MinesweeperGo.png][attachment=35461:Screenshot_2017-03-25-17-59-09-348_com.EvolveGames.MinesweeperGo.png]
    • By MarcusAseth
      I need some help to understand what I'm doing wrong here x_x
      Here's my step:
      1) create a new C++ project with starting content, drop a door in the scene.
      2)Add a C++ component to the door called OpenDoor
      3)add a variable in the .h and initialize it in the .cpp  (code below)
      When I compile this, the editor crash and any future attempt to open the project won't succede. What mistake did I made? Furthermore, if said mistake is made, is the project lost forever or there is a way to restore it? x_x  Cause if wathever silly mistake I've made, if it's all it takes to corrupt and lose an entire project, then I'm done with Unreal Editor... x_x
      OpenDoor.h:
      // Fill out your copyright notice in the Description page of Project Settings. #pragma once #include "CoreMinimal.h" #include "Components/ActorComponent.h" #include "OpenDoor.generated.h" UCLASS( ClassGroup=(Custom), meta=(BlueprintSpawnableComponent) ) class BUILDINGESCAPE_API UOpenDoor : public UActorComponent { GENERATED_BODY() public: // Sets default values for this component's properties UOpenDoor(); protected: // Called when the game starts virtual void BeginPlay() override; public: // Called every frame virtual void TickComponent(float DeltaTime, ELevelTick TickType, FActorComponentTickFunction* ThisTickFunction) override; private: float DoorYaw; };  
      OpenDoor.cpp:
      // Fill out your copyright notice in the Description page of Project Settings. #include "OpenDoor.h" #include "GameFramework/Actor.h" // Sets default values for this component's properties UOpenDoor::UOpenDoor() :DoorYaw{GetOwner()->GetActorRotation().Yaw} { // Set this component to be initialized when the game starts, and to be ticked every frame. You can turn these features // off to improve performance if you don't need them. PrimaryComponentTick.bCanEverTick = true; // ... } // Called when the game starts void UOpenDoor::BeginPlay() { Super::BeginPlay(); // ... } // Called every frame void UOpenDoor::TickComponent(float DeltaTime, ELevelTick TickType, FActorComponentTickFunction* ThisTickFunction) { Super::TickComponent(DeltaTime, TickType, ThisTickFunction); // ... }  
    • By MarcusAseth
      I'm getting a "red minus icon" next to all my .h and .cpp inside of the VS 2017 solution explorer, anyone knows what does it means? It is red so it doesn't mean anything good, right?
    • By povilaslt2
      Hello. I'm Programmer who is in search of 2D game project who preferably uses OpenGL and C++. You can see my projects in GitHub. Project genre doesn't matter (except MMO's :D).
    • By King Mir
      I'm trying to find a good precise numeric solution for my problem.
      Background:
      I'm trying to create a trade simulation between cities. Each demands a certain amount of a resource and may have a certain number of importers cities that provide that resource. A city needs to take an equal fraction of each importer's resources, and the sum of the amounts taken must add up to the amount demanded. For example, if a city demands 2 bushels of grain, and has three importers, it will take 2/3 of the resources form each importer city, and the sum must add up to 2. Cities will always produce and demand an integer amount of goods, but a city may export to multiple places, so the amount of goods available may be a rational number. At no point are irrational numbers needed.
      Limitations:
      I'm working in C++ and emscripten. This means I cannot link any library to my project; I must include the whole source. For this reason, I'd prefer not to include any large library. I don't want to use boost. This is a closed source project, so I can't use anything GPL.
      Options:
      1) Use floating point with an epsilon. But I'm not sure how to pick the right epsilon here. This reproach has the advantage of being fast and simple though.
      2) Use fixed point. If I use scaling factor that's a multiple or several lowest factors, it may be precise. But I need to ensure that any numerator of my fractions is a factor of the scaling factor. I'm not sure if I can ensure this. But if a city imports from at most N cites, and the scaling factor is N!, maybe this could work? or some version of it?
      3) Use rational numbers. This ensure that calculations are precise all around. If I implement this myself, this is the most complex option.

      The Ask:
      I'm wondering if anyone here has any suggestions as to which is the best option for my use case, and if there are any libraries I might be able to use.
  • Popular Now