In Chapter III, "Rigging the Red Ninja", bones were discussed largely within the context of Edit Mode and making a skeleton to articulate the mesh. For Chapter IV this changes to a discussion about animation and Pose Mode and how bones are manipulated using the "Action Editor" to produce motion sequences, in this instance a simple walk cycle.
Although ostensibly for game-related content, the following is broadly applicable in different contexts and for other types of animated item or object, not just characters and things that have limbs, as the principles and general procedures are much the same - mesh, rig, animate!.
Design note: although certain aspects of the rigging and animation process can be discussed using the proper technical terms (the 'names' professionals commonly use), for sake of clearly explaining the principles and process involved, they are largely omitted in the text below.
Before making a start animated the character, the overall model should prepared for use, in particular the two halves can be joined together forming a single unified object. First however, ensure the Origin of Armature and meshes are properly established relative to the central point of the grid floor, "0,0,0"; right-click select each half of the character in turn and check their respective "Location:" coordinates in (View) Properties, "N", read as "0.00000". Next check the "Scale:" values for each Object is similarly set to "0.00000", with "Rotation:" set at "0°" (cf. illus. 1).
Once positional data is corrected as needed, to join the two halves together, in Object Mode "Shift+RMB" multi-select both sides, the original selected last so it becomes the active object, and from the "Object" menu in the 3D View Header left-click "Join" ("Object » Join" or "Ctrl+J"). Immediately upon doing this the mesh will change to be outlined a uniform pale-orange confirming the action and the halves being joined together.
Design note: when selecting multiple object the active element is typically outlined a brighter colour, by default a lighter or paler orange (more saturated tone of orange).
Next, with the new object selected "Tab" in Edit Mode and press "A" to select everything (may need to be done twice, once to clear previous selections, then again to re-select all). In the "Tools" panel of the Tool Shelf, scroll down to the "Remove:" subsection and left-click the "Remove Doubles" button. This unifies the mesh by removing duplicate vertices along the centre edge-loop where the two halves meet, making it ready for animation (cf. illus. 2).
Design note: duplicate vertices along the centre-line need to be removed to prevent the character breaking apart when articulated - in their raw state each side might be influenced by a different bone, causing a disparity. Merging alleviates this by unifying the structure and influence bones then have over the area.
[illustration 1] before animating the character the two halves need to be joined to form a single mesh to avoid deformation problems - right-click select both and from the "Object" menu select "Join" [29_cubie.blend] ...
[illustration 2] ... then in Edit Mode, select the entire mesh ("A") and "Remove Doubles" to full unify the structure, removing the duplicate vertices around the centre edge-loop [29a_cubie.blend]
Like other aspects of the characters development, animation has its own dedicated editing 'mode', "Pose Mode", wherein the rigged character is posed and captured as a series of static frames that, strung together, form an animated sequence. Unlike other editing modes however, Pose Mode places particular restrictions on bone articulation, largely due to the Parent » Child relationships established between bones during rig construction. For example, where bones are connected to each other, but not positioned last in a bone-chain, their movement will be limited to the Head node of the Parent bone above in the hierarchy (cf. illus. 6) - they will rotate around that particular point regardless of the 'transform' action used (scale, rotate, move). On the other hand disconnected bones, and those positioned at the end of bone-chains, can move with relative freedom, similar to bone behaviour seen in Edit Mode (cf. illus. 7 - 9).
Design note: bone relationships over-ride selection bias, in other words unlike Edit Mode, depending upon the position of a bone in a chain, and whether its connect to others above or below in the hierarchy, transform actions will largely ignore what 'Pivot Center' is set as the general point of focus for manipulating Objects in the 3D View - bones rotate by default relative to the Head node (cf. illus. 3), the point highlighted by the Manipulator Widget when a bone is selected, unless the bone terminates a chain, or is solitary, in which case rotation and scale operations will focus around the global 'Pivot' point set in the 3D Views Header (cf. illus. 4).
[illustration 3 & 4] in Pose Mode the global "Pivot" point setting is ignored in favour of the selected bones Head node (image top), unless the bone is solitary, or the terminal of a chain (image bottom) - applies to rotation and scale operations, transform (move) ignores the pivot universally unless bones are connected to one another
Pose Mode also limits the way bones can be manipulated as selectable items. In Edit Mode for instance, a bones (sub)elements, the Head and Tail nodes in particular, can be selected and moved independently of the bone as a unit, whereas in Pose Mode the Head and Tail nodes are always included.
Design note: in Edit Mode bones move freely but in doing so also change the shape of other bones as might be connected above or below (cf. illus. 5). In Pose Mode bones are anchored based on their relationship with one another and the pivot point of the active item, moving one moves all (cf. illus. 6 & 7).
[illustration 5] in Edit Mode only selected bones can be fully manipulated, else they have limited or partial affect over other elements of the structure, i.e. manipulating a bone makes changes to neighbouring bones only so far as the next (unselected) fixed Head and/or Tail node (connection) ...
[illustration 6] ... whereas in Pose Mode bones move relative to selection and the Child » Parent relationship - bones lower down the hierarchy than a selection bone will move whereas those above, won't (notwithstanding IK chain properties)
[illustration 7] the basic different in bone behaviour between Edit Mode and Pose Mode - in Pose Mode manipulation focuses on the selected bone, in Edit Mode bones either side of a selection limit movement. In other words bone use, articulation and the tools available in Pose Mode are essentially relative to motion capture in contrast to Edit Mode and forming structure
There is an exception to this however, Inverse Kinematics. When this bone-based property is assigned in Pose Mode, the default behaviour described above can be inverted, the normal "Parent » Child" relationship between bones changes to "Child » Parent" essentially reversing the pivot point and articulation of individual bones and bone chains without needing to alter the Armatures underlying structure in Edit Mode. For character animation this is particularly useful as it allows limb control from the outside in (from foot or hands etc.) rather than inside outwards (cf. illus. 8 - 11).
Design note: a bone chain assigned an Inverse Kinematics property will move freely when "Grab/Move" ("G") is active on the selected bone, pivoting around the terminal bones Head node (or freely if set as the terminal bone in a chain). "Scale" ("S") and "Rotate" ("R") however typically only act upon the bone selected and its Children, the behaviour of these operands is largely unaffected by the use of IK.
[illustration 8] the arm bone chain with IK property assigned to the hand - the relationship between bones affects how they move, connected bones (node highlighted green) typically move as a unit when the hand is manipulated, whereas detached nodes (highlighted red) generally don't (unless the IK overrides this default behaviour) [29b_cubie.blend]
[illustration 9] how bones articulate when "Grab/Move" is activated, the range and direction is determined by their respective relationship and whether the IK assigned to the hand overrides this
[illustration 10] how bones articulate using "Rotate" - range and orientation is again limited relative to bone selected. IK has no affect
[illustration 11] how bones change using "Scale" - degree of change differs relative to bone selection. IK has no affect
Animation is about creating a sense of movement, that objects are alive or perhaps responding to something, a simple lamp fall from a table for example, or a complex multi-legged creature running, and so on. Whatever the impression they all tend to be created the same way, by capturing snapshots of an object variously posed over time in a linear sequence that can then be (re)played like a recording. Some may be a few seconds long, others dozens, hundreds or thousands (cf.. illus. 12 - 14).
Design note: if an object is being animated by an Armature that articulates (with or without Inverse Kinematics), the same principles apply to production no matter what the sequence is meant to represent (notwithstanding movement based on simple object positioning that doesn't require the use of an underlying articulated skeleton, i.e., the object can be moved independently of its Armature).
In principle generating animated actions is relatively straightforward, the challenge to a large degree, is in the fidelity of the end result, how convincing it is to the viewer, rather than the apparent complexities of the process, much of which can be broken down in to a series of passes where ever more refined adjustments are made to the Scene. Applied to the Red Ninjas walk cycle for example, a first pass might establish the actions length and mark out the major extremes of each pose, second pass might add intermediary positions and poses, with third and subsequent passes fine-tuning previous additions and adjustments to make sure everything transitions smoothly.
Design note: the number of passes used per sequence depends on the complexity of the animation, but should be kept to a minimum to keep the process manageable.
The core elements of the animation process overall then are as follows;
"Timeline" the Editor used to manage all the data associated with a given animation.
"Duration" the length of a given animation measured in second/minutes/etc.
"Pose" a 'snapshot' of the object at various points during an action.
"Keyframe" the position at which a "Pose" is marked, noted or saved to the "Timeline".
"Tween" an automated transition between "Pose" points ("Keyframes").
[illustration 12 - 14] (top) the overall Scene showing the completed character with rig in the 3D View and animation sequence in timeline underneath, (middle) then the basic breakdown of the timeline and the parts that go into making an animation using the approach described in the main text, (bottom) and the Armature shown in "Pose Mode" and the basic components of the skeleton
Most game-related animation is simplest created in the "Action Editor", a sub-editor of another primary editor, the "Dope Sheet". Here character poses created in the 3D View are captured and marked to an "Action" sequence, one marker per bone. Along the horizontal a collection of pose markers represents 'time', vertically they represent a 'frame' (or given pose).
Design note: animations can be generated using a number of different Editors in Blender, although the Action Editor tends to suffice for most sequence production because the underlying data structures aren't specifically what's being manipulated, the Armature is. In other words, most work is performed in the 3D View posing the character, the Action Editor then essentially acting the manage and edited the resulting sequence and markers.
To display the "Action Editor"; in the "Timeline" area below the 3D View, left-click the "Current editor type for this area" button to the far-left of the Header and select "Dope Sheet" from the list of options (cf. illus. 16). Once the "Dope Sheet" accessible, left-click the "Editing context being displayed" button to the right of the text-menu options in its Header and select "Action Editor" from the available "Mode" options. The view will again change to display another timeline variation. This is the "Action Editor" (cf. illus. 17), it comprises largely; a list of bone channels on the left; on the right the main workspace in the form of an adjustable timeline; and a green linear widget or frame marker ('scrubber' or 'slider') indicating the active frame (cf. illus. 18).
Design note: like most 'views', the "Action Editor" has a Header that contains a series of buttons, menus and other quick-access options. The editor is also controlled much the same way as other editors using the standard "Transform" operands ("Move/Rotate/Scale" - although 'Rotate' in this context performs a different function than normal) to move and manipulate bone/pose markers, and middle-mouse button in conjunction with "Ctrl" being used to manipulate the view itself (cf. illus. 15).
[illustration 15] elements of the "Action Editor" typically used for sequence production, the "Create new action" ("+ New") and the "Copy selected keyframes..." and "Paste selected keyframes..." (copy/paste) buttons (the Header is shown 'flipped' to the top of the Editor for ease of access - right-click the Header and select "Flip to Top"), and the green 'scrubber' shown at frame "1" in the timeline
[illustration 16] switching the "Timeline Editor" to the "Dope Sheet" editor [30a1_cubie.blend] ...
[illustration 17] ... where the "Action Editor" can be found in the "Editing Context..." option in the "Dope Sheet" Header [30a2_cubie.blend]
[illustration 18] close-up of the Action Editor showing the timeline with bone 'channels' listed on the left  and various pose markers  in the timeline indicating locations 'pose data' is held, which also correspond to a specific frame  when taking other nodes into account along the vertical  (nodes immediately above and below a specific marker)
With the "Action Editor" visible an initial frame can be establish by posing the character in the 3D View and capturing it in the timeline as a 'key' frame (a "keyframe"). The process can then be repeated a number of times to generate a sequence, each pose representing different aspects of the characters progress through the 'walk' action. With this in mind the first step is to block-out the main positions, the start, middle and end frames.
Design note: the number of frames required per sequence varies depending upon the complexity of the action being recorded, a standard walk cycle might only require six or so key frame, whereas picking up an object from the ground might use twelve or more because the action has to include subtler movement. It's also not specifically necessary to 'key' all frames within a sequence.
To get started, in the Action Editors timeline, left-click at, or left-click+drag the green slider widget to, frame "1" (if not already positioned there by default). Release to confirm. This sets the active frame to which a pose will be captured (cf. illus. 21). In the 3D View click the "View" menu option in the Header and select "Right" (or press "NumPad 3") then again selecting "View Persp/Ortho" (or press "NumPad 5") to flatten the Scene. Reposition the character where necessary so the entire object is visible centre-screen (cf. illus. 22).
Design note: the 'scrubber' widgets location in the timeline determines the active frame to which pose data is saved/baked. It can be moved an number of ways; left-click positions it at the cursor; left-click+drag will 'scrub' (move) the indicator back and forth/into position. On flattening the view: using orthogonal display modes ensures bones remain perpendicular to the view, that bones are manipulating along a single axis/plain thus limiting the likelihood of misalignment due to the presence of perspective - a majority of Armature posing is carried out this way, using the various "Orthogonal" views, for this reason.
To set the first pose right-click select theleft foot bone (bone immediately visible to the viewer). When the manipulator widget appears left-click on the central circular orbit (white outline) and drag the mouse forwards. The entire leg will move, its direction controlled by the selected (active) foot. Position the bone forward of its original position, angled so the entire leg forms one arm of an inverted "V", i.e., "/". Release to confirm and fix in place.
Design note: when using the orthogonal views care should be taken to ensure the correct bone is selected relative to the views orientation; seen from the side bones typically overlap so right-click select may not highlight the desired item, for example right-clicking the 'foot' might select the back-foot bone (furthest from the screen - the characters 'right' foot in this instance) when the intention was to select the front-foot bone (closest to the screen - the characters 'left' foot in this instance), or vice versa (cf. illus. 19). To address this proximity-selection issue, Blender automatically 'drills-down' through the view where multiple selections are possible (selectable 'layers'), highlighting each relevant object in turn until the actual item needed highlights. On using the selection orbit: once an item is highlighted, instead of using the blue and green widget handles separately, the inner circular orbit outline (white) can be used to move the bone along both (multiple) axes at the same time. For posing this is useful as it lets bones react more naturally to their being manipulated as a group rather than individually (cf. illus. 20).
[illustration 19] item selection in the Orthogonal views can be tricky where similar/same items are essentially stacked on top of one another (relative to the screen). Blender solves this by 'drilling-down' through the items highlighting each in-turn - shown, the left foot is in front, to select the right foot (behind), right-click twice
[illustration 20] multi-axes widget orbit/manipulation circle - be sure to clink on or immediately around the outline to ensure the action moves the widget instead of reposition the cursor (this particular style of movement/action is typically initiated pressing "G", i.e., 'free translate')
To capture this change to the Action Editors timeline, in the 3D View Header left-click the "Pose" menu option then select "Animation » Insert Keyframe...". The "Insert Keyframe Menu" appears. Left-click "LocRot" (cf. illus. 23). An orange marker appears in the timeline at the frame set by the slider. Repeat for the right foot except orientate the leg backwards to create the opposing aspect of the upturned "V", i.e., "\" - right-click select the right foot bone then left-click drag the 3D widget multi-axis orbit to pull the leg backwards. Release to confirm then using the shortcut "Insert" a new keyframe pressing "I", again selecting "LocRot" from the options (cf. illus. 24). Once set the two legs now resemble the upturned "V", i.e. "/\".
Design note: capturing "LocRot" pose data, that is the coordinates for a given bones "Location" and "Rotation", is a minimum requirement - although "LocRotScale" can be used,"Location", "Rotation" and "Scale", the latter, "Scale", is often ignored in favour of proprietor systems that are better able to dynamically size objects. In this regard its generally best practice to model at scale (1:1), the size at which the model will actually be used.
Before continuing, expand the Action Editor area by hovering the mouse cursor over the "area-border" divide between it and the 3D View, when the double-headed arrow appears left-click drag upwards to increase the editors height (increase the Action Editor, decrease the 3D View). Release to confirm (cf. illus. 25).
Design note: generally optional, adjusting views tends to make it easier to see what's going on, as more bones are posed, and more data added to the timeline, being able to see an over-view at a glance aids production.
Looking at the contents of the timeline two bone "Channels" are shown to the left, one titled "foot.L" the other "foot.R". Each carries a single frame/pose marker in the form of an orange diamond at frame "1" indicating the frame contains pose data.
Design note: frame markers appear orange when selected, and an off-white colour when unselected (in both states outlined in black).
At this point even though a pose has been made, if the timeline slider is moved it will be lost because by default "Insert" only marks actively selected items, the data associated with the auto-posed upper and lower leg bones was not included in the operation as they were not part of the selection group. To fix this, "Shift+RMB" multi-select the upper and lower leg bones belonging to both legs and press "I" to "Insert" the groups "LocRot" data (cf. illus. 26). Once done, if the timeline slider is now moved, the pose remains fixed in place.
Design note: by default "Insert" is selection based, only the highlighted bones are captured and marked to the timeline, omitted bone then have to be manually (re)selected and inserted into the timeline/included.
[illustration 21] to insert the initial pose data, position the timeline widget to frame "1" - the widget can be moved or repositioned by left-clicking anywhere in the area, or by left-click dragging it left/right (release confirms). It automatically snaps to the frame by default
[illustration 22] switch view to "Right" ortho ("NumPad 3") and toggle out of perspective mode, this flattens the scene making it easier to pose bones on a single axis/plain (ensuring manipulation remains/is perpendicular to the view) [30b_cubie.blend]
[illustration 23] manually inserting a bones 'pose' as a keyframe in the timeline - select the bone, pose it then press "I" (whilst mouse is over the 3D View), select "LocRot" ("Location" and "Rotation" coordinates) from the available options [30c_cubie.blend - note: pose data is marked in source to retain position of bone even though its not shown as such above]
[illustration 24] using IK positioning bones is considerably easier - shown the 'opposing leg' is being positioned, marking an initial 'pose' to the Action Editors timeline [30d_cubie.blend]
[illustration 25] expanding the Action Editor so more of the data is visible (in the timeline in particular) - move the mouse over the border between the Action Editor and 3D View until the double-headed arrow appears. Left-click drag to move. Release confirms the change [30e_cubie.blend]
[illustration 26] "Shift+ RMB" multi-select other bones that have been moved or moved as a result of another manipulation and mark the group to the timeline - each bone has a 'channel' and associated marker in the timeline where the keyframe is set (channels highlight with white text when bones are selected in the 3D View) [30f_cubie.blend]
As highlighted in the previous section, manipulating bones assigned an Inverse Kinematics property often means having to (re)select secondary auto-posed bones after-the-fact to be specifically keyed into the Action Editor timeline. To address this and make the process less repetitive and time-consuming, pose markers can be automatically inserted into the Action Editors timeline by activating the "Automatic keyframe insertion for Objects and Bones" ("Auto-Insert") feature. Once enabled pose data is automatically captured live, typically after mouse release or other confirming action.
Design note: confirmation actions include left/middle/right mouse button releases, left/middle/right mouse-clicks, or key presses, e.g. "Enter".
To enable 'auto-insert' first switch back to the "Timeline" Editor by selecting that option from the "Current editor type for this area" list (cf. illus. 27). In the Header of the Timeline Editor left-click the red 'record' button ("Automatic keyframe insertion for Objects and Bones") to activate the feature then check the "Type of keyframes to create when inserting keyframes" option is set to "Keyframe" (if not left-click the orange icon and select "Keyframe" from the list) [cf. illus. 28]. Next, left-click the "Active Keying Set used to insert/delete Keyframes" input field and select "LocRot" from the list of options that appears [cf. illus. 29]. Finally, to make sure only the selected dataset ("LocRot") is marked to the timeline left-click the "Automatic keyframe insertion using Active Keying Set only" button [cf. illus. 30]. Once auto-insert is set up, switch back to the Action Editor selecting "Dope Sheet" from the "Current editor type for this area" button in the Header.
Design note: when switching between the Timeline Editor and the Action Editor, the latter will be available upon selecting "Dope Sheet" because it was the editor in use before changing (if not available simply select "Action Editor" from the "Editing context being displayed" menu). Although the system underlying the auto-insert feature is available for use within all 'animation' or other 'sequence' editors once set up - data can be automatically captured - it's not (currently) directly accessible other than through the Timeline Editor.
[illustration 27] the 'auto-insert' feature controls; the 'record' button to activate, the 'style' of data to be saved and the type to be saved; can only be accessed from the "Timeline" Editor [30f2_cubie.blend]
[illustration 28] left-click the orange "Type of keyframes to create when inserting keyframes" icon to select "Keyframe" from the "New Keyframe Type" options (default) - this sets the 'type' of data to be inserted in terms of a 'group' type (operates semi independently of other settings) [30f3_cubie.blend]
[illustration 29] left-click the "Active Keying Set used to insert/delete Keyframes" input field and selected "LocRot" (Location" and "Rotation" data) from the list of options to set the type of data being saved in terms of a dataset, i.e. the type of data being saved, i.e. coordinate, position, etc.
[illustration 30] when auto-insert is active "Automatic keyframe insertion using Active Keying Set only" then become available as an optional setting; activating this forces captured data to only include those of the selected dataset, i.e. "LocRot" only [30g_cubie.blend]
For Blender 2.77 and below: To enable auto-insert for Blender 2.77 or below, switch the Action Editor back to the Timeline Editor by selecting that option from the "Current editor type for this area" list (cf. illus. 31). With the editor visible left-click the 'record' button to the far right of the Timeline Editors Header. To ensure Blender captures the correct data type associated with posing the Armature, left-click the "Automatic keyframe insertion using active Keying Set only" button to the right of 'record' (appears after 'record' is turned on). Next left-click the "Active Keying Set used to insert/delete keyframes" input field (cf. illus. 32), and from the list of options that appear select "LocRot" (which then occupies the input field) (cf. illus. 33). Once enabled and set up, switch back to the Action Editor selecting "Dope Sheet" from the "Current editor type for this area" button in the Header.
[illustration 31] although "Automatic Keyframe Insertion..." ('auto-record') is available for use in the Action Editor it can only be (de)activated from within the "Timeline" Editor - switching back using the "Editor Type" selector , left-click the red 'record' button  in the Header to enable the feature (and access to other useful settings) 
[illustration 32 & 33] once "Automatic Keyframe Insertion..." is activated left-click the input field to set the data-type to be saved, in this instance "LocRot"  ("Location" and "Rotation" data). To ensure only LocRot data is saved left-click the "Key type only" button 
With the legs initial pose roughed in, the arms can be set. First switch the 3D View to "Front" Ortho, "NumPad 1" (or "View » Front"), then right-click each hand bone in turn and again using the multi-axis orbit of the manipulator widget, left-click drag the bones down to the floor (which the finger tips can touch for now). Release to set in place (cf. illus. 34) - with "Automatic Keyframe insert..." enabled the new bone positions are marked to the timeline without the need to manually press "I". This takes the character fully out of its original "T" pose, the arms in a better 'starting pose'.
Design note: if the multi-axis orbit of the transform widget is difficult to select and manipulate, fall back to using the standard "X", "Y" and "Z" axis handles to move a selection(s) into position.
Once set press "NumPad 3" to switch back to "Right" side view noting which of the two arms was last edited; if the leg on the same side as the selected hand is in a forward position, left-click drag the widget orbit of the hand bone to move the arm back; if in the leg was in a backward position move the arm forward (cf. illus 35). The result produces another inverted "V" shape that's in opposition to the that formed by the legs, completing the initial pose block-out (cf. illus 36).
Design note: to aid positioning the arms in opposition to the legs press "NumPad 5" to toggle "Ortho/Persp" ("Perspective") to temporarily view the mesh, this allows for better assessment of the pose - the arm and leg on the same side of the body should form an "/\", the left and right side then being in opposition.
[illustration 34] with "Automatic Keyframe insertion..." enabled, moving the hands inserts a collection of bone channels and pose markers for the whole arm into the timeline (if the IK is moved, chained bones also move and will be marked) [30h_cubie.blend]
[illustration 35 & 36] hand bone is posed so the arm is in opposition to the leg on the same side, a position that acts as a natural counterbalance to the actions shifting weight and momentum - leg forward/arm back, arm forward/leg back [30i_cubie.blend]
A walk cycle typically needs three frames to be initially marked, each accounting for a different aspect of the stride; a 'start', a 'middle' and an 'end', that is the character is posed to start with its right-foot forward, switching to the left-foot forward at the mid-point, returning to right-foot forward again at the end (or vice versa). For the sequence to loop cleanly, the return - right-left-right - is needed else the character appears to skip rather than walk. And to avoid inconsistencies at the 'end/start' transition where the sequence repeats, both frames need to be the same, which requires the initial frame (start) be copied to the last (end). This is usually done using "Duplicate".
Design note: used within the context of Action Editor and/or Pose Mode being active, "Duplicate" is essentially a simple copy and paste function that results a set of uniquely identifiable objects or blocks of data (datablocks) able to be edited independently of the source/their origin - the data is not linked so editing one has no effect on the other.
There are two approaches to copying data when animating (using the Action Editor and/or Pose Mode); by either copying a pose (a single bone or whole pose), or copying timeline markers (individual markers or groups). In either instance the same fundamental bone related coordinate data is represented by the duplication.
Design note: the data being copied is essentially coordinate information so it can be represented and manipulated in a number of ways depending upon context, this is why/how copying a pose and/or markers produce the same end result, a duplication.
To copy a pose; in the 3D View "Shift+RMB" the bones to be copied then in the "Pose" menu of the 3D View, left-click "Copy Pose" ("Pose » Copy Pose" - cf. illus. 39). Once in the pose buffer (memory) the data can be pasted to another frame, for example left-click the timeline at frame "30" relocating slider (or left-click drag), left-click the "Pose" menu option in the 3D View Header this time select "Paste Pose" ("Pose » Paste Pose"). A new set of markers immediately appear in the timeline at the selected frame (cf. illus. 40), highlighted by an orange bar between old and new indicating the two sets of data are the same, a 'duplication'. This then establishes both the 'start' and 'end' points of the sequence using the same basic pose information.
Design note: bone selection can be done using "Shift+RMB" for simple multi-selections, "Ctrl+LMB" to draw a selection lasso around objects (cf. illus. 37), or "B" and "C" to make "Border" and "Circle" selection. In all instances toggling between "Orthogonal" and "Perspective" display modes helps select the necessary bones where using a 'block' or other 'group' selection picks up other unwanted bones. Alternatively, use "A" to select everything before copying the pose (this may need to be used twice, once to clear current selections then again to reselect all). When copying pose data, Blender marks the timeline with an orange bar (cf. illus. 38)between markers to indicate there is no difference between the two (see above).
[illustration 37] use "Ctrl+LMB" to draw an area around a selection using the mouse to "Lasso" select as quicker, or alternative, to using "Shift+RMB" to multi-select several bones, or "B" to "Border" (or "Box") or "C" to "Circle" (or "Paint") select items
[illustration 38] an orange bar between frames indicates there are no difference between the two (typically holding 'duplicate' pose data) - this appears wherever this is the case and can run across several frames
[illustration 39] multi-selecting bones ("Shift+RMB" et al) and copying (alternatively "Ctrl+C") their respective pose data to the temporary pose/data-buffer... [30i_cubie.blend]
[illustration 40] ... which is then pasted (alternatively "Ctrl+V") to new frame creating two identical frames at sequence start and end (frame 'duplicates') [30j_cubie.blend]
For the mid-point, frame "15", the characters limbs are reversed so the left-foot currently leading the stride at frames "1" and "30" is swapped for the right-foot, with the right 'back-foot' swapped for the left - that's right-foot forward, left-foot back instead of left-foot forward, right-foot back.
Design note: the 'left' foot/leg is established as the front-foot simply because the Scene is orientated so the character faces left when viewed in "Right" Ortho ("NumPad 3") - the left-side of the character is dominant; If the character faces a different direction (based on deign established during construction) it might mean the right-foot leading instead. Beyond this there are no particular reasons for one side or limb taking precedence over the other except perhaps as a consequence of personal preference.
To do this, first left-click the timeline at "15" setting the active frame (cf. illus. 44). Next, in the 3D View right-click select the left foot bone then left-click drag the multi-axis widget control as before (the white circle), repositioning the foot under the back half of the character. Release to confirm. Similarly grab the right foot and reposition this under the front half of the mesh. Release to confirm. In both instances with Auto-Insert enabled the appropriate bones will be marked to the timeline (cf. illus. 45).
Design note: to make frame selection or reposition the slider easier, press the "Home" key, or alternatively in the Action Editors Header click "View" then "View All" ("View » View All"), to focus on the extents of the active sequence (cf. illus. 41).
[illustration 41 to make frame selection and/or manipulating the timeline slider/widget easier, 'zoom' into the sequence by selecting "View All" from the "View" menu option in the Action Editor's Header ("View » View All"), or press the "Home" key
Once the legs have been posed, the arms need to be similarly treated so right-click select the right-hand bone and left-click drag the widgets multi-axis control, pulling the bone and arm backwards. Release to confirm. Then repeat for the left-hand, instead moving this forward. Release to confirm, completing the reversed pose (cf. illus. 46). Playing the sequence now to check progress the characters arms and legs swing back and forth, albeit robotically (cf. illus. 47 & 48).
Design note: playing through the sequence now means running though the default 'range' set by Blender, i.e. 250 frames, the default length value attributed to sequences, before automatically looping the sequence. To adjust this so only the necessary frames are played, in this instance "30", left-click the "Render" Properties button and in "Frame Range:" set the "End Frame:" value to "30" by double-(left) clicking the input box and typing the value (or left-click drag within the input to 'drag' the value lower). Press "Enter" to confirm. When playback is then started with the correction, the sequence loops as it should, frames 1 - 30 (cf. illus. 42 & 43).
[illustration 42 & 43] when initially created Actions are 250 frames long (image top). As a result shorter animations will appear to stop when played as the unused frames are run though before Blender loops back for replay. This can be fixed in "Render" properties by adjusting the "End Frame:" value to match the actual sequence length, "30" in this instance (image bottom)
[illustration 44 & 45] at frame 15, sequence mid-point, the start/end pose is reversed so the front leg becomes the back and vice versa; select each bone in turn and manipulate into position (from "Right" orthogonal) - auto-insert marks the new positions to the timeline, which also removes the orange data duplication highlights between frames (frames no longer the same) [30l_cubie.blend]
[illustration 46 - 48] the arms are similarly 'inverted' to reflect the pose essentially being in opposition to the start and end frames - on the left side, with the leg back the arm is posed towards the front, and vice versa for the right side - right leg front, right arm back (second image above shown in perspective for clarity) [30m_cubie.blend]
With the base frames established the first pass can be completed by adding a bobbing motion, a height adjustment that takes into account pose differences as the legs pass under the character and extend outwards to complete the stride. In practice this means altering current poses, and marking some intermediary keyframes to the timeline.
Design note: although the bob is being include here, it can be added at any point because it only requires a relatively minor modification to the characters position compared to other aspects of the sequence/pose.
To do this, in the timeline left-click at frame "8" positioning the slider widget (or left-click drag). In the 3D View right-click select the "torso" bone and press "I" to automatically insert the "LocRot" keyframe data (the bone hasn't been moved, just the keyframe inserted). A new set of markers appear in the timeline. Left-click the timeline again or move the slider to frame "23" and repeat the process - with the "torso" bone selected press "I" to auto-insert a keyframe (cf. illus. 50). This establishes two new frames for the torso bone in between those already established.
Design note: pressing "I" when auto-insert is active automatically inserts the 'key-set' data previously defined when establishing auto-keyframing, in this case "LocRot", without it the normal process would be used, i.e., selecting the 'type' of data to insert from the keyframe pop-up menu. If the necessary bone for marking is not easily selectable, in the "Outliner" Editor left-click the appropriate bone from within "Pose", in this instance "torso" (cf. illus. 49), which may also require left-clicking the small "+" to expand the hierarchy.
[illustration 49] an alternative way to select bones is to use the "Outliner" Editor whilst Pose Mode is active - this negates the need to constantly re-orientating the model in the 3D View just to make a selection (often of a single bone)
Next, with "torso" still selected, move the timeline slider to frame "30" then in the 3D View left-click drag the blue handle of the widget down moving the bone with it until the heel of the characters front-foot touches the ground. Release to confirm. This sets the initial 'low' point of the sequence at the strides extended position. Once done, and with the torso bone still selected, left-click the "Copies the current pose of the selected bones to the copy/paste buffer" button in the 3D Views Header to 'copy' the pose, move the timeline slider to frame "15" and click the "Paste the stored pose on to the current pose" button to 'paste' the same (stored) pose data to the selected (different) frame (cf. illus. 51). The bone adjusts which automatically places a marker in the timeline. Finally move the slider to the frame "1" and again left-click 'paste' to modify the selected frame with the stored pose data. Another marker appears in the timeline. If the sequence is then replayed, the character will bob up and down as the legs swing back and fourth due to the difference in height now set (cf. illus. 52).
Design note: when lowering the torso bone the 'toe' of the back-foot is likely already in contact with the ground and will buried further as a result. This can be ignored for the time-being as it will be corrected in a later stage.
[illustration 50] setting two new intermediary poses,  & , and creating the upper limit or apex of the characters height as it moves through the different pose positions (frames) relative to the legs [30n_cubie.blend]
[illustration 51] inserting an updated pose at a previously defined frame to set the 'bob' low points ( & ) - if the selected bone had a marker already present, making these new adjustment will overwrite the data, storing new positional values [31_cubie.blend]
[illustration 52] the results of adding a 'bob' to the character
At this point the animation is functional but not particularly convincing, the measured way the arms and legs swing back and fourth make it appear relatively lifeless and robotic. To lessen this effect the sequence needs to be more relaxed to better reflect the way the body shifts and transfer weight as it moves.
Design note: accounting for momentum, how weight transfer effects movement, makes all the difference when animation - the body cannot twist, turn and articulate without each action having an opposite that compensates for, or acts as a counter-balance to, the activity being performed/represented.
Taking a closer look at the sequence, the reason it doesn't look as convincing as it possibly could relates to the way the primary poses make the arms, and in particular legs, appear to slide back and forth rather follow a more natural cyclical pattern. In other words, instead of gliding along the ground, the feet should lift to clear the horizontal before being placed ahead to form a loosely circular action. First, flatten the leading foot.
Design note: one foot, either left or right as appropriate, is always in contact with the ground at any given time as the action cycles through. And assuming a typical walk motion, the feet traverse a squashed ovoid shape as the foot is planted on the ground in front and then lifted as the stride extends to its limit at the rear - stride distance is usually defined by the maximum stretch of the inverted "V" ("/\") and modified 'backwards' as required of the pose, i.e., limbs are initially posed at their extremes and pulled back (made less severe) so each pose makes sense relative to the motion being represented (cf. illus. 53).
[illustration 53] for a typical 'walk' action limbs more naturally articulate along an ovaloid path rather than sliding back and forth between end points
Left-click the timeline at frame "5" then right-click select the 'foot' bone currently leading the pose (front-foot), "foot.L". Press "R" and moving the mouse rotate the bone so the mesh section corresponding to "foot.L" runs parallel with the ground. Left-click to confirm (cf. illus. 54).
Design note: use the mesh to guide placement of the characters foot rather than the bone which, due to its original position, will be angled relative to the floor regardless. In "Right" orthogonal view ("NumPad 3"), rotate spins around the "X" axis, which is perpendicular to the screen (projects outwards) - in perspective mode the axis of rotation would be locked pressing "X" (unless the rotate widget is used). This is one of the more practical reasons for using orthogonal views when manipulating bones, it restricts movement to a given axis or orientation.
Next reposition (left-click) the timeline widget at frame "19" and right-click the other foot, "foot.R", now leading the pose. Press "R" and similarly rotate the bone so the underside of the corresponding mesh section runs parallel with the ground. Left-click to confirm. Once set left-click drag the timeline widget back and forth to check how the sequence now plays with the new adjustments, essentially the feet should flop down at the adjusted frames giving the appearance of contact with the ground (cf. illus. 55).
if auto-insert is not active see here to enable, or press "I" to "Insert" the selected bones "LocRot" data.
Moving through the sequence, although the foot flattens as it makes contact with the ground, the new position doesn't carry through to subsequent frames because the bones remain orientated relative to the initial pose. As a result it needs further adjustment to match the initial pose, the feet being flat across a number of other frames.
Design note: bones orientate themselves relative to "Parent » Child" relationships rather than the environment (absent other influence), the foot bone for example might rest at [n]° (e.g. 60°) to the lower leg bone and [y]° (e.g. 20°) to the ground plain, when the former moves the foot retains its [n]° position with the Parent bone whilst changing [y]° relative to the ground by virtue of the bone having moved in relation to it (cf. illus. 56 & 57).
Right-click "foot.L" again and move the timeline widget back to frame "5", before slowly dragging it to frame "8" - as this is done the foot can be seen to dip below the horizontal. Leave the widget at frame "8", press "R" and rotate the foot into a parallel position with the ground as before. Left-click confirm. Repeat for "foot.R" at frames "19" and "23" - move the widget to frame "19" checking the bones position, then advance to "23" before pressing "R" and rotating the bone so the corresponding mesh section runs similarly parallel with the ground (cf. illus. 56 & 57). Playing the sequence now ("Alt+A" or left-click drag the timeline widget back and forth), the feet ostensibly remain flat relative to the ground as the stride progresses.
Design note: the adjustments made to the feet at this point correct their general (rotational) orientation relative to the ground rather than their proximity to it, as the sequence plays discrepancies will appear, these will be corrected later.
[illustration 54 & 55] at frame "5" and "19" respectively, each foot flattens in relation to the ground representing the initial impact point of the front foot during the stride [31b_cubie.blend]
[illustration 56 & 57] with the feet flattened at frames "5" and "19" they need to remain so through a number of frames, which may require some correction (distance from the ground is not important at this point, only that the feet should run parallel across several frames from initial 'impact' to 'lift') [31c_cubie.blend]
Continuing on. With the front-footcontact in place relative to the ground plane, the back-foot lift and return needs to be set so each clears the ground as they are brought forward to lead the stride again. Before modifying the pose left-click drag the timeline slider back and fourth to assess progress so far, pay particular attention to the back-foot and what its doing relative to the front-foot hitting the ground at frames "5" and "19", it's at these points adjustments are initially made to account for the characters (virtual) weight and momentum being transferred from one foot to the other just before the back-foot lifts from the ground.
Design note: if the foot did not lift it would drag along the ground, potentially tripping the owner. The action is also the manifestation of the continuation of momentum related to muscle behaviour, how they spring and tense as flesh and bone articulate (cf. illus. 58).
[illustration 58] when the foot travels through the cycle it angles relative to the loop which has it often pointed in slightly different directions as it progresses - so long as the key poses are placed the foot should naturally replicate the desired motion as a consequence of 'tweening' between key frames
With this in mind, left-click the timeline at "5" to set the active frame - the front-foot flat on the ground. Right-click the lower-leg bone of the back-foot, "legLwr.R", press "R" and move the mouse rotating the bone upward slightly to kink the leg at the knee enough to raise the foot so only the toes remain partially buried in the ground. Left-click to set in place (cf. illus. 59 & 60). Move the timeline slider to frame "19" and similarly right-click "legLwr.L", press "R" and rotate the bone upward to kink the knee. Left-click to confirm (cf. illus. 61 & 62).
Design note: the foot bones don't necessarily need to be adjusted, the modified leg bones should be sufficient for the time being.
Once done left-click drag the slider back and fourth scrubbing the sequence to check progress, the leg should 'kick' slightly on the back-foot as the stride cycles through before returning (cf. illus. 63).
Design note: press "NumPad 5" to toggle "Persp" mode when checking the sequence as this helps get a better sense of the Armatures articulation (press "NumPad 5" then "NumPad 3" to return to "Right" side view once done).
[illustration 59 & 60] move the timeline slider to frame "5", select the lower-right leg bone and using "R", rotate it upwards to kink the knee (and in doing so raising the foot from the ground) - a new marker will be placed automatically
[illustration 61 & 62] similarly for frame "19", position the slider, select the lower-leg and rotate to kink the knee and raise the foot [32_cubie.blend]
[illustration 63] the results of the modification up to this point in action
A final addition to make takes into account the general pitch, yaw and roll of the character. Here each pose is modified to give a sense of weight and how the body shifts to counter-balance particular aspects of the action; lifting a leg generally necessitates tilting the body in the opposite direction to compensate for the strain/weight transfer involved and so on. Without doing this movement can appear stiff at the very least because it doesn't deviate from what is otherwise then a linearly prescribed path ('tram-lines').
Design note: although including pitch, yaw and roll here produces a better walk cycle for the project, its addition can be considered an optional stylistic decision determined by character and/or game design requirements; in some instances a 'tram-line' like action may be desired because it serves a specific visual or game-play purpose, the Red Ninja for example, has short legs and long arms that require a greater degree of torso rotation and tilting to accommodate than might ordinarily be used (cf. illus. 64).
[illustration 64] the general position and short stubby nature of the Red Ninjas legs ("a)") limit the range of available motion possible from the character as it moves, so pitch, yaw and roll edits are often necessary as a compensatory measure (as would the case if the character were real, it would have to tilt, sway and roll so its arms could clear the ground and leg afford a reasonably long stride length relative to the body)
In this context, correcting or making adjustments that compensate for a specific action, pitch, yaw and roll, are global rather than local considerations. In other words, to compensate for the legs and arms swinging, both of which are localised actions, the entire torso is be moved, which affects the entire model. In practice this tends to mean changes being made to bones that have greater control over the entire mesh, "torso" in this instance, rather than those with lesser, e.g. "legUpper.L/.R" etc.
Design note: notwithstanding the note above concerning design there is a general expectation that objects behave as the End-User might expect them to, so in lifting a leg there is a general expectation the character would fall over were the body not to compensate.
First set the roll. To do this left-click the timeline at frame "5" to set the keyframe to be adjusted, then before continuing mouse over the 3D View, toggle "Persp(ective)" mode, "NumPad 5", and note which leg/foot is leading the pose (left) - this will be the initial bias towards which the character is to be manipulated. Once checked press "NumPad 5", "NumPad 1" toggling back into "Ortho(gonal)" and "Front" view.
Design note: it's not always possible to determine which side of the mesh the leading leg is on, toggling perspective helps in this regard (cf. illus 65).
[illustration 65] temporarily toggle perspective mode ("NumPad 5") to check which leg is the front-foot at frame "5" once the timeline slider is positioned - this is the initial bias towards which the character will lean and roll, and be the point at which it happens (as the characters foot hits the ground)
With the slider at frame "5", to set the new position right-click the "torso" bone, press "R" and roll the entire mesh a few degrees (5 or 10 degrees) to the side favouring the front-foot as determined above - when facing "Front" the characters left leg is on the right so rotate the "torso" bone to the right, the mesh will follow. Left-click to set in place (cf. illus. 66).
Design note: rotation should occur around the torso bones 'Head' node, the location of the manipulator widget. If not, check the "Pivot center..." is set to "Active Element". For absolute or precise placement, immediately after pressing "R" type a numerical value, e.g. "10", then left-click or press "Enter" to confirm. Alternatively, press "R" then hold down "Ctrl" whilst moving the mouse to engage rotational snap (5° increments). Left-click to set in place. When making adjustments, as 'torso' was used to set the 'bob' motion previously, data currently held will be updated upon pose modification, which may or may not also necessitate old keyframes having to be deleted and reinserted depending on the way the old pose data behaves with respect to the new.
Continuing, move the timeline slider to frame "19", the inverse pose to frame "5", and again with the "torso" bone selected press "R" and roll the bone to the opposite side (to the left) by the same amount (-5 or -10 degrees). Left-click to confirm or press "Enter" (cf. illus. 67).
Design note: typing negative values, i.e. "-10", rotates selections counter-clockwise (rolls to the left). Simply type "-" (minus/negative/hyphen character) and then the value needed, in this instance "10" - both 'minus/hyphen' to the right of "0" on the main keyboard, or top-right of the numerical keypad, perform the same function in this context, a 'negative' value. Standard numbers rotate clockwise to the right.
Next move the slider to frame "23", press "R" and type "-5" (or half the value used above), moving to the left by a lesser amount than before. Press "Enter" to confirm. Move the slider back to frame "8", press "R" once more and type "5", moving to the bone to the right. Press "Enter" to confirm. If the sequence is run now ("Alt+A") the character will roll left to right during the stride (cf. illus. 68).
Design note: with the 'bob' being previously established at frames "8" and "23", the updates at those same frames are necessary to over-ride the old pose data, allowing the roll to transition smoothly across multiple sets of keyframe.
Once the roll action is in place the same keyframe sets can be marked with a yaw (or twist) around the horizontal axis ("Z"), representing the body rotating to increase the stride length slightly.
Design note: as mentioned above, each set of the "pitch", "yaw" and "roll" actions is marked independently of the others, but not specifically in the order written.
To make adding the yaw/twist easier left-click the "View" menu option in the 3D View Header and select "Top", "View » Top" (or alternatively press "NumPad 7"). In the timeline left-click the at frame "5" (or drag the slider) then move the mouse back over the 3D View, press "R" and type "10" to rotate the "torso" bone clockwise towards the front-foot (looking down on the Scene the characters left foot will be on the right-hand side of the screen). Press "Enter" to set (cf. illus. 69). Repeat at frame "19" but type "-10" to rotate counter-clockwise; press "R" then type "-10" (negative "10"), press "Enter" to confirm.
Design note: as with "roll", "twist" also needs a greater and lesser angle of rotation to ensure the action transitions smoothly across a number of keyframe sets - if the values are too sever, the character moves too much, they can be adjusted later using the same basic formula; one set at full value, the other at half.
Repeat these steps at frames "8" and "23" using a lesser rotation value of "5" and "-5" respectively; left-click or position the slider, mouse over the 3D View and press "R", type "5" at frame "8" and "-5" at frame "23". Press "Enter" to confirm each change (cf. illus. 70). Once done play the sequence, or scrub the timeline slider back and forth, to see how the twist fits together with the roll to make the action appear more natural (cf. illus. 71).
Design note: although the aim is to produce a sequence that obeys much of the expected laws of motion, the end result will typically be an exaggeration of reality based on the specifics of the characters design, articulation, and the action (walk) being (re)produced.
At this point the animations core is done, the final step(s) is to go back over each keyframe, checking and clarify bone positions and the overall mesh so they sit on, or articulate relative to, the ground plain properly.
Design note: making the character 'pitch' (tilt forward/backwards) is largely optional for a standard walk cycle because there may be some degree of this naturally occurring as a consequence of the overall animation. It is useful for other actions however, if the character were to 'sneak', making it pitch back and fourth would be more appropriate as there is a more obvious shifting of weight front-to-back - forward/backward pitching is usually indicative of a person trying to lessen the impact of their stride/foot-falls, weight shifts more significantly to the back-foot to offset the front as it is placed.
[illustration 66 & 67] showing the tilt ( a "-10°" tilt anti-clockwise is shown) as the character strides along - each angle can be placed with precision by typing a value once "R" is pressed, initiating "Rotate" [33a, 33b & 33c_cubie.blend]
[illustration 68] sequence showing the animation with the 'tilt' in place making the character rock side-to-side gradually and slightly as it moves through the walk cycle
[illustration 69] switch to "Top" view ("NumPad 7") and with the "torso" bone still selected press "R" to rotate clockwise at frame "5" and anti-clockwise at frame "19" (type "10" and "-10" respectively) ... [33d_cubie.blend]
[illustration 70] ... then at frames "8" and "23" type "5" and "-5" respectively to rotate the bone a lesser amount, reducing the twist [33e_cubie.blend]
[illustration 71] sequence shown with twist in place, combined with the roll
With core pose data set, replaying the sequence now reveals the characters feet (and hands to a lesser extent) dipping below the horizontal (cf. illus. 72 & 73). A remnant of the previous pitch, yaw and roll adjustments, this problem can now be fixed altering those same bones. At frames "1", "15" and "30" then, the toes are buried too far into the ground so to fix this, left click the timeline at frame "1" then right-click "foot.R" (the 'back-foot'). Using the manipulator widget (or press "G" then "Z" to lock the axis), left-click drag the blue handle upwards raising the bone and mesh along with it until the 'big-toe' section is only partially buried. Release to confirm. Copy this new pose to frame "30" - "Shift+RMB" select the other leg bones on the right (same side as the bone just amended), click the "Copies the current pose..." button ("Ctrl+C") in the Header. Move the timeline slider to frame "30" then left-click the "Paste the stored pose..." button ("Ctrl+V") to drop the copied pose into the selected frame ensuring duplication. Move the slider to frame "15", right-click "foot.L" and using the widget, left-click drag the bone upwards until the 'big-toe' section of the mesh is similarly the only part buried in the ground. Release to confirm (cf. illus. 74).
Design note: when making these adjustments to the 'back-foot', the 'heal' of the 'front-foot' should also be partially buried in the ground indicating weight - right-click "foot.L/.R" and adjust using the manipulator so the heal section of the mesh is appropriately aligned with the ground when the foot fronts the stride.
Finally move the slider to frame "5" and "19", then "8" and "23" respectively to adjust the relative height of the "torso" bone to raise the entire character so the feet align properly with the ground - right-click select "torso" then left-click drag the widgets blue handle, moving the bone and mesh upwards a degree until the underside of the each foot stands correctly on the ground plain at their respective frames. Release to confirm each change. Playing the sequence back once this is done will have the characters stride better aligned to the horizontal plain (cf. illus. 75).
Design note: a degree of intersection with the ground may be desired to give a better impression of weight - when feet stand on the ground precisely the result can look odd despite being 'correct' in a technical sense. This can often be alleviated burying the feet by a small amount.
Once the feet have been fixed, using the same principle adjust the hands so they too are above the ground plain at all times - right-click "hand.L" and "hand.R" respectively and work through each keyframe making adjustments using the transform widget handles so the hands clear the ground and can swing freely.
Design note: ensure frames "1" and "30" are duplicates, this may mean correcting bone positions in one frame then copy/pasting to the other, for example select all the bones that have moved at frame "1", use "Ctrl+C" to copy, move the slider to frame "30" and use "Ctrl+V" to paste.
[illustration 72] adjusting bones displaced the character relative to the baseline so hands and feet drop below. With the 'pitch, yaw and roll' in place his can now be fixed
[illustration 73] sequence played through before adjustment highlighting the main issue that need to be addressed as a consequence of previous posing
[illustration 74] at frames "1", "15" and "30" ("30" is a duplicate of pose data at frame "1") the 'back-foot' can be raised slightly essentially leaving just the big-toe embedded in the ground - this is done by adjusting the foot (and leg) bone rather than using the torso (which would raise the 'front-foot' at the same time too far from the ground) [33f_cubie.blend]
[illustration 75] at frames "5" and "8", and "19" and "23", the torso bone is used to raise the whole character rather than a section of it because the leg bones cannot be manipulated into position without unnecessarily deforming the mesh (by raising the legs up into the torso region) [33g_cubie.blend]
An advantage to breaking the pose process down into a series of passes or stages is that the order in which each step is done can be changed, the bob for example could have been the last element inserted rather than being amongst the first because doing so doesn't take into account what then becomes a torso bone orientation that's slightly out of sync relative to where it should be after pitch, yaw and roll has been accounted for. In other words, the torso bone isn't where it should naturally be as a consequence of pitch, yaw and roll. To fix these types of issues pose markers typically need to be removed and the bone reposed (cf. illus. 76).
Design note: the old pose data is not correct with respect to what should be happening, in other words it wasn't overridden because numerically it appears nothing needed to be changed - the sequence follows through as defined by the frames and poses marked, however, it's not until they are removed and the animation given the latitude to move and follow-through naturally that the disparity between what is there versus what should be there, becomes apparent - the torso bone doesn't rest perpendicular to the screen, its slightly askew, which does make a difference to the final sequence, minor as it might appear to be.
With this situation in mind, in the timeline right-click select the pose marker associated with the "torso" bone at frame "1" (bone selection in the 3D View is not necessary) press "Delete" then left-click "Delete Keyframes" ("Delete » Delete Keyframes") in the pop-up that appears to clear all pose data associated with the removed marker. In the 3D View the bone and character may reset themselves (cf. illus. 77). Once the marker is removed scrub the slider back and forth to see how the bone naturally re-orientates itself with respect to the action now that its free to do so - it doesn't rest perpendicular to the Screen as before but slightly askew, a new and natural resting position.
Design note: scrub the timeline slider back and forth after removing the pose marker regardless as to what happens in the 3D View to ensure Blender properly updates the Scene - cached data used to render what's on screen occasionally needs to be forcibly updated, scrubbing the slider ensure the new resting position is 'clean' and only based on existing pose data/markers.
Reposition the slider at frame "1" (if not already there), then in the 3D View right-click the "torso" bone and pressing "R" move the mouse rotating the bone a degree or two until it stands upright relative to the previously updated orientation. Release to confirm. Then whilst "torso" is still selected adjust the distance between the characters feet and ground by left-click dragging down on the blue handle of the widget until the Red Ninja stands properly on the horizontal. Release to confirm. Once set, copy the bones new position and paste it to frame "30" so both start and end frames are identical - with the torso bone selected left-click the "Copies the current pose..." button (or "Ctrl+C") in the 3D View Header then move the timeline slider to frame "30" before then left-clicking the "Paste the stored pose..." button (or "Ctrl+V").
Design note: the torso bone is corrected in "Front" ortho, "NumPad 1", to ensure the adjustments don't effect the other axes. As an alternative to free-rotation when manipulating selections by small amounts, hold "Shift+Ctrl" as this grid-snaps to single whole units, i.e. "1°" increments when rotating ("Ctrl" on its own snaps to "5°" increments).
Repeat the corrective rotation process for frame "15" - right-click select the frame marker at frame "15" corresponding to the "torso" bone and press "Delete" (select "Delete Keyframes") to remove all associated data, scrub the timeline slider back and forth to check the bones orientation, then with the slider again at frame "15", press "R" whilst the mouse is over the 3D View and rotate the bone upright. Release to confirm. Then again adjust the distance between foot and floor by left-click dragging the blue handle of the widget downwards until the characters feet touch the ground. Release to set the bones new position (cf. illus. 78).
Design note: the degree to which the torso bone resets once old pose markers have been removed varies depending on the lead-in and lead-out from the pose - frame "15" for example has fully posed from data either side (frames "8" and "19"), whereas frames "1" and "30" don't. This affects the averaging used to determine pose coordinates and is an important reason why frames "1" and "30" are identical, each compensates for the others missing component (the lead-out for frame 30 is frame 1's lead-out).
These finalising adjustments can be made as part of other minor corrections that might make the animation appear less abrupt and more fluid, perhaps reducing the degree to which the character twists and turns as it moves. In either case playing through the sequence now ("Alt+A") shows a better transition between the keyed frames.
[illustration 76] the torso bones position is based on the character simply bobbing up and down so at present its orientation doesn't take into account subsequent updates that have been made - the bone aligns perpendicular to the view (as indicated by the arrows) [34_cubie.blend]
[illustration 77 & 78] with the old pose markers deleted the bone resets (image middle) in line with a more natural, slightly askew orientation (indicated by the green arrows) directly related to the adjustments that have been made since (image bottom) [34a & 34b_cubie.blend]
At this point the pose process is essentially complete. Before the sequence can be put to use however, it has to be shortened by one frame to eliminate the hiccup that occurs as both end and start frames are cycled though - two (identical) frames is one frame too many, so one has to be removed or at the very least discounted. The simplest way to do this is to decrease the animations length. In addition, for export a fixed end point, an extra keyframe set, will also need to be included.
Design note: the walk cycle comprises some 30 or so frames, seven of which carry the 'key' data necessary for "Tweening", the process of transitioning from one frame to another without each needing to hold an actual pose (7 'key' poses can be used instead of 30, one per frame).
First set the sequence length. In "Render" Properties (left-click the "Render" Properties button) decrease the "End Frame:" value in "Frame Range:" by a single unit from "30" to "29" - left-click the input field and type a new value, or left-click the left arrow to the left side of the property to decrease the value. If the sequence is then run ("Alt+A") the transition point will be smoother because a duplicate (frame "30") is now ignored (cf. illus. 79).
Design note: the effect of this change can be seen when the animation is running whilst the adjustment is being made ("Alt+A"), the action transitions without 'popping' when it cycles across the start/end point.
To add what will become the actual endpoint of the sequence, move the timeline slider to frame "29", then with the cursor over the 3D View (still in "Pose Mode") press "A" to select every available bone, "Shift+" left-click one ensuring its the active item of the group, then press "I" to automatically mark the "LocRot" data that has been captured throughout the animation process. A new (full) set of pose markers will appear in the timeline confirming the action. Upon playback now the sequence will run through without the hiccup at the start and end points.
Design note: if the mouse cursor is over the timeline when "I" is pressed, the "Insert Keyframe" pop-up appears, select "Only Selected Channels" from the list of available options.
[illustration 79] to properly loop, the last frame need to be ignored by reducing the frame count, and/or inserting a new keyed frame before the very last frame ("29" in this instance) for export needs - select the entire rig (all available bones) then press "I" to auto-insert the necessary data [34d_cubie.blend]
At this point the character is usable within Blender. Outside however, each keyframe set needs to be marked to ensure every bone is captured and represented by a bone channel and marker in the timeline - although internally Blender understands a given sequence regardless of any apparent gaps and omissions, use outside requires keyframe data be complete for proper functionality.
Design note: gaps within keyframe sets mean coordinate data being averaged between frames that are marked, typically resulting is incorrect articulation of the Armature and character mesh.
To quickly check the timeline, with the mouse over the Action Editor press "Ctrl+UP" maximising the view and revealing all the active channels and poses markers - gaps indicate generated (tweened) pose data that need to be properly occupied (cf. illus. 80). Once assessed press "Ctrl+DOWN" to minimise the timeline retuning Blender to its default state, then in the 3D View press "A" to select all available bones ("Shift+" left-click select one bone to set it as the active item in the group). In the timeline move the slider to frame "1" and working through to frame "30, stop at each frame set pressing "I" to (re)insert the pose data for each bone. This results in a number of previously unmarked bone channels appearing in the timeline alongside the missing pose markers completing each frame set (cf. illus. 81). Once done the sequence is complete and the animation in a usable state ready for export.
Design note: pressing "I" automatically inserts data attributed to bones selected so ensure all are included (this might mean pressing "A" twice, once to clear previous selections, then once again to reselect everything). When exporting, the number of frames to be marked and/or included depends on the export script and final file forma, some might require a full sequence 'bake', whilst others typically not.
[illustration 80 & 81] using 'auto-insert' typically results in a few bone channels not being marked (image top). For external use this data should be set - select the entire rig (all the available bones) and press "I" to auto-insert the "LocRot" data for each bone per keyframe (image bottom) [34e_cubie.blend]
Although the Red Ninja is shown looping through a simple walk cycle, the basic principles behind the sequences production are the same for other types of animated action, e.g. complex combat motions, idle breathing, or even blinking, all use the same fundamentals to bring objects to life without necessarily overcomplicating the process.
Design note: as discussed in the tutorial, the challenge to animation is not the process itself so much as the fidelity of the final result. Although this latter aspect is often determined by design, it's still possible for even the simplest of objects to appear real (behave as expected based on rules defined by the environment).
Breaking the process in to a series of manageable steps also aids development, each able to be further divided to suit the complexity of the task at hand; model the character (with a mind to the type of animations that might be needed) - primitive, block-out, shape, detail, UV's, texture; create an Armature using the mesh as a guide - block-out, connect, IK; then animate - block-out, initial posing, detail posing, etc. In this way very complex structures and motion can be created and replicated without being too overwhelming.
[illustration 82] the final walk cycle in action showing the correct sequence length (bones selected in 3D View to highlight) [34e_cubie.blend]
KatsBits provides freely available game and content making tutorials and resources, helping Visitors build their own games, or go further, Game Design Studios!. At KatsBits we strive to bring relevant material to our Readers and forefront Blender as a general game development tool.