2025-06-12 Animation & Rigging module meeting

Meetings
1

The meeting will be on 2025-06-12T16: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, Daniel Salazar, David Woolf, Dorothee Dittrich, Drew Medina, Eduardo Rubio, Nacho de Andrés, Nate Rupsis

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:
  • Nathan:
  • Sybren:
    • Sybren’s weekly report
    • Daniel Salazar commented on #138339: VSE: Swap shortcuts for next and previous strip jump about being consistent with key bindings.
    • Should we expose the FCURVE_INT_VALUES and FCURVE_DISCRETE_VALUES flags to the user interface? If so, how?
      • Christoph: these should be exposed to the UI+Python. Even for debugging sake. But also it’s so important, these flags change the behaviour so much, users should have this under their control.
      • Nathan: agrees, but do we want to expose them as they are now? That would imply they stay working this way. These two boolean flags are related, and actually represent an enum with three options.
      • Sybren: agrees, thought in that direction as well.
      • Module agrees to add this to 5.0
    • #140291: Fix #139762: Deleting an F-Curve from NLA strip in tweak mode crashes
      • main moved to 5.0, so we can start removing code that handles legacy Actions.
    • How do we want to deal with references vs. pointers, when nullptr is not a valid value? Use references in new/updated code? Or just stay consistent with surrounding code, and do “everything” in one go at some point? Context: #139496: Refactor: Replace PBONE_SELECTED macro with functions.
      • Nathan: we all want to get the code into a state where pointers are only used where nullptr is valid.
      • Nathan: incrementally makes more sense, because we won’t have the time to do a big refactor. Doesn’t have to be super strict though.
      • Christoph & Sybren agree.
  • Mini-meeting with Clément Foucault, Pablo Vazquez, Nathan, and Sybren, about the ‘Bone Wireframe Opacity’ setting in weight paint mode.
    • Clément: this option was accidentally made available not just in wireframe mode, but also when the Armature Object was set to “Display as: Wireframe”.
    • #139919 proposes to make the option available in all modes, not just weight paint mode.
    • Clément: This would add yet another way to hide the armature, which negatively impacts selection state visibility. And it broadens the impact of the mistake, instead of fixing it.
    • People present agree.
    • Sybren: it would also make sense to have this option available in other draw modes as well (still limited to weight paint mode). Wireframe draw mode in weight paint mode is not even really drawing wireframes, and having a semi-transparent armature will help in Solid mode too.
    • Conclusion: Clément will fix the glitch, the opacity slider becomes once again specific to Weight Paint mode, and will be moved into the Armature Overlay options (instead of the general Overlay options).

Patches: Review & Decision Time

  • #139576: Graph Editor: Home keybind zooms incorrectly if there is an Envelope F-curve modifier Should we consider this a bug and how would we fix it.
    • Sybren: The “Limits” modifier also hides the keys.
    • Nathan: Suspects that this is not a thorough design, just what the developer thought useful at the time.
    • Dorothy: I like to see my keys.
    • David agrees.
    • Sybren: This is not a bug (works as designed), but we should address this.
    • Christoph: even better, the keys aren’t shown, but you can still edit them.
    • Module agrees.

Questions from Nathan

  • What (if anything) should we do about #138471: Additive constraints and cumulative floating point rounding error?
    • Nathan: This is a fundamental issue that shows up in Blender in various places. There is no straight-forward way to easily solve this.
    • Nathan: For the constraint system, it would mean making them work with double floating point precision.
    • Nacho: this also affects meshes, for example with an Armature modifier. Adding a parent that’s close to the mesh helps, because then the local coordinates are still small.
    • Sybren: this is something to discuss with the Core module, because of the limitation existing in many areas of Blender.
    • Nathan: the general issue has been discussed already.
    • Sybren: Nathan, you also mentioned some time the idea of breaking up the transform matrix into multiple parts, using double for the translation and still using float for the rest.
    • Nathan: for constraints that’s probably not necessary, as there won’t be that many matrices allocated.
    • Sybren: are there already math functions that handle doubles?
    • Nathan: most of the relevant ones are there.
    • Sybren: thinks it’s worth doing. Question is just “when”.
    • Sybren: put it on the workboard, when that gets a little bit shorter we can reprioritize.
  • When keying geometry nodes, should the animation data go into the same Action as the object the geonode modifier is for? (Note: not all geometry node trees are for modifiers.)
    • Sybren: we also should add the UI panel for assigning Actions and Slots to node trees.
    • Nacho: how do you get per-object animation, when multiple objects share the same geonodes trees?
    • Sybren: via custom inputs for the geonodes modifiers. Animating them would be on the object level.
    • Nacho: then having the node tree animation itself in its own Action is fine.
    • Sybren: then the Action editor should get pinning, so that you can see & edit the Action without assigning it to an Object.
    • Nathan: re-focuses the discsussion to whether the Action of a geonodes tree should be going to the same Action as the Object that owns the modifier.
    • Nathan: similar to keying Mesh Data, if that doesn’t have an Action yet but the Object does, it’ll create a new slot on the Object’s Action.
    • Sybren: that only happens if the Mesh is not reused by multiple Objects.
    • Sybren: tricky to apply the same to node trees. They can be the “top-level” ones owned by the Modifier, but also potentially-reusable ones deeper in the tree. When we key Object properties, do we also search for Actions in the node tree hierarchy?
    • Nathan: contrary to material’s shader node trees, the geonodes node trees are not “embedded”, so all can be reused / swapped out.
    • Nathan is leaning towards: leave the behaviour as-is. When keying something inside the tree itself, let the tree have its own Action. When you want the keys to go to the Object, expose those parameters as custom properties of the modifier.
    • Christoph: agrees with Nathan. We more intuitive ways to work with Slots, for example with the outliner. People should be able to move data around the way they want.
    • Sybren asks animators for feedback, but nobody really has an opinion. So let’s implement the above, make things clearer in the UI, and then people have a better basis to form an opinion.
    • Nathan is going to add the Animation panel to the geonode trees UI.

Next Meeting

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