Difference between revisions of "Animation-(Timeline)"

From Inkscape Wiki
Jump to navigation Jump to search
(* Add link to Ambulant SMIL 2 viewer)
(No difference)

Revision as of 00:18, 10 August 2005

User interface for timeline-based animation

Existing animation programs (Free & non-Free)

Other thoughts

Suggestion from someone else: working like CinePaint (compaired 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 MacromediaFlash 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 inlinearly :)

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 :)