Difference between revisions of "Animation-(Timeline)"

From Inkscape Wiki
Jump to navigation Jump to search
(Spam.)
Line 50: Line 50:


Of course, on the web, with SVG and DHTML, where most Inkscape animations will hopefully be used one day, frames are not an issue at all, and we just worry about keys in time :)
Of course, on the web, with SVG and DHTML, where most Inkscape animations will hopefully be used one day, frames are not an issue at all, and we just worry about keys in time :)
ANOTHER NOTE: Interpolation does not necessarily occur along straight lines and linearly in time. Paths are already part of Inkscape, so points could move along paths; also he time-length graph can be something like a path, instead of a straight line.


==== Bob Sabiston Example ====
==== Bob Sabiston Example ====

Revision as of 18:29, 22 April 2006

Back to main page for animation

User interface for timeline-based animation

Existing animation programs (Free & non-Free)

Fantavision example

Back in the '80's there was a program on Apple IIE (Amiga and MS-DOS too) called "Fantavision". It allowed one to create vector artwork (although I didn't understand at the time that that was what it was called) and animations. It allowed one to create frames of animation where you manually repositioned, recolored, scaled, rotated etc. the objects from one frame to the next. However, it then automatically interpolated frames between the 2 frames (the number of interpolated frames was configurable) such that it create a smooth transition of the object moving from one frame to the other. The effect was very similiar to the "Morphing" effect for raster graphics (popularized in a Michael Jackson video, I believe). That is, the system calculated the trajectory of "Key Points" of the objects from one frame to the next. This process is often called "Tweening" (a term used by Macromedia Flash). Skencil (formerly known as Sketch) supports this functionality and describes it as "Blending".

I guess what I'm saying is that I think a nice interface to create animations would be similiar. So to animate you would do the following:

  • Draw the initial SVG Image
  • Increment Frame (from say 1 to 20)
  • Reposition the elements in frame 20 (including scaling, color changes, adding removing objects, etc, etc, etc)
  • System would then calculate a trajectory for each key point from frame 1 to frame 20. Trajectories would be calculated for things like:
    • Each "node" of an object
    • Color
    • Transformation Matrix
    • etc
  • You could display/manipulate the trajectories (using the trajectory editor shown above by the original creator of this topic)
  • The system would then store the animations using SVG trajectories and the "Key Points" would be the frames you manually created
So, to create say a 100 frame animation, one might only need to manually create/modify 10 frames and the system would interpolate the additional frames as necessary.
  • Also, once the system interpolated frames it would allow you to manually modify the interpolated frames creating further "Key Points" and allow further refinement and interpolation.


NOTE: 3D apps such as blender also use a technique like this, which I think is most widely known as "keyframe animation" or simply "keyframing". However, many such systems tie the keys too closely to actual animation frames, and this creates problems when the frames-per-second rate changes. Particularly in the case of vector apps which are not so low-level as bitmaps and animation frames, I would suggest that frames should be as abstract as possible.

Having key positions in simple percentages of the total animation time might be a better solution. This would also need to be a global/local system, of course: animated objects would have their own animation time specified when inserted into a larger document. A character's walkcycle would end at 100%, but in the larger animation, it would perhaps only be 5% of the total time, yet repeating as the object moves across the screen.

One issue with this abstraction of frames might be that important animation effects do not occur exactly within frames: small things could be mistimed, or simply missed altogether. If you set the frame rate too low, this would be an obvious side effect, so it's not necessarily a problem that Inkscape should try to fix. On the other hand, a few things could be done to ease this. For instance, "snapping" animation events to frames when exporting (thereby slightly altering the timing), or perhaps just warning that certain animation events are not visible at such a low frame rate.

Of course, on the web, with SVG and DHTML, where most Inkscape animations will hopefully be used one day, frames are not an issue at all, and we just worry about keys in time :)

ANOTHER NOTE: Interpolation does not necessarily occur along straight lines and linearly in time. Paths are already part of Inkscape, so points could move along paths; also he time-length graph can be something like a path, instead of a straight line.

Bob Sabiston Example

Bob Sabiston's animation software is an amazing vector-based package that stores line width within the points that make up a line -- derived from a tablet pen. usually in a simple stroke there could be a hundred data points storing width information. Then in the next keyframe, a line from a previous key is selected and re-drawn restricted to the same number of points. The software allow sthe points to be "repositioned" as you watch their previous locations be re-positioned. When you run out, the line ends automatically. This information is interpolated in tweening frames to change shape, width, position, but retains the same number of data-points. See the film "Waking Life" for the making-of video for a demonstration. Also visit his website for examples of it's capabilities converted to flash. http://www.flatblackfilms.com

Other thoughts

Suggestion from someone else: working like CinePaint (compared with Gimp), with each frame independently from each svg document (working like this or providing this feature) - providing vectorial edition quality we can't get on apps like Macromedia Flash or any other (maybe ToonBoom or Moho) - allowing us to make our work fast publish without further lack of quality. (One more suggestion about it: being able to convert .swf to .svg sequence (or animated .sgv) and vice versa.)

It is suggested that there be basically two modes: Local (Object) mode and Global mode. Below is a picture showing a very rough design of the local mode:

http://www.inkscape.org/wiki_uploads/anim_gui1.png

In local modes, all properties of the object editing will be shown on a timeline, and one can create and edit frame within the timeline. Then one may assign different value of that properties on different timeline, or make it change linearly, or nonlinearly :)


Onion Skinning

As an animator, one of the features I find most useful is the ability to view a series of frames layered on top of each other (called "onion skinning"). They don't need to be key frames, or even tied to a particular frame rate, just be representative of the state at regular time intervals. It's much more intuitive than looking at a graph of position vs. time or whatever you are animating. After all this is a tool to be creative with, and graphs are more suited to thinking like an engineer.