XML Data Templates
Whilst working with the animation pipeline at a mobile games company, I started working with an artist that had created a sprite animation at the wrong scale and orientation. I began coding a set of scripts that would allow artists to transform animation keyframes to get around problems like this. Looking further into our animation pipeline, I started to realise that there were limitations to the template that the company was using for animation export, which meant that the subtle nuances of an animation dictated by the keyframe tangents were getting discarded in favour of a simplification of the data. For each animation channel, Maya provides an animation curve which is essentially a uniquely named node. Each curve features a respective time, value, and strings to represent the ease-in and ease-out modes being used on a keyframe. However, the system in place lumped the three animation curves together representing each of the axes into a single compound representation of the curves and didn’t take into account the fact that ease in and ease out values at the keyframe position can be different.
<animation name="jump" speed="1.0"> <translate time="1.0" x="0.0" y="0.0" z="0.0" ease="linear"/> <translate time="5.0" x="0.0" y="4.0" z="0.0" ease="auto"/> <translate time="10.0" x="0.0" y="0.0" z="0.0" ease="linear"/> </animation>
While the simplification makes for ease of reading, it also means that we are losing the ability to be able to apply independent keyframe tangents to each of the axes. A system was in place whereby the exporter spat out text files containing the animation data, and the artists would then copy and paste these into a master animation file.
After my time at the company, I decided to create a completely new export template and a data structure for animation with the following aims:
- Take account of the independence of animation curves.
- Provide a UI so that artists would not have to hand-edit delicate xml files.
- Form the foundation of an animation framework that could be expanded.
I designed the new xml template with these ideas in mind.
<animations> <animation name="bounce" notes=""> <translateY> <key in="auto" out="auto" time="1.0" value="0.0"/> <key in="linear" out="linear" time="3.0" value="0.0"/> <key in="auto" out="auto" time="8.996" value="45.72"/> <key in="linear" out="step" time="14.992" value="0.0"/> <key in="auto" out="step" time="18.0" value="20.0"/> <key in="auto" out="auto" time="22.0" value="0.0"/> </translateY> </animation> </animations>
Animation Export Development Workflow
After several iterations of creating the export pipeline, I found that there was a logical way to develop the pipeline during coding:
- Create the xml template by hand.
- Read the data from the xml file to the animation data format.
- Read the data from a scene node to the animation data format.
- Write from the animation data format to the xml data file.
- Apply the animation data to a scene node.
When all these steps are complete, the export pipeline is up and running.
Animation Data Structure
The animation data structure was built using classes representing keyframes and animation channels.
The AnimationData class can be collected in groups of animations which can be used to represent simple generic animations, or could be used to represent complex animations, such as each of the articulations in an animated character. And with the export pipeline, we also have a means of storing animations externally which can be sent to an external engine.