Inkscape Wiki - User contributions [en]

Animation-(Timeline)

2008-04-17T15:40:42Z

SnapSilverlight: /* SMIL Animation (SVG Animation) vs SMIL Timing and Sync */ Initial entry

[[Animation|Back to main page for animation]]

=== User interface for timeline-based animation ===

==== Existing animation programs (Free & non-Free) ====

* [[MacromediaFlash]] is a good non-Free example.
* [[Ajax Animator]] is a FUNCTIONAL web-based (ajax) free-software clone of the flash interface, and uses a SVG based format for saving and compiling animations (http://osflash.org/ajaxanimator)
* Ikivo Animator is a good non-Free example producing SVG Tiny animations (http://www.ikivo.com/animator/index.html)
* Macromedia Director prior to version MX had a different interface (http://www.rice.edu/fondren/erc/howto/director.html) which I prefer(ed) over Flash
* QFlash is a FUNCTIONAL free-software mock-up of the Flash 4 interface, which can import SVG files but not edit them. (http://qflash.sourceforge.net)
* F4l is a non-functional free-software mock-up of the Flash 4 interface.(http://f4l.sf.net/)
* Anime Studio, formerly known as [[Moho]] (http://www.e-frontier.com/article/articleview/1913/1/793?sbss=793) a non-free example. (Written in Java.) Features skeletal animation ([http://www.e-frontier.com/article/articleview/1918/1/800?sbss=80х, unique bone rigging for 2D]) and automatic tweening of vector operations, [http://img.osnews.com/img/2547/moho4-rh.png view screenshot].
* [[LimSee2]] (http://wam.inrialpes.fr/software/limsee2/) is an excellent almost-free basis. (visible-source limited-use license)
* Spalah Flash (http://spalah.sourceforge.net/?p=10) (not to be confused with Spalah CMS) "is a GTK2[[/GNOME2]] based application for generating Macromedia SWF and [[W3C]] SVG animations." The GUI is today minimalist but the author is trying to integrate it with inkscape. See http://spalah.sourceforge.net/?p=19
* SMIL 2.1 player: http://www.cwi.nl/projects/Ambulant/distPlayer.html (GPL)
* Bob Sabiston's proprietary animation software http://www.flatblackfilms.com
* [[Synfig]] ([http://www.synfig.com/ link]) is a film-quality 2D vector animation editor and renderer. It features image morphing between drawings and output animation that is resolution independent both visually and temporally. (GPL)
* Ktoon (http://ktoon.toonka.com/) is a 2D Animation Toolkit designed by animators for animators, focused to the Cartoon Industry. (GPL)
* Jahshaka (http://www.jahshaka.org/) multiplatform QT animation program powered mostly by OpenGL (GPL)
* Powerpoint (http://office.microsoft.com) has an easy but basic interface. No flash killer, but some nice ideas.
* The Tab (http://www.the-tab.com/) Another non-free example that features elegant systems for parent-child animation and a very interesting feature that is designed for pseudo-3D camera moves.
* Pencil (http://www.les-stooges.org/pascal/pencil/index.php?id=Home) vector and bitmap free animation package using Qt toolkit run on Win32 (XP and works fine on wine), and MacOSX. Simple but already powerful basic animation. It uses blender like timeline with multiple layers and Author plan to export SVG.
* SVGDeveloper (http://www.perfectsvg.com/) is a non-free SVG authoring tool with animation support.
* Blender3D (http://blender.org/) is a 3d (eq. vector) animation program featuring [http://wiki.blender.org/index.php/Manual/Animation_Basics key frame, motion curve, path animation] using [http://wiki.blender.org/index.php/Manual/Ipo_Curves_and_Keyframes interpolation (IPO) curve editing] combining with [http://wiki.blender.org/index.php/Manual/Shape_Keys shape keys] and [http://wiki.blender.org/index.php/Manual/Animation/Lattice_Animation deforming by a lattice] (GPL)
* [http://gimp.org Gimp] the bitmpa editor and it's included animation script for gif is really minimalistic and frame based
* [http://gimp.org Gimp-GAP] (wich stand for Gimp Animation Plugin) is a gimp plugin has some good interfaces for managing movments of objects (menu video=>movepath), layer management and apply effects along animation. A powerfull onionskin management, and notions of clip/storyboard, but could be slow in complexe case and slow computers.
* [http://www.tvpaint.com TV Paint] is a non-free bitmap based compositing and animation package. It works with a timeline and layers. Notable feature is the onion skin "mixer", which let's you adjust the brightness of multiple frames before and after the current one.
* [http://www.toonboom.com/ Toon Boom] is a non-free vector based frame by frame anmiation package. It simulates a lot of the tools familiar to traditional animators, such as a dope sheet, field charts and more. Has two modes, one for drawing "cels" and one for placing them in front of a virtual camera in basic 3D space.

==== 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). [[Sketch|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)

[http://en.wikipedia.org/wiki/Onion-skinning 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 [http://www.classapart.org 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 [http://www.w3.org/TR/2005/REC-SMIL2-20051213/animation.html SMIL's "Animation" module], with a [http://www.w3.org/TR/SVG11/animate.html#RelationshipToSMILAnimation 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?

[http://www.w3.org/TR/2005/REC-SMIL2-20051213/smil-timing.html 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?

[[Category:Developer Discussion]]

Animation-(Timeline)

2008-04-17T15:22:48Z

SnapSilverlight: /* User interface for timeline-based animation */

Animation-Conceptualization

2007-06-07T21:50:59Z

SnapSilverlight: nesting stuff

[[Animation|Back to main page for animation]]

== Traditional Animation based Controls ==
Most animation controls are based on the ways that traditional animators plan out their animation.
=== Exposure Sheets / Curves View / Timeline ===
Exposure sheets are paper spreadsheets used by animators to plan out the timing of actions, to allow the director to communicate when certain actions must occur, and on what frames speech sounds occur. Animators indicate on the exposure sheets which frames are "key" (important) frames, and at what time they occur. During the planning phase of animation, the animator often will draw arcs along the time axis of the exposure sheet to indicate the approximate pacing she wants the character to move at during that action. The computer equivalent of Exposure sheets are the "graph view" or "curves view" in animation programs. These typically display a single value of a parameter, graphed against time, with adjustable curve handles to more carefully alter the timing. Traditionally, exposure sheets ran vertically down the side of the animator's desk, but on the screen, they are typically horizontal, so more time can be displayed on the screen. In SVG animation, this could also represent animated color palettes using a gradient bar to display the color change over time. See also the discussion at [[Animation-(Timeline)]]

=== Light Table / Onion Skinning / Ghosting ===
The standard animator's tool for making sure that animation lines up correctly with previous drawings is the light table. In digital animation programs, this is typically done by displaying previous and subsequent frames, or parts of frames, at reduced opacity, and rendered "behind" the current objects. This will require a UI option, and should not be actual scene objects added via a script. Since SVG does not rely on specific frame times, this should likely represent "snapshots" of the scene at specific offsets from the current time (another option, easily adjustable and enabled/disabled)

=== Timing Charts / Motion Paths ===
In the earliest days of animation timing charts were drawn along the arcs which parts of the character would move. Animators today still will sometimes indicate a motion arc on the "key" frames, even though the timing charts are typically drawn along the side of the page. The CG analog to this is a "motion path" created by tracking a single point on the character through computer-tweened motion, and drawing a line representing its motion before and after the current frame. This would probably best be approached as a "guide" - a temporary non-scene object, that could easily be applied, and cleared either individually or as a group.
== Other Concerns ==
=== Computer Tweening vs Independent Frames ===
This is a continuous issue in digital character animation. While the computer can generate smooth transitions between frames, none of the default interpolations are particularly realistic. Animation tools should still allow for the ability to generate frame-by-frame animation easily, despite the fact that this will consume much greater processor time and disk space when used. Much of the reason for the lack of realistic computer interpolation is that it is still very artificial to adjust the animation targets, and the movement between them, in most digital animation suites. Ideally this should be accomplished in as close a workflow to traditional animation as possible - that is, drawing the original, target, and any necessary-to-define intermediate frames to create the appropriate movement. Inkscape is already well ahead of the game on this, with its ability to 'paint' line weight onto or off of strokes, as well as grabbing lines anywhere along their path, and adjusting them. The possibility of using "As rigid as possible" dynamics on scene objects is also promising. It might be a good idea to have a way to reshape a path by simply drawing the approximate path it should follow on a frame, as well - and fitting the curve to that shape, possibly generating a key, since animators are often accustomed to drawing frames.

=== Nested Timelines ===
One thing SVG does encounter, is that there ''will'' be multiple timelines in the scene - each SVG animation block is specified by a start trigger, which may be at a specific time offset from the moment the page is first rendered (movie-like playing), or may be triggered by a javascript or other event (interactive behavior). Timelines can be looped within the main timeline, or skipped entirely, and they may either rewind to the initial state, or freeze at the end state when complete. Therefore, it'll be necessary for Inkscape to explicitly display to the user which timeline it's working with, and only render extra animation feedback from the above items for elements which it actually makes sense to show animated in the current timeline.

=== Nested Timeline View ===
Timelines should themselves be viewable in the master timeline, as appropriate - particularly when they occur within one another. The easier it is to move them around, and combine them, the more complicated (and theoretically, better) presentations will be produced by Inkscape users. A good example of this is Adobe After Effects's Timeline - which is intended more for assembling linear timelines together. In addition, this timeline style presents a good inspiration for how to handle animation of attributes which don't lend themselves well to the more common "graph view".

=== Static Light Table ===
''that's a Toon Boom Studio term''
Animated elements in alternate timelines may need to be displayed at a specific frame for the user's reference, when editing the current timelline. There should be some way to specify this, if it's not precisely defined by the way the SVG file is currently assembled.

=== Flash Export ===
Users will no doubt demand this feature. Swftools.org has a library which can be used for exporting SWF files. In addition, byte-compiled swf files are often half the size of an equivalent SVGZ file. As Adobe will cease supporting Adobe SVG player as of 2008, it's possible that its code will be included with future versions Adobe Flash Player.

[[Category:Developer Discussion]]

Animation-Conceptualization

2007-06-07T21:46:58Z

SnapSilverlight: tagging new page

[[Animation|Back to main page for animation]]

Most animation controls are based on the ways that traditional animators plan out their animation.
=== Exposure Sheets / Curves View / Timeline ===
Exposure sheets are paper spreadsheets used by animators to plan out the timing of actions, to allow the director to communicate when certain actions must occur, and on what frames speech sounds occur. Animators indicate on the exposure sheets which frames are "key" (important) frames, and at what time they occur. During the planning phase of animation, the animator often will draw arcs along the time axis of the exposure sheet to indicate the approximate pacing she wants the character to move at during that action. The computer equivalent of Exposure sheets are the "graph view" or "curves view" in animation programs. These typically display a single value of a parameter, graphed against time, with adjustable curve handles to more carefully alter the timing. Traditionally, exposure sheets ran vertically down the side of the animator's desk, but on the screen, they are typically horizontal, so more time can be displayed on the screen. In SVG animation, this could also represent animated color palettes using a gradient bar to display the color change over time. See also the discussion at [[Animation-(Timeline)]]

=== Light Table / Onion Skinning / Ghosting ===
The standard animator's tool for making sure that animation lines up correctly with previous drawings is the light table. In digital animation programs, this is typically done by displaying previous and subsequent frames, or parts of frames, at reduced opacity, and rendered "behind" the current objects. This will require a UI option, and should not be actual scene objects added via a script. Since SVG does not rely on specific frame times, this should likely represent "snapshots" of the scene at specific offsets from the current time (another option, easily adjustable and enabled/disabled)

=== Timing Charts / Motion Paths ===
In the earliest days of animation timing charts were drawn along the arcs which parts of the character would move. Animators today still will sometimes indicate a motion arc on the "key" frames, even though the timing charts are typically drawn along the side of the page. The CG analog to this is a "motion path" created by tracking a single point on the character through computer-tweened motion, and drawing a line representing its motion before and after the current frame. This would probably best be approached as a "guide" - a temporary non-scene object, that could easily be applied, and cleared either individually or as a group.

=== Computer Tweening vs Independent Frames ===
This is a continuous issue in digital character animation. While the computer can generate smooth transitions between frames, none of the default interpolations are particularly realistic. Animation tools should still allow for the ability to generate frame-by-frame animation easily, despite the fact that this will consume much greater processor time and disk space when used. Much of the reason for the lack of realistic computer interpolation is that it is still very artificial to adjust the animation targets, and the movement between them, in most digital animation suites. Ideally this should be accomplished in as close a workflow to traditional animation as possible - that is, drawing the original, target, and any necessary-to-define intermediate frames to create the appropriate movement. Inkscape is already well ahead of the game on this, with its ability to 'paint' line weight onto or off of strokes, as well as grabbing lines anywhere along their path, and adjusting them. The possibility of using "As rigid as possible" dynamics on scene objects is also promising. It might be a good idea to have a way to reshape a path by simply drawing the approximate path it should follow on a frame, as well - and fitting the curve to that shape, possibly generating a key, since animators are often accustomed to drawing frames.

=== Nested Timelines ===
One thing SVG does encounter, is that there ''will'' be multiple timelines in the scene - each SVG animation block is specified by a start trigger, which may be at a specific time offset from the moment the page is first rendered (movie-like playing), or may be triggered by a javascript or other event (interactive behavior). Timelines can be looped within the main timeline, or skipped entirely, and they may either rewind to the initial state, or freeze at the end state when complete. Therefore, it'll be necessary for Inkscape to explicitly display to the user which timeline it's working with, and only render extra animation feedback from the above items for elements which it actually makes sense to show animated in the current timeline.

=== Nested Timeline View ===
Timelines should themselves be viewable in the master timeline, as appropriate - particularly when they occur within one another. The easier it is to move them around, and combine them, the more complicated (and theoretically, better) presentations will be produced by Inkscape users. A good example of this is Adobe After Effects's Timeline - which is intended more for assembling linear timelines together. In addition, this timeline style presents a good inspiration for how to handle animation of attributes which don't lend themselves well to the more common "graph view".

=== Static Light Table ===
''that's a Toon Boom Studio term''
Animated elements in alternate timelines may need to be displayed at a specific frame for the user's reference, when editing the current timelline. There should be some way to specify this, if it's not precisely defined by the way the SVG file is currently assembled.

=== Flash Export ===
Users will no doubt demand this feature. Swftools.org has a library which can be used for exporting SWF files. In addition, byte-compiled swf files are often half the size of an equivalent SVGZ file. As Adobe will cease supporting Adobe SVG player as of 2008, it's possible that its code will be included with future versions Adobe Flash Player.

[[Category:Developer Discussion]]

Animation-Conceptualization

2007-06-07T21:43:31Z

SnapSilverlight: More basic info about animation interfaces.

Most animation controls are based on the ways that traditional animators plan out their animation.
=== Exposure Sheets / Curves View / Timeline ===
Exposure sheets are paper spreadsheets used by animators to plan out the timing of actions, to allow the director to communicate when certain actions must occur, and on what frames speech sounds occur. Animators indicate on the exposure sheets which frames are "key" (important) frames, and at what time they occur. During the planning phase of animation, the animator often will draw arcs along the time axis of the exposure sheet to indicate the approximate pacing she wants the character to move at during that action. The computer equivalent of Exposure sheets are the "graph view" or "curves view" in animation programs. These typically display a single value of a parameter, graphed against time, with adjustable curve handles to more carefully alter the timing. Traditionally, exposure sheets ran vertically down the side of the animator's desk, but on the screen, they are typically horizontal, so more time can be displayed on the screen. In SVG animation, this could also represent animated color palettes using a gradient bar to display the color change over time. See also the discussion at [[Animation-(Timeline)]]

=== Light Table / Onion Skinning / Ghosting ===
The standard animator's tool for making sure that animation lines up correctly with previous drawings is the light table. In digital animation programs, this is typically done by displaying previous and subsequent frames, or parts of frames, at reduced opacity, and rendered "behind" the current objects. This will require a UI option, and should not be actual scene objects added via a script. Since SVG does not rely on specific frame times, this should likely represent "snapshots" of the scene at specific offsets from the current time (another option, easily adjustable and enabled/disabled)

=== Timing Charts / Motion Paths ===
In the earliest days of animation timing charts were drawn along the arcs which parts of the character would move. Animators today still will sometimes indicate a motion arc on the "key" frames, even though the timing charts are typically drawn along the side of the page. The CG analog to this is a "motion path" created by tracking a single point on the character through computer-tweened motion, and drawing a line representing its motion before and after the current frame. This would probably best be approached as a "guide" - a temporary non-scene object, that could easily be applied, and cleared either individually or as a group.

=== Computer Tweening vs Independent Frames ===
This is a continuous issue in digital character animation. While the computer can generate smooth transitions between frames, none of the default interpolations are particularly realistic. Animation tools should still allow for the ability to generate frame-by-frame animation easily, despite the fact that this will consume much greater processor time and disk space when used. Much of the reason for the lack of realistic computer interpolation is that it is still very artificial to adjust the animation targets, and the movement between them, in most digital animation suites. Ideally this should be accomplished in as close a workflow to traditional animation as possible - that is, drawing the original, target, and any necessary-to-define intermediate frames to create the appropriate movement. Inkscape is already well ahead of the game on this, with its ability to 'paint' line weight onto or off of strokes, as well as grabbing lines anywhere along their path, and adjusting them. The possibility of using "As rigid as possible" dynamics on scene objects is also promising. It might be a good idea to have a way to reshape a path by simply drawing the approximate path it should follow on a frame, as well - and fitting the curve to that shape, possibly generating a key, since animators are often accustomed to drawing frames.

=== Nested Timelines ===
One thing SVG does encounter, is that there ''will'' be multiple timelines in the scene - each SVG animation block is specified by a start trigger, which may be at a specific time offset from the moment the page is first rendered (movie-like playing), or may be triggered by a javascript or other event (interactive behavior). Timelines can be looped within the main timeline, or skipped entirely, and they may either rewind to the initial state, or freeze at the end state when complete. Therefore, it'll be necessary for Inkscape to explicitly display to the user which timeline it's working with, and only render extra animation feedback from the above items for elements which it actually makes sense to show animated in the current timeline.

=== Nested Timeline View ===
Timelines should themselves be viewable in the master timeline, as appropriate - particularly when they occur within one another. The easier it is to move them around, and combine them, the more complicated (and theoretically, better) presentations will be produced by Inkscape users. A good example of this is Adobe After Effects's Timeline - which is intended more for assembling linear timelines together. In addition, this timeline style presents a good inspiration for how to handle animation of attributes which don't lend themselves well to the more common "graph view".

=== Static Light Table ===
''that's a Toon Boom Studio term''
Animated elements in alternate timelines may need to be displayed at a specific frame for the user's reference, when editing the current timelline. There should be some way to specify this, if it's not precisely defined by the way the SVG file is currently assembled.

=== Flash Export ===
Users will no doubt demand this feature. Swftools.org has a library which can be used for exporting SWF files. In addition, byte-compiled swf files are often half the size of an equivalent SVGZ file. As Adobe will cease supporting Adobe SVG player as of 2008, it's possible that its code will be included with future versions Adobe Flash Player.

Animation-(Timeline)

2006-07-02T00:10:04Z

SnapSilverlight: /* Existing animation programs (Free & non-Free) */

[[Animation|Back to main page for animation]]

=== User interface for timeline-based animation ===

==== Existing animation programs (Free & non-Free) ====

* [[MacromediaFlash]] is a good non-Free example.
* Macromedia Director prior to version MX had a different interface (http://www.rice.edu/fondren/erc/howto/director.html) which I prefer(ed) over Flash
* QFlash is a FUNCTIONAL free-software mock-up of the Flash 4 interface, which can import SVG files but not edit them. (http://qflash.sourceforge.net)
* F4l is a non-functional free-software mock-up of the Flash 4 interface.(http://f4l.sf.net/)
* [[Moho]] as a gratis-but-non-free example. (Written in Java.)
* [[LimSee2]] (http://wam.inrialpes.fr/software/limsee2/) is an excellent almost-free basis. (visible-source limited-use license)
* Spalah Flash (http://spalah.sourceforge.net/?p=10) (not to be confused with Spalah CMS) "is a GTK2[[/GNOME2]] based application for generating Macromedia SWF and [[W3C]] SVG animations." The GUI is today minimalist but the author is trying to integrate it with inkscape. See http://spalah.sourceforge.net/?p=19
* SMIL 2.1 player: http://www.cwi.nl/projects/Ambulant/distPlayer.html (GPL)
* Bob Sabiston's proprietary animation software http://www.flatblackfilms.com
* [[Synfig]] ([http://www.synfig.com/ link]) is a film-quality 2D vector animation editor and renderer. (GPL)
* Ktoon (http://ktoon.toonka.com/) is a 2D Animation Toolkit designed by animators for animators, focused to the Cartoon Industry. (GPL)
* Jahshaka (http://www.jahshaka.org/) multiplatform QT animation program powered mostly by OpenGL (GPL)
* Powerpoint (http://office.microsoft.com) has an easy but basic interface. No flash killer, but some nice ideas.

==== 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). [[Sketch|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 :)

==== 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 ====
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.

[[Category:Developer Discussion]]

Synfig

2006-07-02T00:02:15Z

SnapSilverlight: Inkscape-relavent Synfig notes. Or Synfig-relavent Inkscape notes?

This is a page to discuss Synfig as it relates to Inkscape. General non-Inkscape discussion of Synfig should take place on [http://wiki.synfig.com Synfig's wiki].
==Overview==
(''I'll import something off of Synfig's website later. Or someone else can.'' [[User:SnapSilverlight|SnapSilverlight]])
==Similarities==
* File format is based upon XML.
* Vector-based graphics software intended for artist use
* Open Source / GPL
==Differences==
;'''Intent'''
:''Synfig'': 2D animation suitable for broadcast/film
:''Inkscape'': SVG specification
;'''Interface'''
:''Synfig'': Focus is animation
:''Inkscape'': Focus is illustration
;'''Status'''
:''Synfig'': In alpha demo - much is slated for change, and bugs are usually fatal.
:''Inkscape'': A very stable, featureful beta. If it wasn't changing so rapidly, we'd call it "mature".

Animation

2006-07-01T23:31:56Z

SnapSilverlight: mostly spellchecking and cosmetic, slight change to Synfig line

This is the place-holder for the brief introduction and collections of links to different discussion pages.

As developments continues, we're now approaching the milestones that mentioned animation. Animation is one of the biggest hurdle in writing a vector program, so here is the place to hold the collections of all information, especially the discussions.

== Discussions ==

=== Basic support ===
* SVG's animation spec

=== User-interface ===

* [[Animation-Conceptualization | Conceptualization]]
* [[Animation-(Timeline) | Timeline]]

Collaborate with [[Synfig]]? ([http://www.synfig.com/ link])

[[Category:Developer Discussion]]