2023-07-13 Animation & Rigging module meeting

Meetings
1

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

Present: Bassam Kurdali, Brad Clark, Christoph Lendenfeld, Jason Schleifer, Nate Rupsis, Nathan Vegdahl, Paolo Amadini, 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

Short-term goals / Ongoing Work

Patch Review & Decision Time

  • #110067: Library Override: Change handling of Animation Data when it exists in both liboverride and linked reference IDs
    • Jason: It would be expected that the animated channels are kept, and work on top of the linked-in animation data.
    • Bassam: How ‘fixable’ is the situation in either scenario? Given that it’s likely that there is a single solution that covers every use case, how easy is it to notice and recover from any data loss?
    • Bassam & Sybren: the big issue is drivers, you cannot have them in the rig file AND change in the anim file.
    • Nathan: what’s written in report is a bit confusing, is different than what was discussed in person earlier when it comes to the drivers.
    • Brad: looks related to #109483: NLA tracks become zombies (can’t be killed nor edited) if you append data from a file where these Tracks were overides on a linked armature.
    • Conclusion: proposal is OK, keeping the overridden animation is more important. If drivers can be merged in (for example when override did not add any drivers at all), that would be even better. Nathan and Sybren will talk with Bastien further about clarifying the driver situation.
  • #109182: Fix #100718: NLA Hold Forward Inconsistency
    • To decide: Target 3.6.1 LTS?
    • Nate: will dig into it to see if the versioning can keep the current behaviour, then 3.6.1 is OK.
  • Brad: Duplicating a strip also duplicates the Action. You’d need to do ‘Duplicate Linked’ to get a copy of the strip that references the same Action.
    • Nathan: This is consistent with other duplications in Blender; duplicating a mesh object also duplicates the mesh itself. I see the NLA workflows and the interface as different enough to diverge for this, though.
    • Bassam: duplicating a texture node doesn’t duplicate the image it refers to.
    • Nathan: also when you duplicate a Node Group node, it doesn’t duplicate the Node Group itself.
    • Paolo: even worse, the menu items for the Duplicate and Duplicate Linked operators have the same tooltips.
    • Nate & Pierrick: altering this behavior for sure is a 4.0 change, not for 3.6.
    • Module agrees this would be a good change.
    • Nate will take a stab at it.
    • Nathan: maybe look at the node editor to see what hotkeys the node editor have, for consistency. He looks it up, and both Shift+D and Alt+D do exactly the same thing: ‘Duplicate Linked’.
    • Brad: maybe update the manual for 3.6?
    • Bassam: maybe we don’t even need a hotkey for ‘deep’ Duplicate. If you want to duplicate the Action, just duplicate the Action afterwards.
    • Brad in a random exploration just found how to ‘un-stash’ an Action, by shift-clicking on the X in the Action editor. That only works in specific situations, though.
  • #108142: Animation: Graph Editor Handle Selection
    • Sybren: What would be good selection-manipulation operators in the graph editor?
    • Brad: box select has a ‘select handles’ option, but doesn’t seem to work well.
    • Sybren: move back & forth between keys and handles? Like “I don’t care what of the key is selected, if it has any selection, move that selection to just the left/right handle”. Module agrees this would be useful.
    • Sybren: reminds him of Jason talking about Oct 2022: “I have index finger selected, now move selection to the next finger”
    • Brad: shares pickWalk | brave rabbit
    • Jason: would be good to have handle selection or key selection as a mode / filter. Like three toggles, ‘left handles’, ‘keys’, ‘right handles’, and those influence what gets selected when you use other tools (box select, etc). Could be very nice to disable selection of the keys themselves, and only be able to manipulate handles.
  • #109976: WIP: Armature Collections
    • To decide: do we want a ‘default’ collection that implicitly contains all the bones not in other collections? This turns out to be a technical challenge in the face of library overrides, adding new bone collections, and assigning existing bones to them.
      This would create a disconnect with bone layers, where every bone exists at least on some layer.
    • Sybren: probably technically easier to always add new bones to the active collection.
    • Pierrick: would be consistent with modeling workflow.
    • Nathan: what if you delete a collection? Sybren: move to the top collection. Makes sense once we add hierarchical collections, as then the top one is the ‘root’ of the tree, just like scene collections.
    • Nathan: having default collection that you cannot delete is fine. Sybren: meh. Let’s make the root one special once we have hierarchies, and otherwise just allow deleting any bone collection (as long as there’s always one left). Module agrees.
    • To decide: how to pick a bone color when it’s in multiple colored collections.
    • Brad: school paint scenario: it becomes muddy brown.
    • Nathan: last or first one wins is fine, it’s arbitrary anyway.
    • Bassam: make the color a property of the bone, and not the collection? Would be consistent with objects and per-bone custom shapes.
    • Nathan: we might want to have other properties per bone as well, like the bone shape (mostly bbone vs. normal bone).
    • Nathan: bone colors as categorisation is easier per collection, for adjusting later.
    • Bassam: maybe something like a material system, that can be assigned to each bone. Then you still have a single thing to edit that’s referenced by all the bones in the collection.
    • Nathan: we could even re-brand the current bone groups as “bone materials” and have the bones point to them.
    • Brad: as long as we can see the color in edit mode.
    • Sybren: bone groups live on Object, so makes it possible to have shared Armatures but still have the bone colors contrast the mesh color, but on the other hand makes it hard to use in edit mode.
    • Sybren: custom bone shapes are on the pose as well.
  • Paolo is going to have limited availability, anyone should feel free to take over his PRs.

Next Meeting

The next meeting will be an off-schedule meeting on Tuesday 2023-03-18T11: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.

6 Likes