Alternatives for Component/Res with lifetime requirements for an AssetLoader

[gak]

I'm working on an animation library and I'm a bit stumped with options. I've separated the library into its own crate so it can be used for other engines. My issue is the library needs a lifetime for the "state" of the animation (e.g. per entity). The skeleton is a bunch of bone structures and texture positioning, etc. This can be reused by multiple states/entities. The state is (will be) a cached view of the animation, manual bone positions, etc.

pub struct SkeletonState<'a> {
    skeleton: &'a Skeleton,
    
    // etc
}

I have an AssetLoader loading the Skeleton, and my aim was to have the SkeletonState in a Component.

Having the state in a Component is not possible because of the 'static requirement as far as I understand, so I'm a bit stuck on how to proceed. I have a few ideas but they're not ideal:

1. Change the library so it doesn't need a reference to the Skeleton. This would need each method to pass in a reference to Skeleton, e.g. state.set_bone(&skeleton). This is not so bad, except for the problem that a user could accidentally pass in the wrong skeleton.

2. Put the whole animation in the state. This is bad for memory and performance when creating many new states.

3. Somehow keep the Skeleton and State outside the asset system and maybe keep it in an Arc<HashMap<Id, SkeletonAndStates>>? This means I'd have to create a component that references the map. The user will need to get access to the state directly so it's seems bit ugly.

Any ideas for a nice way to implement this?

---

I have the sources up but it's a big mess because I'm in the middle of hacking things to work first:
https://github.com/gak/spinal/tree/main/bevy_spinal/src <-- Bevy plugin
https://github.com/gak/spinal/blob/main/spinal/src/state.rs <-- State
https://github.com/gak/spinal/blob/main/spinal/src/skeleton.rs <-- Skeleton

[HackerFoo]

Can your Skeleton references be handles instead?

I had a similar problem in Noumenal storing and caching shape data, which can be large and expensive to compute. I chose something like the first option, using type tagged integer handles (enum variants containing a usize) passed to a central data structure (defined in a crate entirely independent from Bevy) that can act on expressions containing those handles, and the results are cached in components. It has worked out pretty well.

You could use an Arc<()> or something else for memory management.

[gak]

Can your Skeleton references be handles instead?

That SkeletonState struct is outside the Bevy world so it can't really be a handle.

In the bevy crate they are handles at the moment. e.g.:

commands.spawn_bundle(SpinalBundle {
    skeleton: asset_server.load("spineboy-ess-4.1/spineboy-ess.skel"),
    ..Default::default()
});

#[derive(Debug, Default, Bundle)]
pub struct SpinalBundle {
    pub skeleton: Handle<SpinalSkeleton>,
    // etc..
}

Thanks for the response. I will try something similar to what you've done in Noumenal. Otherwise I'll try 3 with an Arc for now until I can get a really nice solution.

Noumenal looks really cool BTW!

[HackerFoo]

I mean handles in the general sense, which are indices into some other data structure, not Bevy's Handle.

Noumenal looks really cool BTW!

Thanks!

[gak]

I went for option 1 and made a reasonable solution IMO. It's straightforward but thought I'd post it here for anyone that might need it.

Separated SkeletonState into two structs, one that internally tracks the Skeleton with the lifetime (SkeletonState), and another that needs a Skeleton reference (DetachedSkeletonState).

Now it looks like this:

pub struct SkeletonState<'a> {
    skeleton: &'a Skeleton,
    internal: DetachedSkeletonState,
}

DetachedSkeletonState is the second "internal" struct that needs Skeleton as a reference for its methods. SkeletonState is kind of like a proxy into DetachedSkeletonState

pub fn pose(&mut self) {
    self.internal.pose(self.skeleton)
}

A library could happily use SkeletonState as long as they can match the Skeleton lifetime, otherwise use InternalSkeletonState for engines like bevy.