Blender Animation FAQ's - June 2015 Edition

From time to time, several issues commonly popup up time and time again. So, I'll try to answer a few of these that come to mind most currently.


1) Why can we not edit keyframes in the Timeline?
In the short-to-medium term: It's not happening, as this is a very slippery slope! If I added just one editing tool (grab) and one or two selection methods (e.g. click-select + border select), I'm 99% confident that it won't be long before I start getting requests for "just one more little thing" to also be exposed there (e.g. more selection tools, change interpolation type, change handle types, delete, scale, duplicate, etc.). Before long, we've now completely duplicated all the dopesheet's operators, except that the timeline ones now do a worse job; if anything else needs to be added, I then have to maintain one more set of operators.

In the medium-to-long term: My preferred option here is that once the Anim Channel Filtering API is made available for use via Python, and/or we put in place some measures for having a "default" animation-editor filtering context that can be used outside of the Action/Graph/NLA editors (so that those operators can be called from other editors more readily), it will become possible for users to either make use of Action Editor operators in the timeline (as if it was the summary track), OR addons could get created for doing this (using the proper API's).


2) Why don't we move everything to the dopesheet, and get rid of the timeline if it can't be used for editing anything?
Simple Answer: There are other things that the timeline does, which aren't that suitable to be placed elsewhere

Long Term Answer: For animation, the timeline may be a good place for waveforms to get shown (for lipsyncing work). I've floated this idea several times, though IIRC the sequencer people weren't too happy about this. Nevertheless, IMO it's quite common that animators will have a single audio strip that they care about - we could simply have a way of marking that one as the "reference track", and have that get displayed in the timeline so that it is more useful.


3) Why can't we change rotation mode on more than one bone at a time?
No, no, no, no, no!!!!   It has always been possible to change the rotation mode on more than one bone at once.  You can use the  Ctrl-R   shortcut to do this. It's been there ever since the ability to use different rotation modes was introduced


4) Why is the default rotation mode "quaternions" for bones?
Sigh... defaults are such a contentious topic! Basically, back when I introduced the rotation modes stuff, I canvassed the opinions of the top riggers of the day. From their feedback, the general message was that we should stick to quaternions for that, since it worked quite well.


5) Why can't we use proportional editing in the Graph Editor?
In the upcoming 2.75 (?) release and current master, this problem is no longer true anymore. The reason why this was not added for so long was that basically all of the core devs (IIRC, me, campbell, mont29, sergey?) who've had to debug the transform conversion code for the Graph Editor have learned the hard way that that was one piece of uber-fragile code with lots and lots of non-obvious edge cases and some serious weird-arsery going on that bite you hard with little prior warning. In retrospect, trying to handle all the different cases with the same basic set of logic here just proved to be far too hard ("DRY strikes again"!).

Therefore, this feature didn't happen for a long time, as none of us was really keen to jump into that beast and add anything new there, lest all hell breaks loose again. Thankfully Antony (psy-fi) stepped up and bashed this thing into submission, and you can thank the Gooseberry project for that!

(<--- For the naysayers: See... the BI projects do result in real production issues that affect everyone being tackled, and not just film workflows; maybe these aren't your personal "big shiny wishlist features" for your particular niche... too bad!)


6) When are we getting editable motion paths?
Short Answer: Not anytime soon

Long Answer: The reason why this won't be happening anytime soon is that there are some really nasty technical challenges and corner cases here. Sure, these things work fine on simple objects and "simple" bones (i.e. no funky parenting, constraints, IK, or drivers at all) - which is what people initially test these things on, and conclude that they're already somehow "fully functional" already.

Unfortunately, if the number of tools attempting to do these kinds of things are any indication to go by (and yes, I have some firsthand experience with some of the quirks involved here), getting this to work in all situations is far from being a walk in the park. We could deploy a version of these tools to tackle the simple cases; but then we'll just get hammered day in day out to make the tool work for all the complex and wacky rigs out there (i.e. the whole, "On the box it said this stuff works, it not work! FFIIXX IT!!!!!1!!1!1!!!!!! URRRGGEEEENNNT!!!1!")


7) Why are Objects not shown in alphabetical order in the Dopesheet?
Short Answer: Technical limitations/tradeoffs

Long Answer: The order that items currently appear in is the "depsgraph sorted" order. The old depsgraph worked by sorting the list of all objects so that an object's parents are included before the object itself. For performance reasons (i.e. so that we don't constantly have to sort that list of objects everytime we want to show them in an animation editor) and to avoid the complexity of the alternative (i.e. storing a cache of object datablocks refs/names sorted in alphabetical order, with all the annoying invalidation/refresh issues that caches have), we don't try to sort that list, but just use it directly instead.

Maybe there'll be some other solutions I've missed here. Or perhaps, as the new depsgraph doesn't do this sorting (though there may be issues down the track with tools that previously assumed things about the way that objects were ordered) things may start getting better.


8) Can we move the filtering options above the channel list instead?
There have been some proposals floating around out there to move the filtering options up to the top of the channel list instead of having it in the header. TBH, this is quite an interesting idea, and I will consider it more. That said, there are several things we'll have to be careful with here:
   - There is not that much space up there to fit these options. Which options should get shown, and what happens to the rest? Do we overflow them below the most important ones, or hide them in a little flyout/dropdown/hamburger menu?
   - Does this design really work for all of the animation editors?
   - We're going to want to have these always visible (i.e. be in a static location), which means that we need to subdivide that channels list region. However, the downside of this is that now the vertical space required for these editors is necessarily greater - something that from many screenshots I've seen is not really something that most users can really afford to do.


9) Why don't we have a "spring constraint"?
There have been multiple patches in the past proposing these. However, the main reason we don't have one is that there are some technical issues here which mean that most of them don't really work that well!

Specifically, all of these physics-based techniques work really great when we can assume that time is always increasing monotonically. That is, time only flows forward, and in fixed-sized increments. This is something you can only get in a realtime/game-engine/simulation environment. You cannot get this in a 3D DCC though! Animators regularly scrub their frames, jumping between different parts of the animation to check how things flow, and move back and forth between pairs/sets of frames checking how things fit together. Spring Constraints really can't cope with that sort of jumping around, since they depend on the previous state to figure out what the next state should be! Figuring out a sane way to have this work is one of the main hurdles that needs to be addressed before we can have such a constraint.


10) When are we going to get a muscle sim/system?
- You'll have to ask someone else about this, because I'm not very interested in deformation stuff.
- What on earth is a "muscle system" supposed to do exactly? Is it the flexing, bulging, and sliding? Is it simulated jiggling/secondary motion? Is it a way to control a character (as opposed to using bones/skeletons)? AFAIK, these things mean different things to different people!


11) When are we going to get <XYZ> deformation technique mentioned in <ABC-Hip Paper of the Month>?
Refer to #10 - I personally don't do much work with deformation techniques, so don't expect anything from me. Deformation, topology, and rendering are 3 topics I have absolutely zero interest in. Rendering == Boring (heaps of people do it anyway), Topology (prior experiments with computational topology have not ended well; too many bloody edge cases and mind bending needed... bleh!), Deformation ==  Not very interesting to me (and this is both as a user/rigger and as a dev; I can't really tell the difference in many cases XD)


12) When can we edit "baked/sampled" FCurves?
Short Answer: Don't hold your breath

Long Answer: It's not really that much of a priority. There are some efforts afoot to convert such dense curves back down into simpler low-density curves for editing though. There were also plans initially for the ability to directly edit these (with certain limitations of course).


13) What about onion skinning for meshes and objects?
Short Answer: Not in the short term. After certain infrastructure issues are addressed, we can reexamine this.

Long Answer: The main reason that onion skinning for meshes/objects doesn't work now is that it would simply be far too slow to work with, not to mention the fact that to evaluate the meshes to do this, we have to clobber a lot of state data everytime this happens. The first part of the depsgraph refactor work that has gone into master lays some of the foundations for this; we're still missing the "operating on separate copies" part (or what Sergey calls "copy on write") to solve the other calculation speed issues though. We are also waiting on the viewport speedup/compositing stuff for more efficient drawing of all the geometry that will need to be rendered. Otherwise, the settings for drawing/controlling these things have been in place since May 2010.

~~~

Those should be the main ones which keep cropping up I think. I may add a few more to this list later, but this list should do for tonight.