Stack of ogre skeletal animation (animation queue)

Hi All !

Is it planned to write some kind of an animation stack for OgreXML skeletal animation? Or maybe some one already wrote a solution?

Now I have a problem that I need to play idle model animation all the time and occasionally play one time  fire animation or being hit animation and after this animation ends I need to continue to play idle animation. I looked thought the latest JME 2 code and haven't found this kind of mechanism... But it is really useful.

It's not a problem for me to write it but I will modify my JME library code that I really don't want to do )) 

And maybe someone can point me some open source projects where this mechanism is already implemented?

I'm interrested too…


anybody done something in this direction? cause otherwise I’ll have to dig on this…

You can use the AnimEventListener to determine when an animation has finished playing, when that happens, simply play the next animation in the stack.

Momoko as i know it’s only available in jME3… Will any efforts be mede to port it in jME2?

I started work on an animation system based on AI game Programming Wisdom 2: Simplified Animation Selection by Chris Hargrove.

Currently the system works as described in the book, besides transitions (which I am working on right now), and scripting. The whole part is currently coded where the book describes a scripting language, but a xText solution could implemented to leverage the learning curve for animators.

As soon as I have transitions finished I’ll post the code.

ghoust said:
I started work on an animation system based on AI game Programming Wisdom 2: Simplified Animation Selection by Chris Hargrove.
Currently the system works as described in the book, besides transitions (which I am working on right now), and scripting. The whole part is currently coded where the book describes a scripting language,, but a xText solution could implemented to leverage the learning curve for animators.
As soon as I have transitions finished I'll post the code.
That sounds great! Will it be specific to either jME2 or jME3?

It’s not specific to jme, could be used with any engine I guess. The system provides interfaces to be called for specific tasks. My current implementation uses an extended controller to bridge between jme and the animation system.

Sort of like this?,1503.0.html

Don’t know why this post got somewhere else,…


aeh doesnt seem to go in the same direction. the animation system is not trying to be a library to DO the animation but a system do decide WHEN to do WHICH animation.

basically it is an animation decision system. you still need a system to execute the animation of a model.

the topmost article (Simplified Animation Selection) describes the concept: - Game Articles & Research



The system is finished, and a simple example based on the jme ninja is written!

A screenshot, source and a video can be downloaded here Have fun, it is for free

Here’s the part from the readme:



based on Game AI Wisdom 2 Animation Selection by Chris Heckers

Provided here is an animation system which allows control of multi channel animations by means of simple actions and input values. Transitions between animations are also supported.

It is not an animation library. The animation system sits on top af any lower level implementation and directing the execution of such a low level system. Currently a JMonkeyengine 2 implementation is provided as an example.

The system comprises of different components working together to achieve the desired animation selection.


The animation system was designed for multi channel animations. For example you could differentiate between upper body, lower body, left arm, right arm, etc. If you would need different channels tha the ones provided, the change A Channel holds a lock for a level for a set time where no other animation of the same level can overide the lock easily.


The whole system is driven by read Input variables. is a storage component to be used between an application and the animation system to exchange input values for an entity. The input Values you need would be implmented by creating your enums for input constants and adding feeding them to the animation system. The first value of the enum should be the initial/default value.


Actions are thplace where the whole selection takes place. An actions tries to get a lock on a channel and if gained is allowed to fill an animation system owned animation descriptor. Normally a default action is used and several other animation actions are provided for more important animations or completely different selection algorithms. New Actions should be based on and only override the evaluate(…) method.


The concept describes transitions to be based on input value changes by actions. My implementation uses plain animations, so if you would be in need of a more sophisticated transition selection system you should change the implementation, or overide it.

IAnimationProvider, Mediator is used to bridge the low level implementation with the animation system. It is here where the low level animation should be set, where low level internal animations are created/looked up/loaded on demand/fetched and provide information like the animation length. The Mediator is used to glue the different animation system parts together. At startup it is fed with a subset of actions and transitions to be used by that entity (several could have the same configuration, some could be different). The external system should use some methods to provide data for animation system updates.

The methods setAnimationProvider(…), update(…), setInput(…), callAction(…) and the constructor should be used by a calling system.

Building your own animation system configuration.

-Decide which channels you need, if you need more than are provided in, then change that class (normally should contain just any channels you would need). Perhaps you need a more sophisticated channel configuration, if not, leave it in place.

-Decide on the input values which should be driving your actions. For each input type create an enum so it can be used in your engine code to fill an InputProvider and used by the actions to look at the current inpt state.

-Decide on the actions you need. Normally you have some idle animation. This one would be the default action used on each frame (functioning like a fallback) other actions you need would be priorized by selecting a certian lock level. An idle normally is the lowest priority, so we give it a lock level of 0,

a taunt, or walk could be 1, an attack could try to lock on even higher, a hurt action would be even higher (no matter what we normally act very fast to being hurt…). Implement your actions by overridng The actions do mostly the same, try to get a lock, decide on which animation name to choose and which parameters to be passed on to the low level system (looping, playbackrate, etc.)

-Decide on the transitions you would need for your system. Give it a try by specifying them by using current animation name, final animation name, transition animation. Should be sufficient for most configurations.

-Implement a position in your engine where update calls can be received on each frame, the input hooks are routed to the mediator and the animationprovider information is filled out. Have a look at the JMEAnimationController for inspiration.

Building an animation system for JMonkeyengine 2

To give you some hints on how to integrate the animation system into your engine an example is provided based on the JMonkeyengine 2, the code can be found in the library folder src/…/animsystem/example/.

As a starting point we will look at the ninja ogre model comming with jmonkey. The model comes with the following animations:

Attack1, Attack2, Attack3, Backflip, Block, Climb, Crouch, Death1, Death2, HighJump, Idle1, Idle2, Idle3, Jump, JumpNoHeight, Kick, SideKick, Spin, Stealth, Walk.

All animations are full body animations, as they provide values for all joints. But it could be also the case that attacks and idle affect the uper body only and the walk the lower body. We will create such a system just to show you how to set it up, although the model is not ready to be using the different channels. So we will have three channels, AllChannels, Upper and Lowerbody. Well better not, you can test this by changing the channels in some actions, but you will notice that the Ninja animations will look jerkey as they might get replaced by default animations at any time inbetween. So I left it out.

The system will be based on the following input values which will be created as enums: Movement=None,Walking; AttackType=None,Weapon; Acting=Open,Hidden; Target=None,Mid,High,Back.

The available actions should be default, attack, defend, climb, jump, die. Default will somehow result in Idle1-3, Stealth, Walk, Crouch animations. Attack will deliver the Attack1-3, Kicks and Spin animations. Defend logically only a Block, Climb a climb animation. The jump action will result in any jump related animations. Having decided what actions there should be it is now the time to think about the locklevels/priorities of the animations. Basically the idle stuff comes at the lowest level so we give it a zero (0). An attack should be higher, but how much? Should it be possible to attack while in a jump? If so it should be higher, than a jump. So we give jump a one (1) and attack a two (2). Defend is the same as an attack but the revers, so we give it also a two(2). A jump is similar to a climb, in my system I would like to be able to interrup any climb by an atack or defend, so I give the climb also a locklevel of one (1). Death of course is one of the top priorities, if you are dead it should be instant, right? So we give it the highest priority, three (3) as it should be possible to drop an attack animation or whatever and start to play the death animation. Remember this was just my interpretation of what should be able to cancel what out. The choice could be completely different in your situation. Finally the actions are implemented, requesting a lock, filling out an animation bean with information.

In the current scenario there are no transitions. That’s ok too. Or you could create animations which perhaps speed up from an idle before starting to full run.

To implement the location in the engine we would extend the Ogre MeshAnimationController with the needed methods and interfaces. In addition the entity class will be extended with a possibility to collect input values and pass them on to the controller. Direct actions calls should also be implemented, which is a different building block (on a playable character this would go into input wireing, on an entity into its entity AI code). In the demonstration the input passing is simulated by a gui interface.

Why do the animations sometimes look jerkey?

From what I can guess the example jme ninja animations are not animated well, the walk cycle for example look smooth, the hidden_idel not. So I guess it’s just the quality of animations that counts.