You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A redesign of the asset types has made the process of accessing loaded level data more clear and correct, for both internal-levels and external-levels projects. Since LdtkProject stores a mapping of level iids to level handles/their indices in the project (along with other metadata), accessing levels by iid is a constant-time operation. Providing similar indexing of entity iids/layer iids would provide many benefits for us and for users. Some of these benefits include..
easier and quicker access to EntityInstance/LayerInstance/Level data in normal bevy systems (this defeats one of the biggest cons of using the "blueprint pattern" for LDtk entity processing) without any clones
redundancy of the LayerMetadata component, which could be completely removed in favor of quickly grabbing the same data directly from the asset
no more performance reason for processing levels via triple-layer iteration over the asset data, so we could redesign internal systems and schedules to be more modular
However, unlike mapping level iids to levels, we cannot provide a mapping of entities to layers or layers to levels inside the asset types. This is because, in the external levels case, this data is not available to the LdtkProject. We would need create these indexes in a normal bevy system and store it in an actual bevy resource, and probably provide a SystemParam API for end-users. The index could look something like this:
Then a system param that grabs this resource and Assets<LdtkProject> and #[cfg(feature = "external_levels")] Assets<LdtkExternalLevel> could provide methods like..
No cloning (apart from the strings used in the iids), and constant-time operations all the way through the tree. It might be worth putting some of this behind feature flags due to the memory and compilation costs that some users may want to opt out of. However, some of the benefits this could provide to internal systems makes me hesitant to put all of it behind a feature flag.
This should come after #250 and #249. It is also worth noting that this is based off work and discussion done in #195 that could not be completed due to the asset type design at the time. Thanks @adtennant
The text was updated successfully, but these errors were encountered:
A redesign of the asset types has made the process of accessing loaded level data more clear and correct, for both internal-levels and external-levels projects. Since
LdtkProject
stores a mapping of level iids to level handles/their indices in the project (along with other metadata), accessing levels by iid is a constant-time operation. Providing similar indexing of entity iids/layer iids would provide many benefits for us and for users. Some of these benefits include..EntityInstance
/LayerInstance
/Level
data in normal bevy systems (this defeats one of the biggest cons of using the "blueprint pattern" for LDtk entity processing) without any clonesLayerMetadata
component, which could be completely removed in favor of quickly grabbing the same data directly from the assetHowever, unlike mapping level iids to levels, we cannot provide a mapping of entities to layers or layers to levels inside the asset types. This is because, in the external levels case, this data is not available to the
LdtkProject
. We would need create these indexes in a normal bevy system and store it in an actual bevy resource, and probably provide aSystemParam
API for end-users. The index could look something like this:Then a system param that grabs this resource and
Assets<LdtkProject>
and#[cfg(feature = "external_levels")] Assets<LdtkExternalLevel>
could provide methods like..fn get_level(_: &LevelIid) -> Option<LoadedLevel>
fn get_level_for_layer(_: &LayerIid) -> Option<LoadedLevel>
fn get_layer(_: &LayerIid) -> Option<&LayerInstance>
fn get_level_for_entity(_: &EntityIid) -> Option<LoadedLevel>
fn get_layer_for_entity(_: &EntityIid) -> Option<&LayerInstance>
fn get_entity(_: &EntityIid) -> Option<&EntityInstance>
No cloning (apart from the strings used in the iids), and constant-time operations all the way through the tree. It might be worth putting some of this behind feature flags due to the memory and compilation costs that some users may want to opt out of. However, some of the benefits this could provide to internal systems makes me hesitant to put all of it behind a feature flag.
This should come after #250 and #249. It is also worth noting that this is based off work and discussion done in #195 that could not be completed due to the asset type design at the time. Thanks @adtennant
The text was updated successfully, but these errors were encountered: