You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Allocating large amounts of cube nodes can take some time. In addition, we just throw them away by calling the destructor of the cube nodes. It would be much better to allocate a large amount of cube nodes ahead, and to have some sort of request system when we need new cube nodes. When no longer needed, the nodes can be "given back" to the allocator, instead of calling the destructor. Given the fact we want to have multiple octrees (cube root nodes), we should aim for one allocator for all the worlds.
Is your feature request related to a problem?
Allocating large amounts of cube nodes can take some time. In addition, we just throw them away by calling the destructor of the cube nodes. It would be much better to allocate a large amount of cube nodes ahead, and to have some sort of request system when we need new cube nodes. When no longer needed, the nodes can be "given back" to the allocator, instead of calling the destructor. Given the fact we want to have multiple octrees (cube root nodes), we should aim for one allocator for all the worlds.
Description
Here is some more info about allocators:
https://www.youtube.com/watch?v=nZNd5FjSquk
https://www.youtube.com/watch?v=CFzuFNSpycI
https://www.youtube.com/watch?v=l14Zkx5OXr4
https://www.youtube.com/watch?v=Ctfbs6UVJ9Y
Lucky for us, we could use the new C++ features for writing the allocator:
https://badlydrawnrod.github.io/posts/2021/12/30/monotonic_buffer_resource/
Alternatives
Do not use an allocator, but accept the fact we will probably be dealing with a lot of memory in an unoptimized way in the future.
Affected Code
The octree code
Operating System
All operating systems
Additional Context
None
The text was updated successfully, but these errors were encountered: