2024-05-02 Animation & Rigging module meeting

Meetings
1

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

Present: Christoph Lendenfeld, David Domingues, David W, Demeter Dzadik, Eduardo Rubio, Nate Rupsis, Nathan Vegdahl, Pierrick Picaut, Sybren Stüvel

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

Links

Since the Last Meeting / Announcements

Landed

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

Blender

Technical Documentation

Ongoing Work

Patches: Review & Decision Time

  • Guillermo Careaga (Dreamworks) asks on X/Twitter why old keys stay selected, when you insert a new key in the graph editor. Makes it hard to adjust a key immediately after creation. This is also inconsistent with the 3D Viewport, where all objects get deselected when adding a new one.
    • Nathan, Eduardo: +1 for this change.
    • Sybren will make a PR with a test build.
  • #90184: Add Asset Browser to Animation Workspace?
    • Sybren: mixed feelings. Might be wasted space, but also help with discoverability of the pose library.
    • Pierrick: never uses the pose library, so he’d be closing it all the time. But not a big issue, as he can save his own default file.
    • Pierrick: the pose library can also be tricky to set up for beginners.
    • David W: uses pose library a lot, but also sees that many people don’t.
    • David W: would it be a good idea to have some default poses for a Rigify human? Something that can be used by everybody? Sybren agrees.
    • Nate: animators using the pose library likely already have their own setup. He suggests going for a more minimal setup by default. Maybe reconsider if the extensions platform is going to offer assets with pose libraries.
    • Nathan: we need to figure out what the purpose is of the default workspaces. If it’s for exploration / discovery, it should be open. If it’s to provide a useful setup for new users, it should be closed.
    • Pierrick: who uses the default layouts? Some people in the meeting do, some don’t. He never does, always sets things up for himself.
    • Pierrick: stresses the importance of discoverability.
    • Christoph: usually creates his own for his main task: animation. For scripting / video editing / shading, it’s convenient to have some pre-made setups.
    • Nate: we could create a new ‘app template’? Like available for ‘Video Editing’. Sybren: good idea, especially when we have some poses to show by default.

C++ification of the code: Namespaces

  • Sybren asks:
    • More code should be in some blender::subname namespace. That way references to blender::animrig::… can also be shortened to animrig::….
    • Do we want sub-namespaces, like blender::animrig::fcurve, blender::animrig::keyframing, etc?
  • Nathan: Rust fan-boy, with the nested namespaces, it’s easy to see where it comes from. We could be very liberal, and have a namespace per file.
  • Sybren: mapping to files seems a bit unnecessary, namespaces more for grouping of functionality, regardless of files.
  • Nathan: we could use directories too?
  • Christoph: let’s move the editor code with blender::editors. especially if others have moved there already.
  • Nathan: as we are doing now is fine, moving code into namespaces when we move the code itself.
  • Christoph: not a big fan of sub-namespaces. Might become too granular. If we don’t need it, let’s not do it.
  • Nathan: likes sub-namespaces for “this is F-Curve related”, making that clear (instead of being some hint in the function name).
  • Sybren: let’s keep going as we are, then. Nathan: that’ll also give us the ability to learn without investing too much time.

Next Meeting

Note: the next meeting will be skipped, as 2024-05-08T22:00:00Z is a national holiday in The Netherlands.

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

5 Likes
2

I described the same issue with new keyframes getting auto-selected in Dopesheet and Graph Editor in an RCS post a long while ago: Right-Click Select — Blender Community

There was a proposed fix but it seems it was put on hold for design reasons and then nothing further happened with that. I would really like this to be fixed still as having to manually deselect all these keys I never selected is one of my biggest pet peeves for animation work in Blender, so I would welcome any such change.

3

Unless I’m misunderstanding things, you’re proposing the exact opposite of what Guillermo was suggesting. To summarise (and also as a double-check that I actually understood you correctly):

Guillermo’s suggestion: on keyframe insertion, deselect all keys, and only select the newly-inserted keys.

Your suggestion: on keyframe insertion, do not touch selection of existing keys, and keep newly-inserted keys deselected.

Do you have a link to that?

Blender has always selected the thing you just created. This works like that with bones and with objects, and now Guillermo proposes to do the same with keys.

Earlier Guillermo and his colleagues also suggested: When selecting a key, automatically jump the playhead to that key so that you can click a key and immediately drag it up/down and see the effect. I think that plays along nicely with only having newly inserted keys selected.

2 Likes
4

It’s not exactly the same suggestion (I would prefer it not affect key selection at all personally as described) but the underlying problem of Blender auto-selecting a whole range of keys that you’ve created or modified as you’re animating (also including previous selections) is the same, it seems to me… and changing it to select only the latest one would solve this problem (and sounds to me like that was what Guillermo was asking for), unless I’m misunderstanding the proposed solution based on above description.

I really DO NOT want to be left with a whole range of selected keys that I did not select, while animating. If only the last modified key is selected, that’s not so bad.

Do you have a link to that?

User RedMser in the comments on RCS posted a link to this fix, now labelled as “Changes Planned”: Blender Archive - developer.blender.org

5

This made me think: how can you modify keys without selecting them? But yeah, it’s true – Blender automatically selects keys it updated via auto-keying. That looks a bit weird to me too, especially since it doesn’t deselect the other keys.

2 Likes
6

Yes, this is my request. When a new key is created, only have that one selected.

6 Likes
7

About the default workspaces discussion.

Workspaces should really be folded up into the brush assets project. Right now they’re a pain to use because you can’t make bespoke setups and save them for reuse. You need to decide what you will need ahead of time and save it in a default file. But if they were turned into assets you could save at any time and push to an asset file for reuse, either locally or across files, they’d be much more useful.

5 Likes
8

Thanks for sharing your view. Although I find this an interesting take on the topic, this is for another module – this is “just” Animation & Rigging :wink:

9

@ChristiaanMoleman @gcareaga
I’ve started working on a patch to change that behavior.
#121908: WIP: Anim: Deselect Keys before inserting new keys
You can try out a test build here: Blender Builds - blender.org

Let me know what you think of this

7 Likes
10

@ChristophLendenfeld this is working great for me. Thanks so much!

1 Like
11

Just tested this, I’m a fan. It’s much more convenient and intuitive.

2 Likes
12

Yes, this is much better than before. Thank you @ChristophLendenfeld.

I think I would probably still like having an option for keying to not affect key selection at all (per my RCS suggestion), but that is a much less urgent issue - more “nice to have” - now that it only selects the last modified key, and I could be persuaded to this approach being the more elegant solution anyway.

2 Likes