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
What is the aspect of the project that needs optimization?
The VoxelStorage::<T> component currently stores an instance of T on each block within the chunk. This, in theory, leads to a lot of redundancy between block data instances. As a result, as the complexity of T increases, the memory usage for the chunk increases exponentially.
Describe the solution you'd like
By adding a lookup table for VoxelStorage::<T> chunks, the memory usage can be reduced to just two bytes per block plus the lookup table size. In general use cases where reusing block data is expected, this can drastically reduce the memory usage for chunks.
Why is this proposal significant, and what are the expected performance benefits?
While this effect reduces memory usage in most cases, it does make writing data to chunks a bit slower since it has also to update the table and look for duplicate entries. In addition, where scenes have lots of different block types stored with very little redundancy, this method increases memory overhead instead.
Additional context
In might be very useful to add this feature as a configuration flag or compilation feature of some kind to enable or disable this optimization for projects based on performance results.
The text was updated successfully, but these errors were encountered:
it would be useful to have various different types of data that can be associated with at tile. For example a tile having an Inventory or a Damage stats. These would be best stored in a global hashmaps, i think. the difficulty with that is, that we would want unloaded chunks to not have their blocks in these hashmaps. but it would allow for an easy way to access such thing, for example like this:
fnsystem_update_spawners(commands:Commands,spawners:Res<BlockData<Spawner>>){for(world, spawner)in spawners {// do stuff with spawner}}
where world is either the position of the block, or something like the thing described in #9 (i am not sure whenever this should be its own parameter or just included in this thing), and spawner is the struct that contains the actual spawner data.
I'm not sure how to implement it exactly right now tho.
What is the aspect of the project that needs optimization?
The
VoxelStorage::<T>
component currently stores an instance ofT
on each block within the chunk. This, in theory, leads to a lot of redundancy between block data instances. As a result, as the complexity ofT
increases, the memory usage for the chunk increases exponentially.Describe the solution you'd like
By adding a lookup table for
VoxelStorage::<T>
chunks, the memory usage can be reduced to just two bytes per block plus the lookup table size. In general use cases where reusing block data is expected, this can drastically reduce the memory usage for chunks.Why is this proposal significant, and what are the expected performance benefits?
While this effect reduces memory usage in most cases, it does make writing data to chunks a bit slower since it has also to update the table and look for duplicate entries. In addition, where scenes have lots of different block types stored with very little redundancy, this method increases memory overhead instead.
Additional context
In might be very useful to add this feature as a configuration flag or compilation feature of some kind to enable or disable this optimization for projects based on performance results.
The text was updated successfully, but these errors were encountered: