Change Detection as Components / Opt-in or opt-out of Change Detection

[james7132]

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

Currently change detection is hard-coded from userspace all the way to ECS storage. This adds quite a bit of extra effort to maintain it at every level in bevy_ecs. Logically speaking, the change ticks included are always kept parallel to the base storage, and can be seen as a companion component that is always present with every component in the World. If this is the case, it may make sense to actually make the change detection ticks their own component.

This can allow for disabling change detection entirely for types which can remove the memory and CPU overhead for small component types that don't really need it (i.e. usize newtypes or ZSTs).

This would also remove all storage-level special casing required for change detection. For example, moving entities from table to table doesn't require knowledge of the change ticks. It's copied from column to column like any other component.

What solution would you like?

• Remove all special casing for ComponentTicks in storage and add ChangeTicks<T: Component> as an engine provided component.
• Add Component hooks that automatically add or remove the ticks if the component is added/removed. This can be done via hooks or be the only hard-coded part of this.
• Update Mut to fetch both &mut T and &mut ChangeTicks<T>.
• Add an associated type to Component that changes WriteFetch to retrieve &mut T when change detection is disabled, and Mut<T> when it isn't. Update the derive macro to enable/disable this behavior.
• Update change detection fetches/filters to rely on Component<Write=Mut<Self>>

What alternative(s) have you considered?

1. Leave change detection as it is.
2. Alter storage to use Option<Vec<UnsafeCell<ComponentTicks>>> instead.

[alice-i-cecile]

My initial instinct is that the component-based design is going to be the most maintainable form of this.

As for default behavior, ideally I'd like opt-out for most things, but opt-in for ZSTs.

[bjorn3]

Isn't a component based approach less efficient for sparse storage?

[james7132]

Arguably. We're still randomly accessing the change ticks now. Though this does add one additional SparseArray lookup in that path.

[james7132]

As for default behavior, ideally I'd like opt-out for most things, but opt-in for ZSTs.

I would actually argue for opt-in by default, but have it explicitly enabled on all user-facing first-party bevy components (i.e. Transform). In a lot of my own game code, I rarely use the change detection filters and checks in the default case.

[bjorn3]

Wouldn't the futurw bevy editor need change detection to ensure that what is shown in the editor is in sync with the game state. Or at least if we will use a retained mode ui, which I believe is the plan. Having change detection opt in would be pretty bad for that I think. Also I believe when introducing the current change detection scheme I believe one of the reasons that this specific scheme was chosen was because it should be cheap enough to be fine to have unconditionally. Making change detection opt-in will reduce the pressure to keep change detection as fast as possible. And finally what would you do if you need change detection for a component defined by a plugin that doesn't opt in to change detection?

[alice-i-cecile]

FYI: based on discussions in ecs-dev, there seems to be consensus that this must be runtime configurable. Different consumers of libraries will have different needs, and there won't be a single solution that works for all of them.

[cBournhonesque]

• How would archetype changes work?
  a) Would the Bundle::component_ids() function on a component run on both the Component itself and ChangeTicks ?
  b) Would we have custom logic in the add_bundle/remove_bundle code?
  c) do we have associated types like T::ChangeTickComponent that give us the paired component?

• For sparse set components, that means we might be able to store the ChangeTicks in dense storage instead of sparse storage (even though the component data itself is in a SparseSet). This means that the Changed/Added filters might iterate faster