This is how the Skeleton system works in 2.0: There is one BoneMemoryManager per skeleton.
That means the same BoneMemoryManager manages the allocation of Bone data of all instances based on the same Skeleton definition. In other words, the skeletal animation system has been greatly optimized for the case where there are many instances sharing the same skeleton (regardless of how many animations are in use or if some instances use many more animations at the same time than others).
- At the same time, for multithreading purposes we keep track of all pointers we create and the variable "threadStarts" records where each thread should begin processing. Unlike nodes, we cannot just iterate through empty memory because each skeleton instance is too complex and somewhat heterogeneous. We also have to ensure that (e.g.) if skeletons[0] and skeletons[1] share the same memory block (which is granted by the BoneMemoryManager), they get updated in the same thread. Otherwise race conditions will ensue, due to SIMD branchless selections inside @SkeletonInstance::update.
- Just like other managers (
- See also
- mNodeMemoryManager), SceneManager implementations may want to provide more than one SkeletonAnimManager (i.e. one per octant)