From Inkscape Wiki
Revision as of 21:43, 7 June 2007 by SnapSilverlight (talk | contribs) (More basic info about animation interfaces.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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