Background
To maintain a level of realism in animation, it is necessary to blend in and out of animations, possibly while still animating. This is necessary to avoid animation "popping", but the details of such an implementation are not generally of interest to a developer, and if they are, classes may be overridden to accommodate extensions to the system. Such a system does, however, need to be capable of handling a variety of circumstances, including the case of multiple active animations, for example, swinging a sword while running. It should also be easy for a developer to queue up animations without handling the timing explicitly. If a character has a landing animation after a large fall, but the player begins running immediately after the fall, the landing animation should not be skipped. Still, it is also often necessary to interrupt the queue. If the player hits the ground while multiple animations are queued up, the landing animation should nevertheless begin blending in.
Proposal
I propose to solve these issues with a high-level, extensible animation system built on top of the existing, lower-level OGRE animation system. No modification should be necessary to the current, relatively low-level animation system (AnimationState, Skeleton, etc..) for these features. Instead, additional classes relating to the high-level system will be added. The proposed system will also simplify the process of utilizing the animation blend masks exposed by the lower-level system.
Additionally, the integration of an animation listener interface similar to listeners available in other parts of the engine would allow for synchronization with and control over the animations as they are run.
Project Components
- AnimationTransition: This class controls the animation transition in and out of an AnimationState. Optionally, it may include an AnimationChannel name (see AnimationChannel) and interrupt flag. The default implementation will include a transition duration and flags to control animation while blending in and out, but other methods may be implemented. As part of the project, I would like to implement some of the more common transitions, hopefully at community request.
- AnimationBlender: This class should be created for each entity requiring high-level animation. It will contain a collection of named animation channels. Transitions to animations will be achieved by calling a method (possibly named "transition") accepting an AnimationTransition and an optional interrupt flag. Upon receiving a transition request, it will be forwarded to an appropriate AnimationChannel, or a new channel may be created to accommodate it. This class will also include an "addTime" or similar method to control animation.
- AnimationChannel: This class stores and manages a queue of AnimationTransitions. It will notify each transition when it is blending in, when it is waiting for the next animation, and when it is blending out. Optionally, a blend mask may be specified for each channel. It will also be possible to determine if the animation queue is empty to accommodate "idle" animations"
- AnimationListener: This class would allow for "listening" to changes within an individual animation, including advancing key frames. This would allow synchronization and possibly control over an animation as it is run.
Implementation of listed components in C++ and following OGRE coding guidelines
Implementation of multiple animation transitions including those requested by the community
Doxygen code documentation
Schedule
4/20-5/23: Get to know my mentor and the internal workings of the animation system. Discuss with community what types of transitions would be most beneficial, although this process should continue as the system becomes further defined.
5/23-6/6: Integrate AnimationListener functionality.
6/6-6/22: Create AnimationBlender, AnimationChannel, and AnimationTransition classes.
6/22-6/29: Complete default animation transition and test system up to this point.
6/29-7/6: Communicate changes to OGRE community and request input.
6/6-6/13: Complete animation transition with support for blend masks to simplify this functionality.
6/13-6/24: Implement alternative animation transitions including those requested by the community.
7/24-7/31: Complete example of using the system, including the use of multiple animation transition implementations.
7/31-8/7: Implement additional alternative animation transitions including those requested by the community and final refinement of interface.
8/7-8/17: Develop and implement final testing and make corrections for any identified problems. Communicate changes to OGRE community and request input. Clean up code and finalize documentation.
Schedule Note: Although time was explicitly allocated for additional animation transitions, these may also be implemented sooner in order to help finalize the interface early in the process. If the task of creating new transitions is completed earlier than expected, additional work on the animation system may be completed.
Anticipated Issues
Handling blend masks for per-bone weights.
Making the AnimationTransition interface generic enough to accommodate a wide range of usage scenarios.
Future Extensions
More animation transitions can easily be added as the need for them becomes apparent. Additionally, if the interface is generic enough, animation transitions for other animations methods, like IK, might be possible.
Edited April 1st to reflect proposal changes.
Edited April 9th to provide more detail regarding blend mask support.
