Components as entities (v2) by Trashtalk217 · Pull Request #24728 · bevyengine/bevy

Trashtalk217 · 2026-06-23T17:31:42Z

Objective

There are two primary problems we currently have with resources-as-components (#19731) .

Performance regression #23039

In order to get access to a resource entity, you usually need to go through two lookups: TypeId -> ComponentId -> Entity. The ComponentId -> Entity lookup can potentially be removed, speeding up resource lookup.

World Asset Serialization (previously in bevy_scene) #22968

Currently, one big downside of resources-as-components is that any components on resource entities aren't serialized. This forms a barrier for implementing required components for resources. Implementing this correctly is tricky. One of the problems we run into is that IsResource(ComponentId) cannot be directly copied over because ComponentIds are not consistent between worlds.

Solution

We change ComponentId(usize) into ComponentId(Entity) and use the EntityAllocator to create ComponentIds. Next, we store all resources on the ComponentId entity. This makes the ComponentId -> Entity lookup a no-op. And we can also use the MapEntities machinery to serialize and deserialize worlds.

Future Work

In the future, we can look at adding parts of ComponentInfo as a component to the component entities. That sounds confusing, because it is. This would improve the introspection ability of the ECS (being able to query for metadata about the components). This, however, requires quite a bit of weird bootstrapping, which I don't know how to do and is not necessary for this PR.

Testing

This is principally a performance PR, and while I will be doing some benchmarking myself, I don't have the hardware. So I'll be asking someone to give it a once-over when it's ready.

Change

The primary difference between this and #23988, is that this is not reliant on Entity Ranges (#24102). Because of this, there is a possibility for a performance regression with regards to Components.components going from a SparseArray to HashMap. There is an additional hash operation. Additionally, the fields on Access have changed from a FixedBitSet to a HashSet, so the set operations are likely slower.

…ents-as-entities-alt

Trashtalk217 · 2026-06-24T13:50:52Z

Performance Testing

I did some reasonably extensive performance testing. I ran both the entire ecs benchmark and several of our stress test examples. I've got the following data:

cargo bench -p benches --bench ecs -> benchmarks.txt

And the three examples I ran through were

cargo run --release --example bevymark -- --waves 60 --per-wave 500 --benchmark --mode mesh2d
cargo run --release --example many_components 100000 1000 1000
running bevy_city with mangohud.

name	frametime before (main)	frametime after (pr)
`bevymark`	37.5 ms	37.8 ms
`many_components`	6.6 ms	6.5 ms
`bevy_city`	90.5 ms	90.5 ms

Conclusion

From the measurements I took I've come to the conclusion that this PR mostly keeps performance the same. At worst it degrades slightly (mostly based on the microbenchmarks). The best solution to fix the resource performance issue is likely still going to be #24058 or something like it.

However!

I still think this PR is worth merging, because

It's a step to storing a meta-component on the component entity, allowing for more introspection in the ecs.
Users can tag component entities with their own data ComponentInfo extensions #24338.
It removes an indirection in the code via ResourceEntities and with it some unsafe code.
The (in my opinion minor) loss of performance can in the future be offset by introducing entity ranges (Entity ranges #24102) and hybrid datastructures. For more information checkout the entity ranges PR (or ask!).
It makes working with resources more consistent. Before, world.spawn((Res1, Res2)) would store Res2 on the resource entity of Res1, so Res2 would be stored on the wrong location. In this PR, this would throw a warning and remove both Res1 and Res2 because neither are on the appropriate entity.

Important Note

When review and discussing this PR, I prefer if you mostly kept it anchored to some line of code (even if only vaguely related). This makes it easier to follow particular threads of argument.

Victoronz

Looks good! I don't believe the #24102 is necessary for this, and can be left for later.

With this change, it becomes possible to express uniqueness regarding ComponentId collections/iterators as well. There are now likely several sections of code where it would make sense to convert the previous ComponentId collection/iterator types to their EntitySet version. That would make for a good follow-up PR!

One place for which this is especially relevant is DynamicComponentFetch, the current dynamic way to access the Components of an entity disjointly.
This functionality should fall under similar design considerations as #18234, though that PR has gotten stalled.

chescock

Looks good!

I'm fairly certain this is sufficiently¹ sound. The checks in Res ensure that IsResource is a required component, and the panic in IsResource::on_discard ensures it can never be removed, so Res can only access entities with IsResource, matching the access that it claims.

This is a bit of an abuse of both required components and hooks, of course :). In particular, the panic in on_discard can mean that other on_discard hooks ran, but then the discard didn't happen. But user hooks could already panic there, so that's not a new problem. And hopefully this can become more principled when we have proper archetype invariants.

Left a few minor style nits I noticed on another read. The apply_settings_to_world one might be a bug, but none of the others should be blocking.

I think there may be a soundness hole if you insert IsResource with the wrong ID so that the required component doesn't insert one with the right ID. But the bad IsResource will immediately be removed by a command from its on_insert hook, so you would need to do the insert in another on_insert hook that runs its commands first. And that hole goes away completely if we switch IsResource to a ZST, which we probably want to do anyway as a follow-up. ↩

chescock · 2026-07-01T15:04:27Z

        let d1 = query.get(&world, e1).unwrap();
        // NameOrEntity Display for entities without a Name should be {index}v{generation}
-        assert_eq!(d1.to_string(), "1v0");
+        assert_eq!(d1.to_string(), "9v0");


The 9 here seems brittle.

Suggested change

assert_eq!(d1.to_string(), "9v0");

assert_eq!(d1.to_string(), e1.to_string());

I actually really like this test as it is, because it's a great marker whenever the default number of entities increases. This is the one test I kind of like to be brittle.

chescock · 2026-07-01T15:43:58Z

    pub unsafe fn get_resource_by_id(self, component_id: ComponentId) -> Option<Ptr<'w>> {
-        // SAFETY: We have permission to access the resource of `component_id`.
-        let entity = unsafe { self.resource_entities() }.get(component_id)?;
+        let entity = component_id.entity();


My mistake @chescock, I didn't understand how this change could result in UB.

No worries! My fault for not explaining it well. Sometimes I'm way too verbose, so I try to avoid that but then wind up editing out the important parts :).

Also, if you can, mark any solved conversation as 'resolved' so I know your concerns have been addressed.

I think only you can do that? It always seems backwards to me, but I think that's how GitHub works. I can add thumbs-up reactions to your responses, though! And I can go approve the PR :).

EDIT: Ended up doing something slightly different, it should still work.

Ah, I see, you're checking for the presence of the required component. That's a clever approach! It only costs a hash lookup at startup per Res, and we're already paying one of those to map T to component_id, so I wouldn't expect it to be a significant perf cost.

do we rely on required components for soundness anywhere already? Under my impression (and this may very well be wrong, I don't have overview there), this infrastructure was in the space of "if something goes wrong, that is a logic error".

If so, we should be careful to make sure that the required component space aligns with being designed for soundness, otherwise we may run into other design complications over there.

No, this is definitely stretching what required components are intended for! Normally they can't be relied on for soundness because you can always remove them later. Which is why we need to prevent that by panicking in the on_discard hook. Which is also stretching what hooks are intended for :).

What we really want here is archetype invariants, so hopefully we can do something cleaner once we have those.

Co-authored-by: Chris Russell <8494645+chescock@users.noreply.github.com>

urben1680

I must say I am actually curious for ComponentInfo being a component on the respective ComponentId entity.

Generally, I am a bit unhappy how many places now need to do assertions on IsResource being a required component. I would have hoped this could be more centralized within the component registration.

This being a change request could be resolved by understanding things better from answers to my questions.

I want to note I know too little of assets to review the world_asset file btw.

Victoronz · 2026-07-06T00:10:04Z

Overall, I do like and want Components as Entities to go through, but I think we are being too lenient with the UB here.

The access problems we run into when moving ECS architecture into the ECS are not trivial and have been a long-standing friction point. I do not think they should be left for a follow-up, and instead be done with this PR, even if it then increases in size.

In reply to @chescock (I can't respond in-thread for some reason):

do we rely on required components for soundness anywhere already? Under my impression (and this may very well be wrong, I don't have overview there), this infrastructure was in the space of "if something goes wrong, that is a logic error".

If so, we should be careful to make sure that the required component space aligns with being designed for soundness, otherwise we may run into other design complications over there.

No, this is definitely stretching what required components are intended for! Normally they can't be relied on for soundness because you can always remove them later. Which is why we need to prevent that by panicking in the on_discard hook. Which is also stretching what hooks are intended for :).

What we really want here is archetype invariants, so hopefully we can do something cleaner once we have those.

I think we're hitting a pain point here:
Judging from what the maintainers/SMEs have stated before, we want to be careful of how we impact other work that is usually in separate areas, and this has a chance of introducing friction in such other areas, hooks and required components.

In my experience with Rust and Bevy, a solution that is unsound if it fails, and one where failure would mean a logic error diverge in some design aspects, and trying to combine the two will often result in friction.
Given that hooks and required components seem not designed for this, I think we need due diligence and/with maintainer/SME sign-off here, because we cannot easily undo dependencies used for soundness.

It seems to me that the underlying problem might need greater architectural changes to address properly. As of right now, the reliance on hooks and required components seems to me like it still circumvents the issue, as I hit on here.

I gather, @Trashtalk217, that you'd rather focus on the code, and less these overarching design interactions/questions. But I do think they need to come up and be discussed when they are as core as this; regardless which way is decided later. That is what I'd think most aligned with the maintainer/SME opinion process-wise.
Such discussion does not need to fully live on the PR! However, they should at least see proper mention, as these PRs are the history people look back on. This way, it'll be easier to handle fallout were anything to go wrong down the line — hopefully without blame falling on specific people!

More actionably, the questions I'd like to see maintainer/SME judgment on:
Can we rely on hooks and required components for soundness?
Does this solve the UB/these access issues in a manner we won't want to undo later? (Both for this PR and for X-As-Entities in general)
Process-wise, how do we want to do due diligence without holding up this specific work for too long?

Keep in mind that "We don't see the need to address/discuss this at this point" are valid opinions/judgments!

alice-i-cecile · 2026-07-06T02:28:57Z

I've taken a look at this and I agree with @Victoronz.

Can we rely on hooks and required components for soundness?

Hooks, if we have no other choice. Required components, in their current form, no. Without an airtight implementation of archetype invariants I am not comfortable relying on this sort of strategy to avoid UB, and "just panic" is the worst sort of UB prevention.

SkiFire13 · 2026-07-06T07:38:48Z

@@ -0,0 +1,36 @@
+---


From my unaddressed comment in the linked PR:

In order to get access to a resource entity, you usually need to go through two lookups: TypeId -> ComponentId -> Entity. The ComponentId -> Entity lookup can potentially be removed, speeding up resource lookup.

On the other hand note that you have introduced a HashMap lookup into every ComponentId -> ComponentInfo path! This happens for example when calling hooks, which is arguably pretty common too.

Sidenote: do we have a benchmark for hooks to measure this?

Currently, one big downside of resources-as-components is that any components on resource entities aren't serialized. This forms a barrier for implementing required components for resources. Implementing this correctly is tricky. One of the problems we run into is that IsResource(ComponentId) cannot be directly copied over because ComponentIds are not consistent between worlds.

I'm not sure how this PR solves the issue. You'll still have the issue that the EntityId in the new world needs to match the ComponentId of the resource.

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_serialization problem, this is where it gets clever. Mapping entities between worlds has already been solved through SceneEntityMapper. The idea is that we can use this just as well for ComponentIds when ComponentIds are just entities.

SkiFire13 · 2026-07-06T07:39:59Z

+pub type ComponentIdMap<V> = EntityEquivalentHashMap<ComponentId, V>;
+
+/// A set of [`ComponentId`]s.
+pub type ComponentIdSet = EntityEquivalentHashSet<ComponentId>;


Note that EntityEquivalentHashSet does not have a well defined order, it will be deterministic but unpredictable. You can see this e.g. in the access tests where you had to update some of them due to the order changing.

SkiFire13 · 2026-07-06T07:51:53Z

@@ -0,0 +1,36 @@
+---


cargo bench -p benches --bench ecs -> benchmarks.txt

I can see some rather big regressions here:

group after before ----- ----- ------ added_archetypes/archetype_count/10000 2.99 36.5±1.69ms ? ?/sec 1.00 12.2±0.16ms ? ?/sec all_added_detection/50000_entities_ecs::change_detection::Sparse 1.72 84.7±0.81µs ? ?/sec 1.00 49.4±2.98µs ? ?/sec all_added_detection/5000_entities_ecs::change_detection::Sparse 1.71 8.5±0.52µs ? ?/sec 1.00 4.9±0.44µs ? ?/sec despawn_world_recursive/10000_entities 1.12 1547.4±24.08µs ? ?/sec 1.00 1375.8±8.73µs ? ?/sec despawn_world_recursive/100_entities 1.14 16.4±1.42µs ? ?/sec 1.00 14.4±1.31µs ? ?/sec ecs::resources::get 1.30 8.1±0.45ns ? ?/sec 1.00 6.2±0.52ns ? ?/sec ecs::resources::get_mut 1.23 9.0±0.47ns ? ?/sec 1.00 7.4±0.60ns ? ?/sec ecs::world::world_get::world_query_get_components_mut/unchecked_5_components_50000_entities 2.02 1547.9±74.62µs ? ?/sec 1.00 766.5±38.31µs ? ?/sec empty_archetypes/for_each/1000 2.46 18.4±1.52µs ? ?/sec 1.00 7.5±1.00µs ? ?/sec empty_archetypes/for_each/10000 25.88 276.3±58.63µs ? ?/sec 1.00 10.7±0.97µs ? ?/sec empty_archetypes/iter/100 1.18 8.4±1.02µs ? ?/sec 1.00 7.1±0.51µs ? ?/sec empty_archetypes/iter/1000 2.58 19.1±2.33µs ? ?/sec 1.00 7.4±0.84µs ? ?/sec empty_archetypes/iter/10000 27.51 279.2±54.97µs ? ?/sec 1.00 10.1±2.66µs ? ?/sec empty_archetypes/par_for_each/10 1.15 10.1±1.13µs ? ?/sec 1.00 8.7±0.65µs ? ?/sec empty_archetypes/par_for_each/100 3.70 32.4±3.23µs ? ?/sec 1.00 8.8±1.06µs ? ?/sec empty_archetypes/par_for_each/1000 33.88 329.2±23.02µs ? ?/sec 1.00 9.7±0.85µs ? ?/sec empty_archetypes/par_for_each/10000 191.38 3.3±0.06ms ? ?/sec 1.00 17.3±2.24µs ? ?/sec empty_systems/0_systems 1.14 16.1±4.09ns ? ?/sec 1.00 14.2±1.49ns ? ?/sec events_iter/size_16_events_1000 1.20 776.3±115.84ns ? ?/sec 1.00 647.5±49.46ns ? ?/sec events_iter/size_16_events_10000 1.32 8.5±0.57µs ? ?/sec 1.00 6.4±0.53µs ? ?/sec events_iter/size_4_events_100 1.32 85.9±5.74ns ? ?/sec 1.00 64.9±5.00ns ? ?/sec events_iter/size_4_events_1000 1.27 826.7±94.24ns ? ?/sec 1.00 648.9±66.35ns ? ?/sec multiple_archetypes_none_changed_detection/100_archetypes_10000_entities_ecs::change_detection::Table 1.33 727.2±4.41µs ? ?/sec 1.00 546.0±5.28µs ? ?/sec multiple_archetypes_none_changed_detection/100_archetypes_1000_entities_ecs::change_detection::Sparse 2.76 215.7±5.87µs ? ?/sec 1.00 78.1±2.80µs ? ?/sec multiple_archetypemultiple_archetypes_none_changed_detection/5_archetypes_1000_entities_ecs::change_detection::Table 1.48 3.4±0.05µs ? ?/sec 1.00 2.3±0.25µs ? ?/sec s_none_changed_detection/100_archetypes_1000_entities_ecs::change_detection::Table 2.11 100.3±2.18µs ? ?/sec 1.00 47.5±0.95µs ? ?/sec multiple_archetypes_none_changed_detection/100_archetypes_100_entities_ecs::change_detection::Table 1.53 9.2±0.37µs ? ?/sec 1.00 6.0±0.24µs ? ?/sec multiple_archetypes_none_changed_detection/100_archetypes_10_entities_ecs::change_detection::Sparse 1.24 1420.8±139.83ns ? ?/sec 1.00 1147.1±161.44ns ? ?/sec multiple_archetypes_none_changed_detection/100_archetypes_10_entities_ecs::change_detection::Table 1.39 1212.4±121.47ns ? ?/sec 1.00 869.3±85.26ns ? ?/sec multiple_archetypes_none_changed_detection/20_archetypes_10000_entities_ecs::change_detection::Sparse 1.22 325.4±22.68µs ? ?/sec 1.00 266.6±11.61µs ? ?/sec multiple_archetypes_none_changed_detection/20_archetypes_10000_entities_ecs::change_detection::Table 1.49 140.3±3.66µs ? ?/sec 1.00 94.2±0.89µs ? ?/sec multiple_archetypes_none_changed_detection/20_archetypes_1000_entities_ecs::change_detection::Table 1.52 13.9±0.24µs ? ?/sec 1.00 9.1±0.17µs ? ?/sec multiple_archetypes_none_changed_detection/20_archetypes_100_entities_ecs::change_detection::Table 1.52 1526.8±146.79ns ? ?/sec 1.00 1007.4±15.22ns ? ?/sec

Some are pretty niche, but I find interesting that ecs::resources::get and ecs::resources::get_mut are there given that this PR claimed to speed up resource lookup.

Edit: or are after/before perhaps switched?

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.

It's also possible that my laptop (bless their soul) is not super reliable for benchmarks, but it tried its best.

SkiFire13 · 2026-07-06T07:59:49Z

-    pub(super) ids: &'w mut ComponentIds,
+    pub(super) allocator: &'w mut EntityAllocator,


Given that now ComponentIds use EntityIds, the highest ComponentId might become proportional to the number of entities rather than components, which might be higher than usual. Have you tried looking into how much this grows in practice? This might be important especially because Tables use SparseSets keyed by ComponentIds, so it's important that these don't grow too much.

Good catch! Sadly, there's not really any good EntityEquivalent data structure for ImmutableSparseSet and adding it, in my opinion, is out of scope for now. This is definitely good future work!

…ents-as-entities-alt

Trashtalk217 added 3 commits June 23, 2026 14:29

make ComponentId use Entity

22e24fb

removed ResourceEntities

96d54c9

fix world_serialization tests

45ff041

Trashtalk217 changed the title ~~Components as Entities (V2)~~ Components as Entities (v2) Jun 23, 2026

add PR number

5e9d8fa

github-project-automation Bot added this to ECS Jun 23, 2026

github-project-automation Bot moved this to Needs SME Triage in ECS Jun 23, 2026

Trashtalk217 added S-Needs-Benchmarking This set of changes needs performance benchmarking to double-check that they help S-Needs-Review Needs reviewer attention (from anyone!) to move forward labels Jun 23, 2026

Trashtalk217 changed the title ~~Components as Entities (v2)~~ Components as entities (V2) Jun 23, 2026

Trashtalk217 changed the title ~~Components as entities (V2)~~ Components as entities (v2) Jun 23, 2026

Trashtalk217 added 6 commits June 23, 2026 23:11

fix bevy_remote

16f2b9e

fix dynamic example

c6d1670

fix doc test

a7d5879

fix bevy_settings test

eed38d9

forgot to remove a println!

a6d7ea3

fix benchmark

9056e8a

Trashtalk217 requested a review from chescock June 23, 2026 23:44

Merge branch 'main' of https://github.com/bevyengine/bevy into compon…

8430a66

…ents-as-entities-alt

Trashtalk217 removed the S-Needs-Benchmarking This set of changes needs performance benchmarking to double-check that they help label Jun 24, 2026

Trashtalk217 requested review from Victoronz, alice-i-cecile and kfc35 June 24, 2026 13:55

Victoronz approved these changes Jun 24, 2026

View reviewed changes

Comment thread _release-content/migration-guides/components-as-entities.md Outdated

Comment thread crates/bevy_ecs/src/world/mod.rs Outdated

improved migration guide, added iter_registered_ids, addressed review

63cd089

Trashtalk217 added 3 commits June 30, 2026 02:46

I'm a big dumb idiot who should test their code

3f3d76a

clippy

de65238

migration guide

b02a412

chescock approved these changes Jul 1, 2026

View reviewed changes

Trashtalk217 and others added 3 commits July 2, 2026 01:32

Apply suggestions from code review

c2678eb

Co-authored-by: Chris Russell <8494645+chescock@users.noreply.github.com>

removed tests, changed bevy_settings

56009dc

format

2c764e6

urben1680 suggested changes Jul 4, 2026

View reviewed changes

changed migration guide

faf0adb

Trashtalk217 added S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it and removed S-Needs-Review Needs reviewer attention (from anyone!) to move forward labels Jul 5, 2026

markdown fix

0d4bcf7

SkiFire13 reviewed Jul 6, 2026

View reviewed changes

Trashtalk217 added 3 commits July 7, 2026 02:10

cleaned up Res/Mut and hooks

ff207f8

cleanup

38489bb

add documentation

9357ba2

urben1680 approved these changes Jul 7, 2026

View reviewed changes

Trashtalk217 added S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it and removed S-Waiting-on-Author The author needs to make changes or address concerns before this can be merged labels Jul 7, 2026

alice-i-cecile added S-Waiting-on-SME This is currently waiting for an SME to resolve something controversial and removed S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it labels Jul 8, 2026

Trashtalk217 added 2 commits July 12, 2026 14:58

Merge branch 'main' of https://github.com/bevyengine/bevy into compon…

c0597ca

…ents-as-entities-alt

fix bevy_dev_tools

a7a2972

Trashtalk217 force-pushed the components-as-entities-alt branch from 897d46e to a7a2972 Compare July 12, 2026 21:45

	assert_eq!(d1.to_string(), "9v0");
	assert_eq!(d1.to_string(), e1.to_string());

		pub(super) ids: &'w mut ComponentIds,
		pub(super) allocator: &'w mut EntityAllocator,

Uh oh!

Uh oh!

Conversation

Trashtalk217 commented Jun 23, 2026

Objective

Performance regression #23039

World Asset Serialization (previously in bevy_scene) #22968

Solution

Future Work

Testing

Change

Uh oh!

Trashtalk217 commented Jun 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Performance Testing

Conclusion

Important Note

Uh oh!

Victoronz left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

chescock left a comment

Choose a reason for hiding this comment

Footnotes

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

urben1680 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Victoronz commented Jul 6, 2026

Uh oh!

alice-i-cecile commented Jul 6, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SkiFire13 Jul 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Trashtalk217 Jul 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

World Asset Serialization (previously in `bevy_scene`) #22968

Trashtalk217 commented Jun 24, 2026 •

edited

Loading

Victoronz left a comment •

edited

Loading

urben1680 left a comment •

edited

Loading

SkiFire13 Jul 6, 2026 •

edited

Loading

Trashtalk217 Jul 7, 2026 •

edited

Loading