OGRE-Next  4.0.0unstable
Object-Oriented Graphics Rendering Engine
Ogre::SkeletonAnimManager Struct Reference

This is how the Skeleton system works in 2.0: There is one BoneMemoryManager per skeleton. More...

#include <OgreSkeletonAnimManager.h>

Public Types

typedef list< BySkeletonDef >::type BySkeletonDefList
 

Public Member Functions

SkeletonInstancecreateSkeletonInstance (const SkeletonDef *skeletonDef, size_t numWorkerThreads)
 Creates an instance of a skeleton based on the given definition. More...
 
void destroySkeletonInstance (SkeletonInstance *skeletonInstance)
 
void removeSkeletonDef (const SkeletonDef *skeletonDef)
 

Public Attributes

BySkeletonDefList bySkeletonDefs
 

Detailed Description

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)
Remarks
The same BoneMemoryManager can't be used for multiple definitions because otherwise many SIMD opportunities are lost due to the heterogeneity of the data (a Skeleton may have 3 bones, 10 animations, another may have 6 bones, 2 animations, etc) unless we wasted a lot of RAM or perform a lot of book-keeping.

Member Typedef Documentation

◆ BySkeletonDefList

Member Function Documentation

◆ createSkeletonInstance()

SkeletonInstance* Ogre::SkeletonAnimManager::createSkeletonInstance ( const SkeletonDef skeletonDef,
size_t  numWorkerThreads 
)

Creates an instance of a skeleton based on the given definition.

◆ destroySkeletonInstance()

void Ogre::SkeletonAnimManager::destroySkeletonInstance ( SkeletonInstance skeletonInstance)

◆ removeSkeletonDef()

void Ogre::SkeletonAnimManager::removeSkeletonDef ( const SkeletonDef skeletonDef)

Member Data Documentation

◆ bySkeletonDefs

BySkeletonDefList Ogre::SkeletonAnimManager::bySkeletonDefs

The documentation for this struct was generated from the following file: