-
-
Notifications
You must be signed in to change notification settings - Fork 4.9k
Components as entities (v2) #24728
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
base: main
Are you sure you want to change the base?
Components as entities (v2) #24728
Changes from all commits
22e24fb
96d54c9
45ff041
5e9d8fa
16f2b9e
c6d1670
a7d5879
eed38d9
a6d7ea3
9056e8a
8430a66
63cd089
50ec233
731b5e6
05c6204
cc02f45
958d2bb
50af152
3f3d76a
de65238
b02a412
c2678eb
56009dc
2c764e6
faf0adb
0d4bcf7
ff207f8
38489bb
9357ba2
c0597ca
a7a2972
2d8488a
9137f52
31c9675
aacc2bb
fb25d44
fe62ef1
ee670da
2563181
13a8779
876989f
35c6b0e
bf50639
97fcd15
0309e8d
43d6314
f6789d8
bf97958
be0ccf4
d53700e
8256f1d
7bd9d4b
0bdcb2b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,36 @@ | ||
| --- | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I can see some rather big regressions here: Some are pretty niche, but I find interesting that Edit: or are after/before perhaps switched?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think after/before were switched. As per my comment, while the micro benchmarks show some regressions, performance is not the only reason for this PR. Furthermore, the stress tests (which are more representative for real world usecases) don't show a significant decrease in performance. Further furthermore: A fix for any performance issues already exists in #24102, but that's something best left for a separate PR.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's also possible that my laptop (bless their soul) is not super reliable for benchmarks, but it tried its best. |
||
| title: "Components as Entities" | ||
| pull_requests: [24728] | ||
| --- | ||
|
|
||
| - `ComponentId::new` now takes `Entity` as an argument instead of `usize`. For debugging, you can use `ComponentId::from_u32`. | ||
| - `ComponentId::index` was removed in favor of implementing `ContainsEntity`, call `ComponentId::entity` to get the underlying entity. | ||
| - `ComponentIdSet` is now an `EntityEquivalentHashSet` instead of a `FixedBitSet`. | ||
| - `ComponentIdSet::is_clear` has changed to `ComponentIdSet::is_empty`. | ||
| - `ComponentIdSet::difference` has changed to `-`, i.e.: `difference = set - other`. | ||
| - `ComponentIdSet::intersection` has changed to `&`, i.e.: `intersection = set & other`. | ||
| - `ComponentIdSet::union` has changed to `|`, i.e.: `union = set | other`. | ||
| - Other methods have remained the same. | ||
| - `ComponentIds` has been removed. Instead of `ComponentIds`, `ComponentsRegistrator::new` now takes `EntityAllocator`, while `ComponentsQueuedRegistrator::new` now takes `RemoteAllocator`. | ||
|
Trashtalk217 marked this conversation as resolved.
|
||
| - `Access` and `EcsAccessType` no longer derive `Hash`. | ||
| - `ResourceEntities` was removed. The following methods have been removed with it: `World::resource_entities`, `EntityWorldMut::resource_entities`, `UnsafeWorldCell::resource_entities`. It can also no longer be used as a system param. If you need the entity linked with a `ComponentId`, simply call `component_id.entity()`. | ||
| - The `component_id` field has been removed from the `IsResource` component, along with `IsResource::new` and `IsResource::resource_component_id`. If you need the `ComponentId` for a resource dynamically, you can simply query `Entity` alongside the resource you want and wrap it: `ComponentId::new(entity)`. | ||
|
|
||
| In 0.19, you could attach components to a resource by simply calling `world.spawn((Res1, Comp1, Comp2))`. In 0.20, this no longer works as `Res1` needs to be on the resource entity allocated by `world.register_component<Res1>()`. In 0.20, adding components looks as follows: | ||
|
|
||
| ```rust | ||
| let entity = world.register_component::<R>().entity(); | ||
| world.spawn_at(entity, (Res1, Comp1, Comp2)); | ||
| ``` | ||
|
|
||
| Additionally, manually implementing `Resource` through | ||
|
|
||
| ```rust | ||
| #[derive(Component, Default)] | ||
| struct R; | ||
|
|
||
| impl Resource for R {} | ||
| ``` | ||
|
|
||
| has become less viable, as now `Res` and `ResMut` panic when `IsResource` has not been made a required component for a resource. | ||
| Use `#[derive(Resource)]` instead. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From my unaddressed comment in the linked PR:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I know, we don't have benchmarks to measure hook access. The particular performance problem you describe can be fixed through #24102.
With regards to the
bevy_world_serializationproblem, this is where it gets clever. Mapping entities between worlds has already been solved throughSceneEntityMapper. The idea is that we can use this just as well forComponentIds whenComponentIds are just entities.