OGRE-Next: Ogre::SkeletonAnimManager Struct Reference

| OGRE-Next 3.0.0 Object-Oriented Graphics Rendering Engine

Loading...
Searching...
No Matches
Ogre::SkeletonAnimManager Struct Reference
Core » Animation

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
SkeletonInstance * | createSkeletonInstance (const SkeletonDef *skeletonDef, size_t numWorkerThreads)
| Creates an instance of a skeleton based on the given definition.
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

typedef list<BySkeletonDef>::type Ogre::SkeletonAnimManager::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:

- OgreSkeletonAnimManager.h