On #63 I highlighted the current architecture. Now I'll highlight how it will be, in order to better use Bevy ECS capabilities.
ECS systems over async
One thing that bothers me is the fact that we have to use async in order to do some computations. Voxel engine can be very CPU intensive (or GPU, if you decide so), which means it's desired to offload the processing to a different thread, so the main game logic doesn't suffer the lack of CPU.
Instead of using async tasks, we should create another ECS world, a server world, and use systems to process what is needed. But this brings some questions/problems:
Execution time - It's hard to keep system execution time low, since it'll depend on how many chunks are processed;
Execution order - Some steps may loop over others, but we can use run conditions and system ordering for that;
Chunk as entities
A chunk is just and location (or IVec3), which can be also seen as an ID, pretty much like an Entity. Until Bevy has Indexed capabilities, we can use a simple HashMap<IVec3, Entity> to keep track of which entity is each chunk.
Work in Regions
The cache system should work in regions, to avoid reading/writing from/to disk one chunk at the time. Also, when loading, keep the entire region loaded. If this consumes too much memory, we can always compress/decompress data and keep and LRU cache only with most recently used data.
In the end all chunks will have the same archetype, which will make things O(1).
On #63 I highlighted the current architecture. Now I'll highlight how it will be, in order to better use Bevy ECS capabilities.
ECS systems over async
One thing that bothers me is the fact that we have to use async in order to do some computations. Voxel engine can be very CPU intensive (or GPU, if you decide so), which means it's desired to offload the processing to a different thread, so the main game logic doesn't suffer the lack of CPU.
Instead of using async tasks, we should create another ECS world, a server world, and use systems to process what is needed. But this brings some questions/problems:
Chunk as entities
A chunk is just and location (or
IVec3), which can be also seen as an ID, pretty much like anEntity. Until Bevy hasIndexedcapabilities, we can use a simpleHashMap<IVec3, Entity>to keep track of which entity is each chunk.Work in Regions
The cache system should work in regions, to avoid reading/writing from/to disk one chunk at the time. Also, when loading, keep the entire region loaded. If this consumes too much memory, we can always compress/decompress data and keep and LRU cache only with most recently used data.
In the end all chunks will have the same archetype, which will make things O(1).