2023-10-17 Animation & Rigging module meeting

Meetings
1

The meeting will be on 2023-10-17T10:00:00Z. It is open for everybody interested to join on Google Meet (link below).

Present: Christoph Lendenfeld, Fani-Eleni Pandi, Hjalti Hjálmarsson, Ivan Cappiello, MohammadHossein Jamshidi, Nathan Vegdahl, Pablo Fournier, Rik Schutte, 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

  • Update on the conversion of face maps to mesh attributes. In short:
    • Hans Goudey will add selection operator for mesh attributes.
    • Face maps will also be versioned to boolean attributes, so that their names are retained.

Landed

Documentation:

Refactors:

Short-term goals / Ongoing Work

  • The new layered animation data model (#113594) is working, in branch anim/animation-id-113594.
  • Nathan is starting work on hierarchical bone collections.
  • Animation 2025 schedule: how to include in future communication?
    • Sybren: Issue on the tracker or wiki page as “communications home” for the project?
    • Nathan: Issue could be good. Can be easily linked to other PRs and issues.
    • Sybren: What to do with the Animation 2025 planning in general, w.r.t. how public it is?
    • Module agrees public is good.
  • Sybren is working on some last tweaks to the data model & preparation for the Animation 2025 Blender Conference talk.
    • Sybren: “insert key” function is still too minimalistic, and creates/fetches the FCurve as well as inserting a key. Adjusting the time with Cycle modifiers (so that the key is added to the first cycle) is thus impossible, as that needs access to the FCurve first. It also doesn’t cover things like visual keying, which is done by the current system in one go. All agree that this limitation is fine, and that what is keyed should be determined separately from actually inserting the keys.
    • Christoph: current key insertion logic should change anyway, as inserting a key can actually add a cycle modifier on the FCurve.
    • Christoph: be specific in the function parameters which time is meant (un-cycled, cycled, strip time, scene time, etc.)
  • Christoph: working on #113278: Anim: Keyframing Rework.
    • Blender’s current code was hard to understand, so he started with refactoring (see ‘landed’ section).
    • Keying sets as they are now will disappear.
    • Keying will be based on options in the preferences, instead of the long list of possible combinations.
    • “Visual keying on/off” is going to be an operator parameter, so it can be bound to a different hotkey.
    • Christoph: issue currently in Blender with auto keying & custom keying sets. The custom keying set is associated with specific data-blocks, so it can happen that you have Suzanne.location in the keying set, but you’re rotating Cube. In this case auto-keying will still key Suzanne.location, and I feel that this is going against Blender principles (working on X, but manipulates Y).
    • Sybren (and rest of module): agrees, not good & should change.

Patch Review & Decision Time

  • Bone Colors have been discussed in the last few meetings and #112943 + #112639. So far things are improving, but not good enough yet to really make people enthousiastic. New proposal:
    • Target Blender 4.1 (instead of 4.0), as the required changes to lift this from “ok” to “yes please!” are too big.
    • Unified ‘selected’/‘active’ color becomes Blender’s default behaviour.
    • All bone colors (themed & custom) are reduced to a single color patch for the ‘regular’ color.
    • A preference ‘colorise selected+active bones’ is added. This will automatically apply the ‘regular’ bone color to colorise its selected/active colors.
    • ‘Selected’ and ‘Active’ theme colors available for both Pose and Edit modes (Pose is already there, but Edit currently hijacks other theme colors; still good to visually separate Pose & Edit mode).
    • Versioning of the theme color indices on bones can be used to map between the theme colors to keep their look more or less the same.
    • Module agrees to the proposal.
    • Future: rule-based colors. Something Ton and Dalai also talked about. Would be Blender-wide, with bone colors as first implementation.
      • Nathan: could be a nice way to have bone collections impact bone colors again.
      • Nathan: this can also help debugging; different sets of rules can be active at one time so you can toggle between “debugging the rig” and “animating with the rig” sets.
  • #113138: Anim: Align new bones with the world axes
    • To decide: move forward with always-aligned-with-world bones? Or wait until we have time to implement a choice in bone axes?
    • Hjalti: Blender’s current implementation wasn’t super well thought out, just built that way. And this has caused lots of smaller issues over time.
    • MohammadHossein: for vertical bones you can just rotate the first bone, then extrude / duplicate.
    • Nathan: when rigging, the only reason to a brand new bone (instead of extrude / duplicate) is for having things like IK controls (where being world-oriented by default really helps) or for very specific alignment (where no default orientation would be exactly what’s necessary anyway).
    • Nathan: in favour of the PR, as it does help, and we don’t have the people to actually do the bigger change right now.
    • Christoph: it’s almost a net-zero, where we break what people are used to, but also improve some other things. All agree that Z-along-bone should have been chosen from the very beginning.
    • Sybren: How backward-incompatible is this?
    • Christoph: It’s a big change, so wait for 4.1 so it can be properly tested in the alpha stage.
    • MohammadHossein: it doesn’t break any existing existing rigs, so 4.1 is indeed fine.
    • Module decides: move forward with the PR, targeting 4.1.
    • Rik: bit off-topic, but could the rotation mode of bones be a preference? Nathan: yeah that makes a lot of sense. Sybren added #113927 for this.
  • #110650: Drivers of sub-ID properties do not get removed along with the sub-ID
    • To decide: bug or todo? Priority?
    • Nathan feels it’s unexpected behaviour. Would changing this break any workflows?
    • Decision: do due dilligence on seeing if it would break anything, and likely just change how this works.
    • Sybren: probably was done because drivers are annoying to set up, but now that the driver editor is more accessible and we can use ‘copy driver’, it’s not much of an issue if a driver is removed (in a predictable way) by Blender.
    • Nathan: priority-wise it’s rather low priority.
  • Nathan: might be good idea to keep track of a “breaking changes wanted” list, so we have a concrete list for Blender 5.0.
    • Module agrees.

Help Needed

Next Meeting

Next week there will be no module meeting due to the Blender Conference.

The next meeting will be on Thursday 2023-11-02T17:00:00Z. Again it will be open for everybody who’s interested. The provisionary meeting agenda will be linked in the #animation-module channel before the meeting.

5 Likes