Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Voxel Storage lookup tables #6

Open
TheDudeFromCI opened this issue Dec 16, 2022 · 1 comment
Open

Voxel Storage lookup tables #6

TheDudeFromCI opened this issue Dec 16, 2022 · 1 comment
Labels
optimization Adds a performance enhancement

Comments

@TheDudeFromCI
Copy link
Member

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.

@TheDudeFromCI TheDudeFromCI added the optimization Adds a performance enhancement label Dec 16, 2022
@PhantomMorrigan
Copy link

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:

fn system_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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
optimization Adds a performance enhancement
Projects
None yet
Development

No branches or pull requests

2 participants