Rainer a écrit
I wanted to avoid object pooling in this case because pooling all those objects will use up a lot of memory.
Depending on your situation it should not use up substantially more memory, given that you load the same skeleton sooner or later. You will not save the SkeletonData part of memory (including Textures, all animation timelines, etc), you only delay it until later. What you will save is the instance data, so the current status of the Bones, Slots, AnimationState, etc.
On-demand lazy loading would make sense if you have no idea in advance what skeletons need to be loaded (e.g. you have a selection of 10 skeletons and one will be chosen by the player).
Rainer a écritAnd instantiation of objects is only called once every 30secons or so in our case.
The first instance of one skeleton type the will be more costly, as SkeletonData needs to be loaded. If the loading overhead in this frame is ok for you, then you might be ok with on-demand lazy loading.
Rainer a écritMy only option to avoid this is object Pooling or would there by anything else i could try?
If you want to instantiate a skeleton, you won't get around an instancing cost, be it loading time or memory consumption. You can lower this cost by optimizing (simplifying) your skeleton, i.e. removing unnecessary keys from timelines, simplifying curves, avoiding mesh deform keys, and the like.
See this forum thread here on reducing memory consumption of a skeleton:
Reducing Spine Memory Usage
The metrics view can also be very helpful in this regard, the documentation page also lists many relevant items:
Metrics view - Spine User Guide: Metrics view
