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

SyncEntityPool Proposal #13576

Closed
dmyyy opened this issue May 30, 2024 · 1 comment
Closed

SyncEntityPool Proposal #13576

dmyyy opened this issue May 30, 2024 · 1 comment
Labels
A-ECS Entities, components, systems, and events A-Tasks Tools for parallel and async work C-Feature A new feature, making something new possible X-Controversial There is active debate or serious implications around merging this PR

Comments

@dmyyy
Copy link
Contributor

dmyyy commented May 30, 2024

What problem does this solve or what need does it fill?

I use worlds as scratch-space in my async tasks. This is a powerful pattern that gives you the flexibility of the ecs, while working on a single chunk of work with exclusive world access.

I take snapshots of the world occasionally. After finishing all my work in my async task I merge the scratch-world back into the main world via

scene.write_to_world_with(main_world, &app_type_registry);

I need to reserve entities ahead of time in the main_world (and in the scratch world) so the address spaces match. This isn't an issue when you can figure out how many entities you need ahead of time

let reserved_entities = world
	.entities()
	.reserve_entities(ENTITY_COUNT)
	.collect();

Because I'm using the world as scratch-space there is a certain number of entities I can't account for ahead of time. If I write a scene to my main world there is a chance I will override an unrelated entity that is being used for something else.

What solution would you like?

I should be able to reserve a pool of entities. This pool of entities can give out EntityHandle's that allow you to temporarily borrow the entity and store some information on the world. When you drop the handle - the entity is reclaimed by the pool.

For simplicity sake it's fine for my use case if the pool isn't grow-able.

Sample API Attempt

pub struct EntityHandle {
    pub entity: Entity,
    // can only be used in a single-threaded context
    pool: RefCell<EntityPool>,
}

impl Drop for EntityHandle {
    fn drop(&mut self) {
        // reclaim entity in pool 
    }
}

pub struct SyncEntityPool {
    raw_entities: Vec<u32>,
    in_use: Vec<bool>,
}

impl SyncEntityPool {
    /// Reserve `capacity` number of entities  
    pub fn new(capacity: usize, world: &mut World) -> Self {
        let entities = world.entities().reserve_entities(capacity).collect();

        Self {
            raw_entities: entities.into_iter().map(|e| e.index()).collect(),
            in_use: Vec::with_capcity(entities.len()),
        }
    }

    // given an entity pool that already exists
    pub fn reserve_in_world(&self, world: &mut World) {
        for e in self.raw_entities.iter() {
            // reserve entity in world
        }
    }

    pub fn get_handle(&mut self) -> EntityHandle {
        ...
    }
}

What alternative(s) have you considered?

This seems kind of similar to the AsyncEntityPool that @cart showed off a little while back for assets as entities. This is slightly different since the goal is to make something that makes it easier to work with exclusive world access and synchronize address spaces across worlds when you don't know how many entities you will need ahead of time.

Additional context

@dmyyy dmyyy added C-Feature A new feature, making something new possible S-Needs-Triage This issue needs to be labelled labels May 30, 2024
@alice-i-cecile alice-i-cecile added A-ECS Entities, components, systems, and events A-Tasks Tools for parallel and async work X-Controversial There is active debate or serious implications around merging this PR and removed S-Needs-Triage This issue needs to be labelled labels May 30, 2024
@dmyyy dmyyy changed the title EntityPool Proposal SyncEntityPool Proposal May 30, 2024
@dmyyy
Copy link
Contributor Author

dmyyy commented Jun 2, 2024

After prototyping I'm convinced this is just a more fragile version of SceneEntityMapper

@dmyyy dmyyy closed this as completed Jun 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-ECS Entities, components, systems, and events A-Tasks Tools for parallel and async work C-Feature A new feature, making something new possible X-Controversial There is active debate or serious implications around merging this PR
Projects
None yet
Development

No branches or pull requests

2 participants