Currently blender UI provides rather limited workflow aids for creating smoothly looping interpolated (not keyed on every frame) animation, like walk cycles. It would be good to improve the situation.
These are some objectives involved in creating loops, which I can think of at the moment, and their current status:
= **Looping the Animation** (in release) =
Simply creating a repeating animation has been possible for ages in a number of ways:
- **NLA:** a track can be set up to repeat a certain keyframe range of an action.
This results in a consistent loop that uses the exact same time range of all F-Curves in the action. However, different tracks using the same action may have different settings.
- **F-Curve Modifier:** the Cycles modifier makes a single F-Curve repeat.
The period and range of the loop is determined by the keyframes existing in the curve and may be different for different curves of the same action. This is very convenient, because applying the concept of overlap in the animation in some cases requires staggering keys away from nice columns. Absolutely requiring the loop to start and end on one single frame for all curves is thus stifling. However, this freedom can also be a cause of inconsistency in the loop periods, which is a bad thing.
The modifier also has advanced settings that allow e.g. limiting the number of iterations. However, if cycle ends are staggered as described above, the usefulness of this is somewhat doubtful.
- **(Pre-2.5 only) Cyclic Extrapolation:** the extrapolation enum of the F-Curve had Cycle and Cycle with Offset settings.
These were abandoned in favor of the modifier approach due to the possibility of extended settings in the modifier case. However, there are some code design arguments in favor of returning to this approach if implementing more comprehensive and integrated support for editing looping animations (e.g. see abandoned D2790).
All of these methods have a common property: in order to represent the cyclic animation, which can be conceptually imagined to have its keys be located on a literal cycle of time, as a linear F-Curve, one of the conceptual keys has to be arbitrarily selected, split into two copies, and set to represent the 'ends' of the cycle. This specific fact causes major workflow problems when editing the animation, which need to be solved.
= Smooth Auto Interpolation Across Loop Transition (addressed in master) =
A very important feature for convenient animation workflow is Auto bezier handle placement, which tries to create a smooth bezier interpolation curve by computing handles purely from the created key positions. This allows animating just by inserting keys, without mandatory use of the Graph Editor.
In order to create a smooth loop transition, this computation must be aware of the fact that the animation loops, and be able to look 'through' the loop ends to take the full flow of the curve into account.
This raises a technical design problem with code abstraction layers with both of the currently existing methods for looping the animation. Specifically, handle computation happens at the level of the base F-Curve, while both modifiers and especially NLA are supposed to be layers that simply change how the curve is evaluated. A 2.49 style Cyclic extrapolation setting won't have this abstraction problem.
For now this objective has been addressed in master by D2783 and D2884, via detecting and specially handling the F-Curve modifier with settings completely equivalent to those legacy extrapolation options (henceforth **trivially cyclic curves**); however this is an obvious hack from code design standpoint.
Addressing this for NLA seems to be completely impractical, unless actions are instanced in some COW fashion for each track, due to there being even more layers between the curve and the NLA stack, and the fact that settings can differ between tracks. This means that NLA is currently disqualified as a way to create smooth loops, and this workflow is more suited to be implemented at F-Curve/Action level.
= Keeping Ends in Sync =
As mentioned above, all of the existing ways of looping an animation require duplicating one key to serve as both ends of the linear curve. These keys must be kept in sync to avoid a jump in the action. However, Blender does not aid this in any way, so the burden falls completely on the user. Addressing this issue is likely the most important improvement to be done next.
The curve keys may be edited in a number of ways:
=== Insert Keyframe via 3D View (manual or auto) ===
This situation is quite simple to handle: it is simply necessary to duplicate the insertion to the other end of the curve if an end key is modified. In order to facilitate working with staggered curves (i.e. overlap etc) it is also convenient to remap the insertion in time if an attempt is made to insert a key outside of the existing range.
D3140 adds a toggle button that enables this specific behavior when modifying //trivially cyclic curves//. The behavior isn't always on because it may be inconvenient or confusing during blockout phase, when the loop isn't properly established yet.
=== Dopesheet ===
Dopesheet and action editor allow inserting keys, and also moving keys in time. Since the user sees the actual range of the curves in these editors, it is a question to be discussed whether it is more useful or confusing to retime key insertion. Regarding retiming keys, moving an end key may mean an intent of changing the loop period, or retiming the end key within the same loop period; this changes whether the modification should be duplicated to the other end.
=== Graph Editor ===
In addition to having similar concerns to the Dopesheet, this editor allows modifying bezier handles. This means considering how and when these changes should be duplicated to the other end, including a technical problem of what to do if the user actually has both end keys selected when performing an action.
= Maintaining Loop Period Consistency =
While staggering the loop range for different curves is a desired property, having differing loop periods for different curves in an action is likely undesirable. Thus an ability to specify a desired loop period at Action level, with some automated support for enforcing it may be useful. This may include things like automatically configuring F-Curves that are added within the action to be cyclic and setting up the correct period, or highlighting curves with the wrong period in the UI.
On occasion it may be actually useful to have different loop periods in an action, especially of lengths that are a divisor of the main period.
This objective requires discussion, and possibly experimentation with python addons to find what is useful and how to design it best.
= Miscellaneous =
=== Rotate Loop Operator ===
As described above, the location within the loop that is split to create the technically required loop ends is arbitrary. Thus sometimes it is useful to be able to change this without actually changing the resulting animation by appropriately moving keys around. This can be done manually in dopesheet, but a single operator would obviously be more convenient.
=== Cycles That Repeat Mirrored ===
Some cycles, like perfectly symmetrical walk cycles, have two halves that are mirrors of each other. Editing these involves copying any changes to the mirrored section, so implementing at least an operator (possibly in python) to do that with one button press could be useful.