# C++ vector Approaches to Octree's

there, I am making a strategy 3d game somewhat like Global Superpower, its much simpler mechanic wise but im now attempting to make performance improvements, now I am wondering what sort of approach would be good for my game, specifically in the way of moving entities addresses into vectors - that would relate to my Octree's well, stricly speaking its not a true octree, but it is the world divided into 8 Cubes, to reduce collision and unit combat stress instead of searching through the whole vector.

Diagram - of my current approach

There is a problem with this approach, I am struggling to manage pushing and popping the entities onto the vectors as they require a new instance of an entity, not a current entity, I have tried creating something like vector<entity*>*myaddresses -but its not worked.

Any idea how I can do it for just addresses or is there a better approach ?

• Saying it didn't work doesn't tell anything. Please, show the code and state the problem clearly. – lisyarus Jun 18 '17 at 22:13
• -1 The most important thing about performance optimizations is: Measure your code, use profilers. Dont start "optimizing" stuff, because your gut feeling tells you so, especially if you are a beginner in a language (the pointer error implies that) Please update your question with those profiles and we can discuss solutions. – Maik Semder Jun 19 '17 at 9:54
• @MaikSemder sorry I'm working on it, my code is quite messy so I'm trying to present it in a way easily understandable, because my class is quite large and complex. – RNewell122 Jun 19 '17 at 10:47

Hard to say without more context, but here's my gut feeling as to what your issue is.

You can certainly store a vector of pointers, but

vector<entity*>* someVariableName


isn't a vector of pointers, it's a pointer to a vector of pointers, notice the second *. It should be

vector<entity*> someVariableName


As an aside, if performance is your focus here, I'd recommend storing a vector of small structs which contain your entity pointer, and a copy of some of the most relevant information you're likely to use when searching the octree. For example

struct EntityInfo
{
Entity* myEntity;     // Entity pointer
BoundingSphere myBounds;
UnitType myUnitType;  // Type of unit
PlayerId myOwningPlayerId; // Owner
};

vector<EntityInfo> myContainedEntities;


Why? Because ideally if you're writing fast code, you want to avoid repeatedly accessing objects that are scattered around in memory (which is often the case when you're dealing with pointers). If you store a contiguous array of structs containing the most common info that's typically searched for, then you can potentially reject entities without ever dereferencing the entity pointer (and likely incurring the cost of a cache miss).

Obviously you can't optimise every single octree access, but it's something to bear in mind.

• Hey thanks, I will try this out, I'm also going to update the question, so its a bit more explanatory, but thanks @Bryan Robertson :) – RNewell122 Jun 19 '17 at 10:48