2025-04-24 Animation & Rigging module meeting

Meetings
1

The meeting will be on 2025-04-24T16: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, Nathan Vegdahl, Sybren Stüvel, David Woolf, Eduardo Rubio, Hassan Charafeddine, Ivan Cappiello, Jeremy Bot, Jonas Holzman, Nacho de Andrés, Raymond Luc

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.

Since the Last Meeting / Announcements

Landed

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

Blender

Technical Documentation

User Manual

Ongoing Work

Patches: Review & Decision Time

  • #137448: Graph Editor-> View Selected → Only 1 Keyframe
    • Proposal is to have a limit on the zoom level, to not zoom in too far.
    • Christoph: makes sense.
    • Sybren: Good to have such a limit, but does it make sense to even zoom to a single keyframe?
    • Christoph: I think it makes sense, like to having one frame to the left & right. Not sure about the Y-axis.
    • Nacho: for the Y-axis it would make sense to ensure that the curve is visible for the previous & next frame.
    • Raymond: when I hit zoom, sometimes I just want to pan, and don’t care about the zooming.
    • Nathan: likes Nacho’s case. There’s another case though, where those keys have the same Y-value, and then they won’t work to set the Y-range.
    • Sybren: maybe we don’t change the Y-range in that case, and just assume that the graph editor was set up somewhat sensible already.
  • time to close #116795: Nested Bone Collections 4.1 Notes?
    • Christoph: Having hotkeys that are specific to a tree view is not currently possible in Blender, so without major changes this isn’t possible right now.
    • Christoph: the other open item (“Removing active item should take hierarchy into account…”) is a bit unclear.
    • Sybren: agrees, let’s ask Demeter if it’s still relevant, and if so, ask for clarification.
  • Should bone envelope radii be allowed to be different at the shared joints of connected bones? Context: #137599: Fix #137398: Transforming editbones can propagate wrong envelope radii
    • Nathan: We can fix this in two ways:
      • Embrace that the radii can be different, and make it work (i.e. remove the code that tries to enforce they are the same).
      • Expand the code that tries to enforce they are the same, and close the avenues by which they can be made to differ.
    • Nacho: This is about connected bones, yes? Nathan confirms.
    • Nacho: We could make this togglable per bone. But this could also be handled by the ‘Connected’ toggle; if you want them to be different, just disconnect from the parent.
    • Nathan: if we want to make the “allow different radii” case work, the drawing code also needs updating, as there currently is no way to visually represent the case.
    • Nathan: how to deal with versioning, if we use that to enforce the same radii?
    • Christoph: so just don’t version this?
    • Nathan: then when they move the bones in edit mode, the radii will snap to be the same, and they won’t be able to get it back to what it was before (except with undo).
    • Sybren: maybe use Nacho’s approach and make those bones disconnected?
    • Nathan: that can break things too, because then the location of the bone becomes relevant.
    • Nathan: leaning towards Christoph’s idea of not versioning. Seem to be the least-bad option.
    • Sybren: likes that too, also because the “snapping” happens when you’re manipulating the bone, and then you see that something happened.
    • Sybren: we could do the versioning, and then land it in 5.0?
    • Nathan: to be clear, even with Blender right now they snap to have the same radii.
    • Sybren: I feel we’re being very careful about something that in practice is already fragile, and where we don’t even know if it’s used in practice.
    • Nacho: people can just disconnect the bone and add a constraint or lock the location, and call it a day. If they were clever enough to find this workaround, they’re clever enough to find the fix.
    • Decision: treat it as a bug, and use versioning to reset the radii to the one of the parent bone.
  • Jonas adds: #131810: UI: Transparent Armature Bone Selection
    • Aras Pranckevičius offered help (offline while visiting Blender HQ)
    • Jonas already has some code to improve things & shows a demo. It prioritizes selection by clicking on the outline. It still allows clicking “through” bones to select others like wireframe mode would do, but without having to draw as wireframes (so face colour can still be used for constraint etc.).
    • When not clicking on the outline, it selects the furthest bone first, then the closest, then continues selecting bones further and further away.
    • Nathan: absolutely loves it, but has doubts about the “furthest bone first” approach. May be mixing up “visually smaller” with “further away”.
    • Jonas: agrees, was testing mostly with overlapping bones, and not with a big distance between them.
    • Sybren: what about prioritizing the visually-smallest bone? So the projected size, not the size in the 3D world?
    • Jonas: could work, but isn’t used anywhere else in Blender. It might be computationally hard to do this.
    • Nathan: suggests splitting this up, into having wireframe/outline-priority as one PR, and then improving the solid-part-click selection. For the solid part we can just do solid-first.

Help Needed

Next Meeting

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