2024-05-24 Animation & Rigging module meeting

The meeting will be on 2024-05-23T16:00:00Z. It is open for everybody interested to join the video call (link below).

People present are referred to by first name for brevity. Others are referred to by full name.

Bassam Kurdali, Christoph Lendenfeld, David W, Ivan Cappiello, Nate Rupsis, Nathan Vegdahl, Pierrick Picaut,



Names are from the Git log. This list is limited to functional improvements & bugfixes.


Technical Documentation

Ongoing Work

  • High Prio bugs: None!
  • Christoph:
  • Nathan:
  • Sybren:
  • Animator meeting at Blender HQ, with Rik Schutte, Hjalti Hjálmarsson, and Pablo Fournier:
    • Discussed pose flipping in the pose library:
      • Rik: what’s the status on the pose flipping stuff that was discussed at the last module meeting?
      • Hjalti: IMO there shouldn’t be any smart “auto flipping” e.g. based on selection. There’s too much potential for the “smart” behavior to mess up what the user is actually trying to do.
      • All three animators liked the “flip pose” checkbox in previous versions of the pose library:
        • Hjalti: it lets us see the poses flipped in the preview images. Whereas doing the same with the hotkey solution would be distracting (e.g. the images constantly flipping every time you hold down ctrl).
        • Hjalti: a checkbox may seem inelegant, but in practice you’re often zoomed in and working on just one side of a rig for a bit.
        • Nathan: and it’s not like we’ll remove the hotkey, so that will still be available in more dynamic situations.
    • Discussed confusion with Blender terminology (not animation module specific):
      • Hjalti: there’s a bunch of Blender terminology that I don’t know/get. And it changes from time to time as well. E.g. what counts as a window, a panel, etc. when referring to different parts of Blender’s UI in a bug report.
      • Hjalti: maybe we can have a regular meeting at the studio where terminology gets explained, so we can all be on the same page.
      • Nathan: the act of preparing such a presentation could also help to identify areas of Blender terminology that need improvement.
    • Discussed #71615: Select key in dopesheet deselect bone in the viewport (only show selected disabled):
      • Rik: I filed an issue about this, and it got closed as duplicate in favor of the already existing one. The existing one is 5 years old. Can we finally address this?
      • (Note to those reading the meeting notes: this was added to the module meeting agenda, and is discussed further below.)

Patches: Review & Decision Time

  • #120558: Anim: Theme entry for time visualization Out of WIP. Color settings are in the theme. Is that the right place?
    • Chrisoph: these colors might need to change with the theme, to appropriately stand out against the background color.
    • Nathan: there is precedent fore some color settings being outside of the theme. E.g. weight painting colors.
    • Pierrick: only ever changed colors via the theme anyway. However, the animation settings is where a lot of animation-related colors settings are, so maybe that’s better than the theme.
    • Christoph: this is also used for grease pencil colors, so does it still belong in animation settings then? Although indeed it is for doing animation in grease pencil as well.
    • Bassam: there’s a bit of a bifurcation issue with where to put them; there’s the Animation tab, the Editing tab is where Weight Paint colors and Grease Pencil settings are.
    • Ivan: let’s discuss with the grease pencil team, to make sure everything can stay unified. We should also consider a future ghosting feature. And make sure it’s all unified.
    • Nathan: I’m now leaning towards the theme being the right place. I think my discomfort with putting it in the theme, and the reason I might want it in the preferences, is just because theme editing is annoying.
    • Ivan: the weird default weight painting colors (rainbow) are a good example of a more general issue: defaults should be more sane. If we follow that philosophy, it doesn’t matter as much the discoverability of customization. People shouldn’t need to customize things to have good, reasonable colors.
    • Nathan: I agree. If the defaults are sane, then the theme being annoying to edit is less of an issue. And logically the theme seems like the right place. Making the theme editing experience better is a separate issue, and we shouldn’t let that push us into the wrong decision here.
    • Decision: module agrees to put these colors in the theme.

Key/Channel/Bone Selection in the Dope Sheet and Graph Editor

5 year old issue: #71615: Select key in dopesheet deselect bone in the viewport (only show selected disabled)

Note: turns out this also applies to the graph editor, and the situation is maybe even a little trickier there since there’s no keyframe summary: you’re always selecting keys on specific individual f-curves.

  • Christoph: this is a hairy issue: it’s not just bones, it touches grease pencil too. Grease pencil basically needs this behavior for a reasonable workflow. So this isn’t a matter of a bug fix, it’s a design task.
  • Bassam: one bone-related use case is that it can be used as a kind of bone picker.
  • Christoph: a proper bone picker would address that.
  • Ivan: and it’s not really very good as a bone picker anyway.
  • Ivan: it’s really a deep design task. We need to make sure we understand the use cases, and figure out what the really useful behavior(s) are.
  • Pierrick: note that this doesn’t happen in object mode, only seems to happen with bones in pose mode.
  • Nathan: oh wow, so this is also a consistency issue between pose mode and object mode. Note that this also seems relevant to Project Baklava, because we’ll want a unified, consistent, and useful behavior here for the new animation system as well.
  • Nathan: main reason I put this in the agenda is because of how long-standing this is, and I think we need to decide on how much of a priority this is. I propose we bump up the priority on this, make a proper design task for it, involve the grease pencil team, and finally get this all sorted out.
  • Decision: module agrees with Nathan’s proposal.

Help Needed

  • Sergey wrote in the module chat:

    Hello everyone,
    Long story short: it feels we can make frame change 2x faster!
    Long story:

    • The “Frame Change” operator does the DEG tag for frame change as expected
    • However, there is also need_extra_redraw_after_scrubbing_ends, which sends a notifier NC_SCENE | ND_FRAME, which enforces an extra DEG update (the if (do_anim) in wm_event_do_notifiers)
    • So if you click on a frame, but not fast enough, you might end up with 2 updates (first one form the change_frame_apply, and the second one from the ED_update_for_newframe(CTX_data_main(C), depsgraph); in the notifier code)

    There are many things we can do to solve some legacy things around all of this, but easiest is probably to implement some sort of flag in the operator which will indicate whether frame was changed since the last tag, and don’t do the extar tag when you click and release at the same frame)

    • Christoph: I had a look at this. Note that this is specific to single clicking on the timeline/graph editor, etc. So just jumping to a single specific frame. It doesn’t apply to e.g. animation playback or scrubbing. It seems a bit above my head, so not sure if I can fix it right now.
    • Nathan: if it only applies to jumping to a single frame, this feels less important. It would be very important if it were playback or scrubbing, but since it’s not then I think this is more of a “nice to fix when we have some spare time” kind of thing.

Next Meeting

The next meeting will be on Thursday 2024-05-30T16:00:00Z. Again it will be open for everybody who’s interested. The provisionary meeting agenda will be updated before the meeting.


I did not get a chance to ask about this repo, GitHub - JiahuiCai/Blender_Interactive_Motion_Path . I saw people online requesting this to be added to blender, not sure if it would fit, but figured I’d forward it anyways.

1 Like