Blender 2.5 - What's going on with some "missing features" for animation

With the recent Blender 2.5 "first stable" release, previous experience tells me that we're going to see another wave of "missing features" complaints again (this post was originally written during one of these bouts of wine-o-mania), so I thought I'd take the chance to clarify the situation with a few more of these here now. If you don't find an answer here, try the other FAQ's too. 

"Show Keyframes" (KKEY) in IPO Editor
(Also, "Why can't keyframes be edited from NLA Editor")
I've heard various mumblings once every four months or so complaining about why this doesn't exist anymore. However, there are a few good reasons why it's not coming back.

One of the greatest reasons, is that when starting work on 2.5, I decided to go through, and clarify and clearly delineate the roles of the various editors. With the situation we used to have, we would have 3 editors where keyframes could be edited, with varying levels of control and general polish of the tools:

• The NLA Editor was mixing strip-operations with timing operations on keyframes
• The Action Editor only focused on the timing of keyframes (with additional provisions for keyframe properties)
• The IPO Editor was a mix of timing of keyframes (KKEY and direct editing of keyframe controlpoints), keyframe values + curve shapes (the only place where this features), and setting keyframe properties. At the same time, for shapekeys, there was the rather bizzaro "horizontal-line" crap (sometimes the lines were blue, sometimes orange, and sometimes yellow, yet spaced at irregular intervals), which I admit to never really understanding until checking out why certain things were being done in the code.

This hodge-podge was bad in many ways:
- on the code front, this made coding tools more difficult, as you had to deal with two different types of data while also making sure that everything would still work nicely together
- for users, this lead to the "so which editor do I use to animate with?" questions

Therefore, the simple solution was to remove any functionality from an editor if that did conflicted with its core purpose, with this "core purpose" being defined by what aspects of the animation the editor showed which the others did not. For the NLA Editor, this was clearly the NLA Strips, while for the Action/DopeSheet Editor, this was the timing of keyframes. Hence, the IPO/Graph Editor was left to the adjustment of animation curve shapes through the modification of keyframe values and the slopes of their handles.

One direct casualty of this was the "Show Keyframes (KKEY)" functionality in the Graph Editor, as its functionality was already covered by the more-dedicated DopeSheet editor. (Another is the shapekey lines stuff). Why introduce more complexity (in the form of extra datatypes to worry about) when there's something else that does this better already!

On the NLA front, a similar argument applies for why keyframes cannot be edited from there anymore. Perhaps one of the main reasons that keyframes were shown there in the past was because there wasn't any other way that you could adjust the timing of keyframes across multiple objects at the same time without doing a lot of window setup first (or scripting hackily). But now we can do this in both of the other animation editors, so it's time that this was put to bed!

"Show Keyframes" (KKEY) 3D View
First things first; with the removal (well, it was never implemented in the new codebase at all) of the KKEY functionality in the Graph Editor, there wasn't such a strong connection with that functionality left to really push for this to have to come back.

But perhaps more critically was that the code for this was not so nice, as it was hacked directly into the object drawing code - one large blob of code in another monstrosity, but a slow one at that, which recalculated everything many times.

Ideally, this would come back as part of some more refined onion-skinning or "ghosting" functionality (which is not limited to armatures only). In fact, as it stands now, armature-based ghosting has by and large turned out to be not so much of a handy feature, as it is often quite difficult to actually see the shape changes (i.e. with some volumes instead of 'imagined' volumes) since with most rigs, the control bones bear little resemblance to the volumes they control. Instead, full-blown character mesh ghosting would be required. But in order for that to happen, we must IMO have a well-defined mesh caching system built-in to avoid some of the mass-recalculations which currently make this infeasible.

All Walkcycle-Related Tools
Currently, all of the tools related to providing some kind of path-control automation over walkcycles has been removed. By the end of the 2.4x series, Blender had accumulated too many different methods of achieving this in its source code. It was not clear which ones were working still, or which ones worked well to begin with. Furthermore, some of the older methods at least relied on certain specific rigging hacks to be present in order for them to work.

Hence, all of these have been removed until further notice and investigation into whether such tools are actually warranted as part of the core, or better suited as addons which could be tailored to suit house-styles so to speak. Anyways, all of these matters are the subject of a draft post I haven't gotten around to posting yet (much like this article).