Actors have a huge memory footprint. It would be better to store the octree nodes as structs and have one actor that manages all nodes.
One way to do this would be by storing all node structs in a list. The octree structure would be stored by storing in each node the indices at which its children appear in the list. Its quite a change in approach but in this case it would improve performance a lot since the straight forward OOP approach doesn’t work well here due to the cost of objects.
If you’re going to try the struct list approach, you should take into account that each node either has 0 children (if not subdivided) or 8. With the exception of the root node, all octree nodes have 7 siblings and generally you create and delete them at the same time, so if you keep sibling nodes together in the list you only need to store the first child index in the parent (envision the list as groups of 8 nodes each).
I agree with Nisshoku, structs are the way to go in this case. When I created the quadtree stuff for the TurnBasedStrategy project, I didn’t have Blueprint Structs to work with And the number of Actors I needed was far less than what you’d require for an octree. I’ll probably be refactoring what I did in the near future.
After playing a bit with Structs and stuff, I noticed that it is not possible to have recursive structs!? However, these are essential for any tree-like structure. Anyone got an idea to make this only with blueprints?
Its a struct that contains itself, didn’t came up with a better name, sorry UE4 doesn’t allow this, not even in Unreal C++ (Dunno why, normal C++ allows this).
Currently, I tested 3 BPs with 8^5(32768) cubes, so in total 98304 actors. The only thing I didn’t do was to use static mesh instancing for visual feedback so if switch to instanced meshes, the performance should be better. I’ll see if the performance gets significantly better with that, if not, I have to come up with a C++ Class solution. Programming itself is not an issue, but learning C++ is especially if you want things very performant.
I just wanted to see how far I could come with just BPs.
I did a few tests with BPs again but this time without any meshes. I was able to go up to 32k(8^5) actors with maintainable fps(about 90fps). However 262k(8^6) actors were still too much to handle. The editor had some crazy fps drops every few seconds. If it was not lagging, the FPS were about 60. Memory Consumption was about 4gb for the whole editor. every child had its tick disabled of course. Maybe I can push it further so 262k childs will be no problem. Octrees with 8^7(2097152) or even more childs should be done in C++ under any circumstances. They are usually not even needed since they’re dynamic and not static.
From my own tests, the number of actors isn’t really the problem, but how much combined memory they all take up. Spawning 80K 2MB blueprints gives me the hiccups you describe. As did ~200K+ actors at 500KB.
What stat/console command shows how much memory the actors use? I found several, but not one that changed upon spawning 80K actors into the world.
I am probably going to use specifically indexed struct arrays to replicate what you would get by storing the data in actors.