Difference between revisions of "Animation-(Timeline)"

From Inkscape Wiki
Jump to navigation Jump to search
(cat)
Line 1: Line 1:
{{DevDiscussion}}
[[Animation|Back to main page for animation]]
[[Animation|Back to main page for animation]]


Line 181: Line 182:


Using some shifting switch to go forward and backwards in time to follow your animation (or mouse gesture, but button press would be more useful). That way you have a direct interaction with the user and the document.
Using some shifting switch to go forward and backwards in time to follow your animation (or mouse gesture, but button press would be more useful). That way you have a direct interaction with the user and the document.
[[Category:Developer Discussion]]


::I strongly disagree with a model, that bases on frames. SVG is and should be only time-dependent. Start-duration-end. --[[User:VonHalenbach|SvH]] 16:41, 28 February 2009 (UTC)
::I strongly disagree with a model, that bases on frames. SVG is and should be only time-dependent. Start-duration-end. --[[User:VonHalenbach|SvH]] 16:41, 28 February 2009 (UTC)

Revision as of 07:46, 6 January 2012

Back to main page for animation

User interface for timeline-based animation

Existing animation programs (Free & non-Free)

Free (or Open Source)

Non-Free (Fee Based, or Proprietary)

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.

Jahshaka example

I have used jahshaka for a small animation. This was my first real experience with animation. Thought rough, jahshaka is all about key frames and setting properties for those key frames.

Things I liked

  • Key frames are on a per object basis
  • When an object is selected you can quickly move from one key frame to another
  • properties values for rotation can span beyond 0 and 360, permetting to set three or more complete rotation with too key frame. I think this kind of feature could be used for all bounded values (like color, transparency and so on). Is this compatible with SVG or should it be an artifact ?
  • representation of properties values on a time line graph. This functionnality was still not very usable, but being to interact through that kind of object could be very useful (see below)

Things that lacks (and Inkscape shall have)

  • possibility to copy animation properties from one object to another (say copy color animation, or whole animation)
  • possibility to modify a property value for all key frames at once (eg. translation of object for all key frames or a selcted group). I think this could happen through the value = f(time) graph metioned above. You could select points (representing keyframes) and move them up (more), down (less), right (sooner). This graph could be organised by properties set (color, position). I think this kind of graph would be very close to SVG animations tag.
  • macro that helps sets common effects (like blinking for example, or crossing the screen....)

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

Animation support in Inkscape offers great new opportunities. Here are some points that I think are important to keep in mind when adding animation to the GUI:

  • Originality
    Don't do as other do - except it's the best way.
  • Simplicity
    Animation should not stand in the way of the user. Only show as much as necessary to perform a certain task, and do things in the most natural way.
  • SVG-Orientation
    SVG animation is different in some ways. The UI should reflect this, and not reassemble concepts of tools that just work differently. E.g.,
    • SMIL animation has no concept of frames. So we don't need a frame-based timeline, but a time-based one.
    • SMIL animation in general is to animation what vector graphics is to graphics: It's declarative and object oriented. So one doesn't animate a scene, one animates objects on a scene, etc.
  • Coherence
    The animation UI should reassemble concepts that Inkscape users are already familiar with:
    • Animation timelines can in some contexts be treated as paths that one can add points to (keyTimes). Or one can control animation timing with splines (keySplines).

I composed a mockup that reflects the above mentioned characteristics to some extend: http://www.uni-bremen.de/~felwert/inkscape/Animation01.html

Powerpoint Example

You select an object and add types of animation. These are listed in the custom animation pane. They can be set to occur all at once, one at a time, onclick, with previous or after previous. A number appears next to each object in the editing window when the object has animation applied to it, representing the sequence of the animations. When an object has an Entrance type animation added to it as the first animation, it will not appear on screen until the timeline reaches this point. animations can be linked together to create quite complicated sequences.

Onion Skinning

Onion skinning is a standard animator tool, previous or next frames (sometime both) are displayed under the current frame with differrent color, or less contrast, allowing to understand wich drawing the animator is actually working on, and wich frame is 1 step or 2 step before or after the actual frame.

This can easily be implemented using transparency parameter of layer, and automatize selection of layers to be displayed, parameters following a specialized gui entries.

Onionskin in gimp-GAP is a good example of what should be a minimal requirement. that is managin backword, forward and both direction onion skin, with variable visiblity increase decrease. Color changes on onionskinning could be another useful option to increase visiblity of different frames, as generally the onionskinning is done at the sketching animation step (meaning mostly grey or black & white drawing)

Onion skinning on wikipedia.

Interactive

I have started using svg to develop interactive displays. Having used several other svg tools currently on the market, I am interested in a more generic implementation that doesn't have animation effects get in the way of interactive controls.


Playback of Construction Steps

We, at Class Apart ( www.classapart.org ), plan to use Inkscape in a manner similar to the classroom whitebord to create taught lectures and record the screen in an mpeg movie. The problem is that raster based formats would take about 50 MB for an hour of content, and does not go very well with our unstated goal of getting a whole course on a cd or all courses of a semester on one dvd. It would be great if we could store the construction steps of the svg keyed against time while recording. Then while playback we can patch the svg dom with the steps as needed, using something similar to smil script. How does one go about implementing this? We could find some members willing to implement.


Using Bones

Anime Studio (and all 3D animation software) uses bones to animate with. In Anime Studio you draw up a basic skeleton and then attach the drawing to the bones This is done automatically based on the distance between the bone and the points on the curve. You can then move, rotate or scale the bones to animate the characters. You can store these values per frame, and have the computer interpolate them. This is a much faster way to work than to interpolate the points on the drawing directly. 3D software is probably a better reference here than Anime Studio. Usefull features include:

  • Weighting of individual points to bones
  • Combining tweening and frame by frame animation. To create replaceable mouths, rotating heads and more.
  • Inverse kinematics, to speed up animation. With it you can grab the hand of a character and have the arm follow, rather than rotate the upper arm and lower arm separately to move the hand.
  • Constraining. Making one bone follow another, limiting the movement of a bone and so on.
  • Graph/Curve editor. A time based editor with b-splines representing the individual move, rotate and scale transformations. This gives the animator great control over the animation.

Drawing Frames

Toon Boom, Plastic Animation Paper, TV Paint, Animo and traditional 2D animation on paper, all use individual drawings per frame. This gives you by far the best control when doing character animation, but at the cost of a lot of work. Features that are needed for traditional 2D animation to work well include:

  • Onion skinning, preferably multiple levels back and forward and adjustable transparency.
  • Dope sheet or timeline where you can move frames back and forth and repeat/hold frames.
  • Cut-outs, where you move a whole or part of a frame to a different position for tracing on another frame.
  • Some way to do rough sketching. Plastic Animation Paper is a good example here, though it's bit map based. With a tablet it gives you pencil like feel when drawing, giving darker lines the harder you press. This helps the animator "find the line". It should be possible to do in vectors if using a central line that stores the pressure along each point (width and/or opacity), rather than an outline.

Combining tweening animation and frame by frame animation can in many cases give the best results.

SMIL Animation (SVG Animation) vs SMIL Timing and Sync

What should the scope of Inkscape's animation capabilities be? Many people are talking about mimicking other software's ability to do frame-by-frame animation and cartoon animation (particularly Flash's).

SVG inherits from SMIL's "Animation" module, with a few added animation controls for animating a path, transform, or animating along a path.

SMIL's animation module however does not provide for elements to begin or end, although we can fake this by having elements initially invisible, and animating their visibility to 'true' during their lifespan.

While this may be feasible for a few long animations (ie, scenes), will it work for someone attempting to do traditional 2D (even Flash-style) animation? Said hypothetical user, while they may take some advantage of shape and motion tweens, will also likely need to replace the entire drawing when elements of the drawing (characters et al) change their logical structure (a motion requiring a line to appear or disappear). If this is to be supported, Inkscape will need some VERY fast code for switching visibility on-and-off during previewing, as it may be considering the visibility of hundreds if not thousands of graphic elements at a time, to over a dozen times per timeline-second.

Will other SVG viewers be able to handle that, too, or is it a special use of SVG that's not central to the aim of Inkscape?

SMIL's "Timing and Synchronization" module supports elements that allow for massive numbers of sequential images or animation elements, as well as defining animation attributes for begin/end/duration timelines. While it's not part of the SVG spec, would this be something Inkscape should look into implementing, or even proposing as an addition in a revision of the SVG spec?


A new idea I think

I can't let go of an idea I'll try to explain as clearly as possible. How about having Inkscape calculate frames in a certain resolution (say 1 to 28 a second) and depth (number of frames displayed) and displaying a number of subsequent frames in over or underlay (transparancy is possible, but eats time) with fading outline colours to depict passing time.

You set either the framerate (calculated) and begin and end frame in time, or select from begin and end instances of an animate. Alternatively, selecting paths from a list and showing all objects following that path. That way you could (if hardware allows) browse through your animation and look for hiccups in its motion.

The same interface depicting frame number could be used to display page numbers in a multi page document. Would be nice in combination with an object manager similar to Coreldraws, enabling to select an object in either defs and see what happens to it in the animation, a path or all USE, XLINK etc.

Using some shifting switch to go forward and backwards in time to follow your animation (or mouse gesture, but button press would be more useful). That way you have a direct interaction with the user and the document.

I strongly disagree with a model, that bases on frames. SVG is and should be only time-dependent. Start-duration-end. --SvH 16:41, 28 February 2009 (UTC)

Custom Keytime-based Timeline

Not based on frames at all, although the ability to select a frames-per-second setting allows for a grid that could be used to emulate frame-based animation. I posted the concept along with a mockup on the SpecSVGAnimation page. ("An example of the third..." to the end of that section) --JadeMatrix 16:32, 6 February 2009 (UTC)

In the animation, frames are of no use. You only edit the moving objects in time and when you are ready, you let it render into a number of frames or define, how much frames per second you need. But that is all after the file is saved as svg. Then the rendering can start. Construction and rendering are two different things, which we don't want to mix up in this process. --SvH 16:49, 28 February 2009 (UTC)
Responded over at SpecSVGAnimation.--JadeMatrix 04:43, 4 March 2009 (UTC)

SVG-animation THE object-oriented approach to animation

SVG-animation is compared to a framebased movieeditor like comparing turbo pascal with c++. These are two different worlds or paradigms. You have to relearn your language, because you have to forget to think in frames. Every object, Line, Rectangle, Path has his own time and space. You could move everything on one single path or give every object a different path to move on. Or you could change the size or its color over time. SVG-animation is designed to get animation on mobile devices. Inkscape should focus on those for animation. We certainly need a global-timeline, on which all animated things get a colored representation (a color bar for each object) of their movement in time. There are already programs to render animated svg into a number of png's or animated png. Inkscape must only be conformant to the svg-standard. --SvH 17:13, 28 February 2009 (UTC)

Retrieved from "https://wiki.inkscape.org/wiki/index.php?title=Animation-(Timeline)&oldid=76394"