-
-
Notifications
You must be signed in to change notification settings - Fork 4.5k
A query filter for Asset updates #5069
Copy link
Copy link
Closed
Labels
A-AssetsLoad files from disk to use for things like images, models, and soundsLoad files from disk to use for things like images, models, and soundsC-FeatureA new feature, making something new possibleA new feature, making something new possibleD-ModestA "normal" level of difficulty; suitable for simple features or challenging fixesA "normal" level of difficulty; suitable for simple features or challenging fixesS-Adopt-MeThe original PR author has no intent to complete this work. Pick me up!The original PR author has no intent to complete this work. Pick me up!
Metadata
Metadata
Assignees
Labels
A-AssetsLoad files from disk to use for things like images, models, and soundsLoad files from disk to use for things like images, models, and soundsC-FeatureA new feature, making something new possibleA new feature, making something new possibleD-ModestA "normal" level of difficulty; suitable for simple features or challenging fixesA "normal" level of difficulty; suitable for simple features or challenging fixesS-Adopt-MeThe original PR author has no intent to complete this work. Pick me up!The original PR author has no intent to complete this work. Pick me up!
What problem does this solve or what need does it fill?
A major pain point of using
Handle<Asset>as components in the ECS currently is that the assets pointed-to by the handle can change, and there is no simple way of reacting to changes to the asset in the context of the ECS.For example: AABB calculation. We have a
Handle<Mesh>andAabbcomponent in the ECS. We want to updateAabbwhenever theMeshfor theHandleis updated. TheHandleis updated in two circumstances:Handlethe entity has by replacing it in a system with aQuery<&mut Handle<Mesh>>parameterMeshin theAssets<Mesh>in a system with aResMut<Assets<Mesh>>parameterTo react to (1), it's trivial: just add a
Changed<Handle<Mesh>>to the system that updates theAabb.To react to (2), it becomes harder. The only way to react to asset changes is to use the
AssetEvent::Modified { handle: Handle<Mesh> }event. This event only holds aHandle<Mesh>, so you either need to iterate over ALL entities with aHandle<Mesh>and updates the ones that are equal to theModifiedfield, or keep aHashMapmapping handles to entities, and other gory details required to maintain thisHashMapproperly.Most of asset changes are done through (2), which makes it very difficult to react to asset changes in the general case.
This was observed in #4944 and also in personal project related to scene hot-reloading.
What solution would you like?
Introducing a
AssetChanged<A>query filter that istruefor entities with aHandle<A>for which the underlying asset got modified since the last time the system ran.What alternative(s) have you considered?
In the case of
Mesh, it seems that moving Aabb calculation to the generation of the Mesh and keeping it as an optionalMeshfield is a correct solution. This would fall into the category of "asset pre-processing" which is both possible today (through a constructor) and subject to future possible improvements.But this is only a specific solution to a specific problem. In general, it seems reasonable to be able to bridge the gap between assets and ECS with such a query filter.
Additional context
See discussions: