利用者:Aligorith/Action Editor Refresh

Introduction

Blender's Action Editor is an important part of the animation system, being one of the three windows (spaces) where keyframes can be viewed and edited. For many people, it is the window they use most when animating.

However, its functionality is currently limited, and the reasons why most of those functionalities are lacking is due to the underlying implementation being somewhat hackish. I discovered this when trying to add several features such as selection options.

In this project, I aim to reconstruct the action editor as I believe it should work. A key goal of this project is to increase usability and power.

Current Implementation

As I've mentioned earlier, the current implementation is (to me) a seemingly large hack, that piggybacks on top of the ipo system. All keyframe operations operate directly on ipo blocks, with many functions just wrapping events and converting them into a form suitable for the ipo functions. The most clear example(s) of this are selection functions.

Other pitfalls include

• There is no clear and easy way to access keyframes. Keyframe access is bydirectly iterating through the ipo beztriples.
• There is no unified way to access anim data. There are three sets of several things. Why three sets? Because each type of ipo-block that can be viewed/edited in the action editor is accessed in a slightly different way (shape-keys have one way, object another, bones another still)
• Only bones actually use actions.
• When the action editor is editing an action that is the active strip for nla, and the strip has some kind of scaling applied to it, then life gets confusing. The user has no clear indication of the consequences of their actions. Adding keyframes is not reliable. It is all in all, very confusing, and not at all reliable.

Proposed Structures / Key Concepts

Therefore, I propose the following terminology:

• NLA strips are a set of action strips that when evaluated for any given frame, gives the animation transform for an object/bone at that point in time.
• An Action Strip is an action that is part of an object/bone's nla strips.
• Actions are collections of action channels (as is currently)
• An Action Channel is really just an ipo-block. It represents a set of ipo curves belonging to a set blocktype.
• An Action Line is an ipo-curve. It contains keyframes
• An Action Stripe refers to any element that occupies a row of its own on the Name Panel. i.e. Action Channel, Action Line
• A KeyFrame in the action editor, is a wrapper for the bezier triples of an ipocurve.
• A KeyBlock in the action editor, is just a representation of two keyframes on the same curve that are identical (or identical in y-position).

Visually, the action editor is divided into two sections:

• Name Panel: where all the names and related stuff goes
• Time Grid: the grid where the keyframes are displayed

Visual Display

(TODO: add some mockups here...)

To reflect these new concepts, there needs to be some changes to the drawing. A hierachial-style display will be adopted, with various icons scattered in meaningful places in the display for indication purposes.

Another key difference is that more information is visible at a glance, without requiring trips to the ipo editor. Users should not have to feel/be intimidated by curves unless they really want to.

Left-Hand Name-Space Panel

• Bone/Object name(s) (aka. Action Channels) are displayed top-level.
  • They have a triangle thingy on the left-hand side that expands/minimises the display of sub-data.
  • Then comes the box in which the name and related things about the object go.
  • At the left-side of the box, there is an icon showing whether the action channel is an object or bone
  • In the middle of this box, the name of the object/bone is shown
  • On the right-side of the box, there is a padlock icon showing whether or not the action channel is locked (more on this in detail later)

• Ipo-block types present for an Action Channel are drawn one-level in, under the relevant Action Channel. They are only displayed if the Action Channel has been expanded.
  • Like for Action Channels, there is an expander/minimiser widget. This shows/hides the 'curves' for the block-type
  • Then comes the box in which the name and related things about the block-type go.
  • At the left-side of the box, there is an icon showing what the block type is (may not be needed - overkill)
  • In the middle of this box, the type of block is shown

• 'Lines' present for an Ipo-block are then shown one-level in again, under the relevant block. They are only displayed if the Action Channel and block-type are expanded
  • Like the others, it draws with the base box where info about it goes
  • Curve interpolation type is drawn as an icon or letter at left-hand side
  • Name goes in middle
  • Slider is drawn at right-hand side if setting in header-menu is turned on
    • Slider values are taken from the current y-value for the associated ipo curve at that frame
    • Changing value on slider inserts a new keyframe if none in frame, or changes value of existing one.

Keyframes and TimeGrid

• In General:
  • Keyframes are coloured according to what handle type they are
  • When two adjacent keyframes in the same line are the same, they are drawn as a single block (referred to as a keyblock)
  • Selected keyframes have a lighter colour than not-selected ones
  • Scaling a keyframe has the same effect as adding another keyframe that is exactly the same as that keyframe, and makes a new keyblock
  • Scaling a keyblock should move the later keyframe

• Presentation:
  • The timegrid space beside an Action Channel name displays all the keyframes in all curves for that channel
  • The timegrid space beside a block name displays all the keyframes in the ipo curves of that block
  • The timegrid space beside a line displays only the keyframes for that line

• Multiple Keyframes:
  • When multiple keyframes occur, they are layered on top of each other, with the colour of each contributing to the final colour.
  • When there are many keyframes layered over each other for that point in time, then only the last few contribute to the colour (5 to 10?)
  • The order or layering is top to bottom, in the order of the how lines are viewed
  • Selecting one keyframe has the effect of selecting all for that action channel at that point in time

• Current Frame:
  • The current frame is indicated with the light green line 2px wide, that spans the height of the timegrid.
  • It is changed by clicking and dragging this line, or by clicking on any frame within the timegrid

Editing Tools

Without any editing tools, even with these changes, the editor would be useless.

Selection Tools

Selection tools are some of the most important tools.

• Border Select:
  • Selects all the elements that are within the part of the display it was started over. For example, if it was started in the timegrid, it would select all the keyframes that were within that range. Same goes for over the names panel.
  • Standard blender hotkeys apply here

• RMB Select:
  • Standard behaviour here. Item under mouse button is selected or deselected according to whether or not it is selected or not

• Same Strip:
  • All keyframes in the selected strip are selected/deselected, depending on the command
  • Strips 'higher' up in hierachy override lower (i.e. select all in Action Channel strip, results in keyframes from everything under it being selected)
  • Menu entry, most likely in the header

• Same Frame:
  • If only one keyframe selected, every keyframe in that same frame in every action channel, is selected
  • If more than one keyframe is selected, then for each keyframe, the proccess for one keyframe is repeated
  • If no keyframes are selected, then the keyframes that occur in the current frame are selected
  • Menu entry (header), hotkey K, click on timegrid scales

Keyframe Modifying Tools

One of the main roles of the action editor is to present a way to edit keyframe data. Keyframe data is categorised into three main categories: time data, amount data, and handle type.

Time Data

Time Data is the horizontal (x) position of the keyframe (in an ipo curve), the time at which it has full influence.

• Visualisation:
  • Position of keyframes on timegrid along timescale, is the way in which keyframes are visualised.
  • Length of keyblocks indicates time one pose is held for

• Editing:
  • Editing is via transforms
  • Can only affect the position of the main x position, not that of little handles
  • Also possible via transform panel.

• Transforms:
  • Mouse Drag:
    • As per normal blender functioning.
    • Click-drag behaviour to move individual keyframes (transform mode -> translate)
  • Translate:
    • Goes into a transform mode -> translate.
    • Normal blender functioning here.
    • Moves all selected keyframes by relative amount derived from mouse movement.
  • Scale:
    • Single Keyblock selected:
      • Scaling keyblock moves later keyframe
      • Time moved relative to mouse movement
    • Single Keyframe selected:
      • Scaling keyframe makes new keyframe that is copy of selected
      • This makes a new keyblock
      • Then, this acts like keyblock scaling
    • Multiple keyframes (and or keyblocks) selected:
      • All selected are scaled by scale factor derived from mouse movement, with the place of scaling, the current frame marker.
  • Time Slide:
    • I've never really understood what this option does, so no comment on it.
    • Therefore, it won't be implemented.

Amount Data

Amount data is the vertical (y) position of the keyframe (in an ipo curve), what value it contributes when it is at full influence.

At this stage, this data will only be available for editing in two ways. The first is the sliders beside action lines, and the second is in the transform panel.

Handle Type

Handle types affect how the interpolation between two keyframes goes. They have more of an effect when editing.

• Visualisation:
  • Handle type of a keyframe is indicated by the colour of the keyframe

• Editing:
  • H hotkey brings up menu featuring types of handle
  • Menus feature commands that change handle types for selected keyframes
  • Transform Panel has setting to change this.

Strip Locking

There are often situations while animating where you have gotten some motion on some parts to a stage that you are generally happy with, but you've got some motion on other parts that is not yet there. By being able to protect that parts that are ok, while you work on the parts still needing work, you can save a lot of time, especially if you are prone to make many mistakes. Mistakes can be costly, espcially in the full thrusts of pressure-cooker commercial production environments, so it is important to avoid them where possible.

Note: This is already in cvs (as of late November/early December). However, only Action Channels and Constraint Channels have these. Shape-keys don't have this support yet, but they will when the other parts of this project have been completed.

• User-Interface:
  • Padlock icon on action strip name block indicates whether or not strip is protected/locked.
  • Clicking on this icon toggles locking.

• Implementation:
  • Checks in code for anything that modifies keyframes, checks if that keyframe is in a strip that has been protected/locked or not.

Transform Properties Panel

Transform Properties Panels provide a single, integrated place where a set of relevant data about the selected data can be edited.

(TODO: add some info here... also some mockups would be neat)

Other Matters

Here are some other matters that need addressing.

Timing

Ton has mentioned on several occasions that the timing system of blender needs a good checkup. Floats here, ints there, scaled timing here, non-scaled there, when will the madness end? I currently don't intend to tackle this in this project, as it will probably be another project in itself.

In General:

• Action being worked on in the action editor can either be stand-alone action (i.e. not in the nla), or the active strip in the nla.
• Strips in nla can get scaled as the result of repeat values in combination with strip lengths and action ranges.
• Editing actions that are used for action strips should not be confusing, and should be reliable.

So, what should we do about the problem with scaled actions?

• The user should be given a choice about whether to display the timings as they are in the nla or not.
• With scaled times, all transforms should be done with regard to the scaling. So no printing of delta x = 5.0 when scaling causes that to be more like delta x = 8.2, and so on. (I've fixed this in cvs)
• With scaled times, inserting keyframes should work so that:
  • Wherever the current frame marker is, that is where the keyframe should go after scaling + offsets
  • The actual keyframe should be inserted in the a place that is determined by removing the scaling of the strip, and removing the offset as well.
  • The result should be expected.

Current Status

2006 Dec 15

Some items from here have already been implemented (locks, long keyframes). Other, more destructive changes, I am finishing implementing so that they are ready by the time the next development cycle rolls around.

2007 Apr 29

Almost all the (user-end) changes detailed here have been implemented into cvs. What still hasn't been done are:

• keyframe handle visualisation
• removing all duplicate code for shapekeys
• extending actions to be usable for all other ipo-types.

/Aligorith