Thursday, November 15, 2012

FAQ - F-Curve Grouping Inconsistencies

This was originally posted in response to a bug report, but I thought it would be interesting to many other people, if only to document why things are so.

As Sambler writes:
I have found some inconsistency relating to keyed data showing up in the dopesheet/action editor/graph editor.

In the 3dview if you insert a keyframe it shows up in the dopesheet -

For an object all data keyed by set will go into a group (say location). keying another set of data creates a new group (rotation) If you go to the object properties and insert keyframes for scale they show up as individual lines not grouped together at all.

For a bone, keying location creates a group for the bone containing the location data. Adding another key for rotation brings that new data into the existing bone group. But if I go into the bone properties and key the scale properties they show up in the dopesheet as individual lines.

So it would appear that keying by a predefined set in the 3dview groups the data, keying a set for a bone groups the data by a bone group, but keying in the properties panel is not considered a keying set so enters unrelated keyed data.

So, why the inconsistencies?


1) Keying Sets (by default) create groups according to the name of the Keying Set used. This is so that, if you create several absolute Keying Set for different sets of properties (potentially across different datablocks), you can easily find all of the channels which are related to those channels.

2) When dealing with bones, Keying Sets default to grouping channels by the bone names instead. This is because, for typical rigs, there are quite a large number of channels per bone (at least 3+3/4+3 = 10). Hence, grouping by Keying Set name (i.e. all location, all rotation, or all finger bones) would result in too many channels being shown at once within a group to be useful. Instead, we group by bones so that it is easier to hone in on the F-Curves for those bones.


3) Directly inserting a keyframe from a button completely bypasses the Keying Set system. It's not a case of "we generate a keying set with a single item for this case"; rather, "we are just going to go in and insert some keyframes for this property only, on a once-off basis". The result though is that we don't really have info any about how to group these. Hence, they aren't grouped at all.


Now, if you don't like the default behaviour of built in Keying Sets, this can be changed. You just need to make one or two small one/two liner edits to their definitions:
- The Keying Set definitions are in: <blender_version>/scripts/startup/keyingsets_builtins.py
- However, the code that actually does most of the work lives in: <blender_version>/scripts/modules/keyingset_utils.py (Hint: look into the group_method and group_name args for ks.paths.add(...))

1 comment:

  1. thanks for the breakdown on why things are setup in this manner, at this time, in Blender. Thanks too for all your recent commits :-)

    ReplyDelete