| nWave Digital | Project Offset, Intel | Orange Labs |
I worked for Project Offset (Intel) in California for one year. Among my differents tasks, I had to simplify and improve their animation graph. I also developed a 3D UI system but sorry I have no material to show you. So this page only concerns animation graph and I try to explain to you what is, thanks to words but also thanks to pictures and videos that are always easier to understand ;). I don't go really deep into explanations since an animation graph is something that can become really complex.
The best thing I found to define this new version of animation graph was to write a XSD schema which would record all the rules of an animation graph. In fact, no one at Project Offset could remember what the rules of the first version were and so there were a lot of errors while processing the animation graphes which were wrong. I started by reading the code for animation graph processing and then I wrote/modified the corresponding rules and recorded them in the XSD schema.
As you can understand, I'm not allowed to provide you with the whole schema so I only show you a video of a graphical representation of it. All along this page, I use the same basic animation graph example to explain to you what an animation graph is and at last, thanks to a video, you'll see how it works to edit it in Visual Studio and test it in Project Offset Editor.
- An animation graph is a succession of states and transitions. You can see a state as a simple animation for now. A transition defines how we leave a state to go to another one. For example, the player was doing nothing and now he runs forward because you moved the joystick. The action "joystick forward" triggers the transition from the state "idle" (idle animation) to the state "moving forward" (running animation). Of course, there are several possibilities to leave a state and go to another one, that's why the XML tag is 'transitions' and it's the parents of several elements 'transition', all describing how to go from the same state to others states.
- The "transitions" element contains several "transition" elements. Each "transition" is described by at least the 3 attributes "action", "toState" and "blendTime". Those attributes are used to know which triggers the transition (when to leave the previous state), to which state go to and for how long to blend the animations of the previous state (fromState) and next state (toState).
- This is the graphical representation of the anim graph example I took (first image) to explain to you what a animation graph is. On this picture you can see what the different states are and how we go to one to another. Each transition is represented by an arrow; the action which triggers it and its blend time are written next to it.
As you can notice, the same transitions appear several times but their arrows don't start from the same states. To avoid bad copy-paste, I defined a new XML tag in the animation graph schema. It's called "transitionSet" and like its name suggests, it's a set of transitions but unlikely the tag "transitions" it doesn't specify which state to leave. Thus, the transitions under it can't be used as if. Their "transitionSet" parent element must be referenced in a "transitions" element which defines the "fromState".
- All the transitons with the action "Moving Forward" and the toState "M_forwardMotion" attributes and the action "Moving Back" and the toState "M_backwardMotion" attributes are grouped together in one transitionSet called "M_Movement".
- Thanks to its name, a transitionSet element can be referenced under a transitions element which will specify the fromState attribute. Thus, a value of an attribute of the transitionSet will automatically be changed in all the references. To avoid this behavior for some references, the attribute can be overridden.
- The reference to the transition is broken. The result will be the same but any changes made in the transitionSet "M_Movement" will never affect those transitions anymore (since they are now "hardcoded").
If you remember, I told you that you could consider a state as an animation, let's complicate a little.
A basic state contains only one animation but a state is often more complicate. Generaly, a state can be a blend tree or a split body.
A blend tree explains how several animations are blended to obtain a more complex animation depending on the speed of the player for example.
A split body is actually the player split in two states: lower and upper states (a root bone is defined for splitting). Thus, the lower and upper parts of the body can have different animations.
For example, the legs can run whereas the arms wave a sword. For this specific kind of example I created "keepPreviousState" which tells the system to not stop the animation(s) play for the lower body. Only the state for the upper body changes. Thus, the animations for the legs don't pop!
We could imagine for a future version that each sub-state could also be a splitBody state and then obtain something recursively to play several different animations on different parts of the body.
The modification on the schema is really simple to obtain this but the modification in the C++ code is not!
YOU SHOULD WATCH THIS VIDEO IN FULL SCREEN MODE AND IN 720p HD.
This video illustrates all the things I told you about: the basics of the animation graph I defined and implemented for Project Offset.
It's a graphical representation of the schema I wrote to define all the rules to respect to well write an animation graph.
In this video, you can also notice that the notion of transitionSet is recursive. In fact, a transitionSet element can also reference other transtionSet elements.
I also highlight the defaultTransition element that I haven't explained yet. It's the transition which is taken if any other transition is taken before a certain amount of time which is specified in the defaultTransition element.
YOU SHOULD WATCH THIS VIDEO IN FULL SCREEN MODE AND IN 720p HD.
Sorry, the video is not really smooth. CamStudio had troubles to record while Project Offset Editor was running. Don't worry, Project Offset Editor is really fast!
More videos:
This video demonstrates how to edit an anim graph and test it in Project Offset Editor.
Of course, editing in Visual Studio was the first step. We wanted to be sure that we had all we needed with the second version of anim graph before writting a graphical editor of anim graphes. Actually, the 3D UI system I developed was also planned for this editor.
It's a one shot video. In this video, I illustrate how the animators worked using the second version of the animation graph (the one I defined and implemented) switching between Visual Studio and Project Offset Editor.
In this video, you can notice that a XSD schema was really useful to define the animation graph since the artists can have autocompletion and errors and warnings showed in a window. They had no excuses anymore if their anim graphes were not valid ;)
>Scenario of the video: the artist tests the simple animation graph but he notices he forgot the "M_Turning_Left" state. So he adds it but first he looks for the name of the animation he wants to play for this state. He edits the state and the missing transitions in the anim graph file. Then he tests the modification in Project Offset Editor after reloading the anim graph.
| nWave Digital | Project Offset, Intel | Orange Labs |
