Rigor is the name given to the animation editor I put together for Optimism. This is a summary of the idea behind it.
The purpose of the animation editor is to create individual animations for characters/items/etc. Something like flash is somewhat useful in this area, but we wanted animations that could be more easily modeled and interfaced with an interactive, dynamic game universe.
Instead of just exporting images of animation strips, Rigor will export a script that can generate a rig object in our game world. A rig consists of a skeletal model, images for each of its bones, and animations which are sequences of events that tell the rig how to behave. Specific parameters of a rig, which of the rig’s animations are running, the frame-rate for each animation, etc. are all properties of a rig which can be touched by the host program.
For example, if a character is walking, the game program might set the character’s rig animation to “walking”, but at the same time set the rig’s “head” bone’s target angle such that it points towards the mouse. The rig animates itself appropriately, causing the character’s feet to move at the right speed, and keeping the head from turning too far or too quickly.
Another feature which was not provided by other (affordable) software that I could find is the ability to set a dynamic dependence of the parameters of one bone in a skeleton to the parameters of another. For example, say you are making an animation of two interlocking gears. With Rigor, you can set the angle parameter of one of the gears to be proportionally dependent on the angle parameter of the other.
The software is built for modeling dynamic and reusable animations, so instead of animating a whole scene, the user will build and animate a single rig at a time. The skeleton of a rig is a bone with child bones, each of which may have their own child bones. All bones have three primary parameters: image, position, & angle. The position parameter determines the bone’s position relative to the position and orientation of it’s parent bone, and the angle parameter determines the rotation of the bone’s image, and the reference frame for any of its children.
Like many animation programs, this program’s animations revolve around key-framing, but perhaps not in as straightforward of a way as you’d expect. For each bone in a rig, there is a timeline track showing the frames for that bone. Each key frame has three parts, one for each of the primary parameters of a bone, and each part has one of three key frame modes: set, tween, & automate.
A “set” key frame simply sets one of the parameters as a constant until the next keyframe. A “tween” key frame not only sets the value of a parameter, but provides a tweening function so that the frames between it and the next key frame can be bridged mathematically (this is where the real animation comes in). In fact, a tween key frame might not directly set the value of a parameter at all - if it is preceded with an automate key frame (which I’ll talk about next), then it might simply be used to cancel the parameter automation function “smoothly”.
The “automate” key frame mode is the one that makes this system somewhat unique. These key frames don’t set exact parameter values for a bone, but instead give the bone a function which is constantly evaluated to calculate the parameter value. The function can have dependencies on any parameter of any bone, which allows for some very interesting animation strategies.
Is This Really A Good Idea?
Who the hell knows? If you know of a similar program or have some ideas of your own (suggestions, inspirations, condemnations) please let me know.