From K-3D

Design Goals

• Any property that is connectible should also be animatable. The system should be as powerful as the rest of k3d. It should work well for procedural setups.

• The system should be able to use another input instead of time, so that driven animations can be created.

• The system should generally produce most commonly intended results. The setting to control interpolations should require changing under only rare circumstances.

• The user wants to see his animation in pop-through mode with no inbetweens, however he has already set some key properties to specially control interpolation. He wants to be able to go to pop through, or linear inbetween mode, but then come back to full interpolation with all his setting intact. It is recommended that popthrough and linear be modes that can override the interpolation for viewing purposes, with out actually affecting underlying data.

• Track - A node that acts as a switcher between several inputs, possibly interpolating between the inputs. The inputs to a track would be of the same type. The word track is chosen because of its use in several other software packages. (Maya, 3dsmax, etc...)

• Key - The group of properties that make up what a animator (user) would think of a key as being, together the properties of a key define its state, the time that state occurs, and how that state should be interpolated with the other states. This word "key" is very standardized in the industry.

• State - The actual value of the key. This could optionally come from a dependency, or be stored within the track itself.

• Time - The time when the key should occur, or the driving value at which the key could occur.

• Out interpolation - The interpolation used while leaving this key to the next key in time. Might have several properties as the part of the out interpolation.

• In interpolation - The interpolation used while arriving to this key from the previous key in time. Might have several properties as the part of the out interpolation.

A Proposal For an Animation System

Intro

The following outlines a fairly revolutionary way of doing animation, but one which would still seem familiar and intuitive to existing animators.

It is based on the idea that everything should be animatable, in the same way that everything should be connectible, and also the idea that the keys should have their histories intact, so that procedural keys can exist which could have relationships to each other and also to other nodes in the scene. Basically, this animation architecture would not limit what could be animated, the user could animate geometry inputs, transforms with various parenting, which modifiers were applied to objects, and pretty much anything else.

Obviously, if everything is animatable, there will be many situations in which there is no sensible way to interpolate between different states. For example we couldn't interpolate between a mesh input where the sources were a cube and a car. In such situations, we can just use pop-through interpolation, where the state of one key is maintained until the time that the next key occurs, at which point the cube would pop, instantaneously going from being a cube to being a car.

When implementing animation, we could first make everything work well for popthrough animations, and then start working on the interpolation, where it makes sense to interpolate.

Description

An animated proprety would be a property connected to a "track" node. The track node would act as a switcher between various states. Track nodes would exist for each property "type" in k3d.

A track would contain several "keys". Each key would have properties that could be edited, most importantly, a value and a time. A track would have other properties as well.

The track would have a refresh property also (or we could just call it an "on" property). This would allow the user to turn the animation on and off.

The track would have a driver property would control which of the states was active, and would usually be connected to and dependent on time.

If the refresh property was on, the current value would change according to the keys and the time value, if the user scrubbed the time slider, the current value would play through the keys in the track, resulting in animation. If the refresh property was off, the current value would not change when time or keys were changed.

Example

The simplest track node would change between scalar values, called keys, when the time was changed. Consider a sphere with a posZ property, ("position in Z"), which was animated using a track. Suppose it started on the ground on frame zero, moved up to 10 units above the ground on frame 7, and then moved back to the ground by frame 14.

The posZ would have a dependency on the track nodes current value.

The track would have three keys.

The first key would have a value of 0, and a time of zero. The second key would have a value of 10 and a time of 7. The third key would have a value of 0 and a time of 14.

Now suppose that the animator wanted the sphere to bounce back up again on frame 18. He would change the timeline to frame 18. The current value of there sphere would change to 0, since the last key on frame 14 was zero. The animator would move the sphere up to 6 units in the 3d view (this would change the current state value, or add a transform node connected to the current state value), and would use a command to set a key on the track. A new key would be created, its time property being 18. The current value would then be copied to the keys "state" property. (If the current value had a history, then that history would be connected to and a dependency of the new key's state property).

More use cases and example will be added to this section

Definitions:

• Track - A node that acts as a switcher between several inputs, possibly interpolating between the inputs. The inputs to a track would be of the same type. The word track is chosen because of its use in several other software packages. (Maya, 3dsmax, etc...)

• Track Driver - A property of the track which would control the track switching/interpolating between the various keys. Usually the track driver would time (the output from the time source node).

• Current Track State - This is the current state of the track, which would normally output to the property that was being animated. When the user edits that property in the UI, the current track state would be changed. (Thus, animated properties can still easily be changed in the UI.) Also, when "set key" is used, the current track state is copied into a new key with the current time.

• Default Track State - This is the default state, and normally would be set as whatever the property being animated had been before it was animated.

• Key - The group of properties that make up what a animator (user) would think of a key as being, together the properties of a key define its state, the time that state occurs, and how that state should be interpolated with the other states. This word "key" is very standardized in the industry.

• State - The actual value of the key. This could optionally come from a dependency, or be stored within the track itself.

• Time - The time when the key should occur, or the driving value at which the key could occur. The time value would be a scalar (float).

• Out interpolation - The interpolation used while leaving this key to the next key in time. Might have several properties as the part of the out interpolation.

• In interpolation - The interpolation used while arriving to this key from the previous key in time. Might have several properties as the part of the out interpolation.

• Active - Whether the key is turned on or off, if off the track would act the same as if the key didn't exist at all.

• Character Set (or just "character" for short) - The character set is a collection of nodes which is used to make animation easier. Keys are generally set for the entire character set at once, or for various sub sets of the properties in the character set. The character set is essentially a manager, it helps the user out by editing things in the scene all automatically instead of the user having to manually go to each node and set up new keys..

Diagram

Here is a diagram showing the connections in a system for an animated input mesh. (Note my scanner is broken so I had to use my camera to take the picture, sorry about the image quality.)

Things we should assume the user intends by default

For all motions to have ease in and out whenever the object slows down/speeds up, but for ease in and out to never cause a hitch in the animation, unless explicitly set. A key typically has ease in and ease out set together.

That the user wants to avoid extra motion wherever it isn't necessary. No overshoot should exist unless it is needed to smooth out a path through space.

• When ease in and ease outs are used on keys, no curvature need exist in any path through space.
• If two keys are approximately the same position, but a large amount of time passes between them, the interpolation should not float or drift very much, regardless of the keys around the motion. The software should be smart enough to ease in and out of this slow motion, and adjust the curvature accordingly.

That the user wants to be able to explicitly set inbetween position "breakdowns" and have the computer use those breakdowns in the inbetweening solution. It should be possible for inbetweens to be either absolute or relative to the keys around them, both in terms of state, and time. (Ie, in relative mode, a breakdown key could specify that the state was 80% of the way between the previous key and the next key, at 60% of the time between them.)

Use Cases

Case 1

The user animates an elevator. It starts on the ground floor and moves up.

Method used: The user goes to the frame he want the motion to start, sets a position key, then goes to the frame where he wants the elevator to be moved up. If the "animate" button wasn't already on, the user turns it on. The user moves the elevator up. A key is set automatically at this new position. Two keys should now exist.

Result that should occur: The elevator should now be animated. There should be two keys. It should ease out of the first key and ease in to the second, so that it doesn't look robotic.

After the first movement, the animator wants the elevator to wait for a while, and then move farther up to the next floor.

Method used: The animator goes to a frame several seconds after the elevator had stopped. He pushes the set key button. That creates a hold, beacuse it is the same as the last key that was set. The animator goes a few seconds later, and moves the elvator up to the next floor. A key is automatically created.

Result that should occur: The elevator should now Move up, stop, hold there for a while, and then move up again. The moves should have ease in and out, and the elevator should not move or drift at all during the hold.

Case 2

In this example, we make the elevator more complex. It doesn't just move up and down, but it can also move from side to side.

Let us assume a brand new animation, and no prior keyframes. The animator sets 4 keyframes to create a motion of the elevator moving up, then moving to the right, then moving up again. Here is a list of key x,y,z,time values

(0,0,0,0) (0,3,0,20) (2,3,0,40) (2,6,0,60)

This results in an animation represented in this picture:

The motion has automatic ease in and out at the start and end of the animation, which is good.

But the user doesn't want the object to follow a curved path.

The user selects all the keys and sets them to Slow in/out.

Because the object now slows down and speeds up when it approachs and leaves keys, there is no longer any need to curve the path through space to create smooth motion. When slow In Outs occur, and corner in the path through space is acceptable. This is always the case when a a motion comes to a complete stop. The software recognizes this, and adjusts the path thought space accordingly.

The animation now looks like this:

Perfect! And very little editing required to get there!

The animator sets a new key at (2,6.5,0,80)

Essentially, specifying that the elevator should go up slightly farther, but very slowly.

The animatrion unfortunately now has a hitch in it. This is to be expected since it is what was specified. The animation now comes to a stop at frame 60, and then speeds up and slows down to move the last bit farther up. The user sets the key on frame 60 to have no ease in/out and the animation is corrected to have no hitch!

Also, the user doesn't have to explicitly set the ease in on the final key, because the first and last keys have ease in/out by default.

The animation now looks like this:

Case 3

The animator wants to roll a box.

It should be possible to do this with 3 keys.

The blue box is the first key. On this key, the pivot point is in the bottom right corner.

The box rotates around that pivot until it reaches the next key frame, drawn as the dark green box. On that keyframe, the pivot is changed, set to be the other corner.

The box then rotates around this new pivot point until the next key is reached, the dark red key.

Voila, a rolling box!

Default interpolation of pivot point locations can be stepped (no interpolation, just jump from one to the next). In other software I've used, the pivot points location is always stepped interpolation.

Linked to previous keys

Move the first box back, or make it rotate 70 degress instead of 90, and the next roll will seem to go up hill.

Other

• An animator want to animate the color of a light from Blue to yellow, however, he would like to animate the hue of the light changing, not RGB. He sets the interpolation of the color to HSV mode instead of RGB mode. The light should interpolate from Blue to aqua to green to greenish-yellow to yellow.

• An object is animated. The user gives the object a new parent. The animation and its interpolation should stay intact.

• An animator wishes to roll a box along the floor. He doesn't want the box the slide, he wants it to simply rotate around the corner touching the ground, and then when a new corner touches the ground, he wants to be able to specify a new pivot point for the rotation interpolation, and the animate it rolling around that next point.
  • Character Studio Successfully solves this problem in a user friendly way.

• shaking

• changing coordinate systems

• move on surface, with rotation

keys sholdn't be stored as a place on the surface, they should be stored as a location in the surface objects coordinate system. The nearest point on the surface to the object should be used automatically. surface keys can also be stored above the surface this way as well, for example, an object hoping on a surface.

Problematic Cases No Software Handles well

• Describe better!! Breakdown and keys snapping their output to a frame number, but still internally storing their subframe information.

• Animating parenting, changing pivot points.

• Animating DG connections between nodes, such as which material is applied to an object.

Implementation

Current state

All existing animation plugins can be found under the "Animation" submenu of the "Create" menu. A single track is implemented so far, allowing animation of transformation matrices to a time stored as double. Adding further types simply requires a new template instance with a new uuid to modules/animation/animation_track.cpp. Once the design is validated, this will be done for all required types.

The animation track requires an "interpolator" object, which takes care of the interpolation between keyframes. These are also templated, so adding new types is easy, but the advantage of strong typing is retained, so it is impossible to connect an interpolator of the wrong type to an animation track.

An example document (anim_track_test.k3d) was added in the share directory, to demonstrate the usage of the current, basic, track.

A new timeline is in development, to enable keyframe manipulation:

Using this new timeline requires setting the K3D_NEWTIMELINE compile option to "ON". Doing so will use the new timeline as a drop-in replacement for the old one.

Issues

• Deleting keyframes: Implemented using "Delete key" buttons. Will also be added to the timeline panel using a context menu.

• Node insertion: In order to manipulate keyframes using the transformation tool, it should be possible to insert the animation track between the interactive tool node and the mesh instance. Proposal: Have the ngui code search for existing transform nodes beyond the animation track. -- Implemented

• User-friendly node insertion. Manually creating animation tracks and interpolators and then setting up the property connections is not exactly smooth. Furthermore, as all required types are added, the animation menu will contain a long list of tracks and interpolators, especially if we throw in different interpolation methods. Proposal: Add an "Animate" command to the connect property menu, that would pop up a window with a choice for interpolation type, keyframe data source (interactive tool, position node, ...) and time source. Data types would be auto-detected based on the chose time source and property to animate, saving the user the trouble of searching for the right combination in a long list.

Todo

• Add a context menu to the timeline
• Implement more complex interpolation methods
• User friendly Animate... menu