2025-05-22 Animation & Rigging module meeting

The meeting will be on 2025-05-22T16: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.

Present: Christoph Lendenfeld, Daniel Salazar, David Woolf, Jean-Silas Moor, Spencer Magnusson, Sybren Stüvel

Links

Opening

  • Please raise your hand when you don’t understand things for any reason. The purpose of these meetings is collaboration. It is absolutely fine to ask for explanations.
  • There are no recordings of the meeting. This way everybody is free to say or show anything they want.

Landed

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

Blender

Technical Documentation

Ongoing Work

  • High Severity bugs:
  • Christoph:
    • Christoph’s weekly report
    • #137274: Anim: Expand the Select Grouped operator in Pose Mode
      • Implemented first set of operators.
      • What about the “these should be discussed” ones? (:white_check_mark: = approved in the meeting, :x: = chosen not to implement for now)
      • Same as select parent/children, but then when those relationships are made with constraints:
        • :white_check_mark: Constrainers: select all bones that are used as targets of constraints on the active bone
        • :white_check_mark: Constrainees: select all bones that use the active bone as a constraint target
      • Same as Select (Immediate) Children, but limited to connected bones:
        • :x: Connected Children: Could be an option of the Children operator.
        • :x: Connected Immediate Children: Could be an option of the Immediate Children operator.
      • Some operators that were found useful, but shouldn’t be in the “Select Grouped” operator because they don’t relate to the current selection:
        • :x: (Non) Deforming: select all bones that have the same “Deform” value as the active bone (so if active bone is non-deforming, select all non-deforming bones). Could also just be two menu items to explicitly select all (non) deforming bones.
        • Sybren: these could also have to go there, instead of in “Select Grouped”. I’m sure game animators will like these, as a sanity check on their rig:
          • Non-uniform Scale: select all bones with non-uniform scale.
          • Scaled: select all bones with non-unit scale.
    • #139167: WIP: Anim: Store pose bone visibility flag on pose bone Will allow saving pose bone visibility on linked armatures (and fix armature instances)
    • #139271: WIP: UI: Icons for playhead snapping follow up to playhead snapping
  • Nathan:
  • Sybren:
  • Animator meeting at Blender HQ, with Rik Schutte, Hjalti Hjálmarsson, Demeter Dzadik, and Julian Eisel (briefly):
    • Demeter: Ivan Capiello & Francesco Siddi talked about gizmos for bendy bones.
      • Julian: gizmos are a pain to code. Nobody in the UI module is available. Maaaybe Campbell has some time.
      • Demeter is going to start a design discussion on devtalk, making it clear we’re looking for somebody in the community to implement this.
      • Julian: it’s fine if the gizmo is coded in Python.
    • Daniel asked in Blender Chat about per-bone “In Front” options.
      • Demeter: is interested for deform bones, as control bones already have a ‘surrounding’ custom shape.
      • Hjalti: not interested in this extra complexity. Demeter: for animation, sure, but for rigging/weightpainting this could be handy.
      • Nathan: we have to be careful to balance ‘power’ and ‘complexity’.
      • Sybren: shouldn’t this be the opposite option, like “Ignore In Front” for the control bones? That way you can still have a global “in front” option for the armature, and some bones just don’t listen to it. Maybe an enum (“always in front”, “never in front”, “use armature setting”).
      • Hjalti: isn’t this more of an “in the moment” thing, where it’s more about bone selection than anything else? Demeter agrees. Nathan likes bone collections for this.
      • Nathan: let’s check with Daniel (ZanQdo) what is actual use case is.
      • Rik: bone picker, please!
      • Continuing in module meeting:
      • Daniel: shows demo of a character with tweak points that are inside the mesh. These points are usually not visible, and are inside the mesh because they manipulate the ‘blobby character’ from the centre, and having more rings around the character would cause more visual clutter.
      • Daniel: would also love solid mode drawing for custom bone shapes.
      • Sybren & Christoph wouldn’t know a technical reason why the shapes should be limited to wireframe only.
      • Sybren: discusses the enum idea (see above)
      • Daniel: the “never in front” could be confusing, object-level “in front” should just “in front” the entire object.
      • Daniel: Luciano says we could remove the Armature’s “in front” option completely, as we have Armature X-ray as well.
      • Sybren: that could work.
      • Daniel: changing object settings just for these short-term visualisation choices is weird.
      • Christoph: The “in front” option is on the Armature object, not on the Armature data. We can still add the per-posebone option.
      • Sybren: if we name the option “Always In Front”, it’ll help to see the relationship with the object-level “in front”.

Patches: Review & Decision Time

  • #139164: ANIM: optimize proportional editing many keys in the Graph Editor
    • Sybren: With proportional editing, when the key & handles are not selected and thus affected by the proportional falloff, should the key and the handles move in unison? Currently Blender affects them separately based on their position. Moving in unison is likely better for animators, and certainly for performance.
    • Christoph: the original code already only compared to the “center” point (in transform system terminology), which is always the key itself.
    • Sybren: great! Then I misunderstood, and the code is doing what I thought was a good idea (just in a bit too-elaborate-for-my-brain-at-the-time way).

Help Needed

  • #113364: Indicate Parent Inverse Matrix State in UI
    • Sybren: Conceptually good to go. However, the implementation should move from Python to C++ as that’ll be significantly less heavy. Currently custom properties are used, including duplicating some data (like the object’s rotation mode), just to be able to draw the UI. From C++ this could happen directly.

USD Nerding

Jean-Silas asks about extending Blender’s USD support to be more transform-stack aware.

  • Jean-Silas: USD object transforms consist of arbitrary stacks of transforms. Currently there’s workarounds to expose this to Blender, but they are often aimed at specific people (like for artists, or for archviz, but nothing that suits everybody).
  • Jean-Silas: a nice start would be to export Blender’s Delta Transform and Parent Inverse matrix as transform stack. And to improve the tools to author Delta Transform & Parent Inverse, as there are no gizmos for that. He has seen at least 5 different studios build custom tooling for that, but they never send those back to Blender.
  • Sybren: would love better tools for these. One of the long-term goals of the module is to bring Objects and Bones closer together. Delta Transform is basically for objects what the rest pose is for bones.
  • Sybren: exposting these to USD would be a natural fit
  • Jean-Silas: and doesn’t add yet more lists-of-checkboxes to the importers/exporters.
  • Jean-Silas is going to poke around and see if he can enthousmise people to work on this.

Next Meeting

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

2 Likes