F-Curve First Aid - Identifying and Medicating "Disabled" F-Curves

One of my items on my todo list for ages has been dealing with the problems associated with F-Curves with "data paths" (a way of referring to the property that a F-Curve affects) that can't be "resolved" correctly, and are thus tagged as "disabled".

Finally I've had time to work on some experimental measures for dealing with this, and I'll use this post to discuss these changes. The commit for reference sake is #33008.

Disabled F-Curves

These are F-Curves which have been tagged so that they will not be considered for evaluation at all (until this tag is removed), as they cannot be resolved for their current user (i.e. the ID-block using the action the F-Curve belongs to).

For example, this typically comes about when assigning an action created on one armature onto another armature, but some bones are missing.

This tagging will take place everytime these F-Curves are loaded up in an animation editor (i.e. they are the active action, so their keyframes can appear in the Graph and Dopesheet editors) and the F-Curves' paths are found to be unable to be resolved properly. This is done so that editing single-layer animation from another source will not potentially get bogged down by having to evaluate F-Curves that aren't resolvable, slowing down animation playback + editing fluency.


Identification
Prior to this commit, it might not have been that visually easy to identify F-Curves which have been tagged as disabled. Although these have always been displaying their full paths in such cases, it can be difficult to tell at a glance sometimes which F-Curves have been tagged as disabled, and which have merely have not be able to be resolved temporarily.

To solve this problem, such channels are now drawn with a red underline.

Identification in Action - A (Contrived) Example
For example, let's consider the following two screenshots:

1st Screenshot: Without

2nd Screenshot: With

In this example (a sample file from a bugreport - cheers Ben Passman for the file!), we've got two armatures: Armature1 with Bone1, and Armature2 with Bone2. We've also got a single action that is assigned to both armatures, and problematically (don't do this at home kids!) has keyframes for "Bone1" and "Bone2" within the same action.

But as we know, each armature only has one of those two, so the paths for one of these sets will not be able to be resolved correctly. Hence, one of the sets of keyframes will get disabled.

Now notice how, even with the zoomed out thumbnails of these screenshots, you can clearly see the channels which are tagged as "disabled" in the 2nd screenshot, while in the first, you'd have little clue without further investigation.

Identification - Another Example
Of course, a less contrived example would be that Armature1 had 2 bones: Bone1 and Bone2. In this case, if both armatures are assigned the same action, we would only have problems when editing the action on Armature2, since it doesn't have Bone1 (just like before).

This is a more realistic example, as it represents the common case where we might take some animation from one armature/object, and place it on another armature/object, only to find that we forgot to add a bone to the new armature, or perhaps that their structures are different!

But now, since Armature2 has had trouble resolving some paths, Armature1's animation "fails" now (on Bone1). What can we do?

Medicating Disabled F-Curves
In the commit mentioned above,  I've added a new operator which clears all "disabled" tags from all the F-Curves available within the current filtered channels in the relevant Animation Editor (selection status of the F-Curves does not matter).

To find this operator:
1) go to the Graph or DopeSheet/Action Editors
2) 'Channels' menu
3) Revive Disabled F-Curves

That's all. Once those tags are removed, if the curves are valid for the stuff which currently use them, the tags won't get reapplied. However, under other circumstances, those tags can reappear (e.g. keyframes for all users of an action appear, but only some of these users can resolve the paths).

---

Hopefully that explains the usage of this new feature. Feedback is always welcome :)