2025-02-13 Animation & Rigging module meeting

Meetings
1

The meeting will be on 2025-02-13T17:00:00Z. It is open for everybody interested to join the video call (link below).

Present: Andy Beers, Christoph Lendenfeld, David Woolf, Felipe G, Nacho de Andrés, Nathan Vegdahl, Sybren Stüvel

People present are referred to by first name for brevity. Others are referred to by full name.

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 Prio bugs: None!
  • Christoph:
    • Christoph’s weekly report
    • Benchmarked Blender with the Shapekey testfile from Rik Schutte
    • Worked on documentation for the pose library changes in the manual
    • Looked through all reports with “Needs Developer Info”
    • Working on bugfixes
      • #110650: Drivers of sub-ID properties do not get removed along with the sub-ID working on a fix to remove drivers on various data
      • failed to fix #97852: Bone weights dont normalize from assign automatic from bones
        • Christoph: This is tricky when new bones have been added since the last time the “Assign Automatic Weights” was done (for example when bones were subdivided).
        • Christoph: Currently normalization is applied as a whole, while it should keep the weights for the already-existing bones should probably not change.
        • Sybren: probably best to act as if the pre-existing groups are locked, and then only allow altering the weights for the new vertex groups.
        • Nathan: also wished in the past to be able to just re-do the automatic weight calculation for just a selection of bones.
        • Christoph: you can, but it doesn’t respect normalisation.
        • Andy: will work on this one.
  • Nathan:
  • Sybren:
  • Animator meeting at Blender HQ, with Rik Schutte, Hjalti Hjálmarsson, Pablo Fournier, and Dalai Felinto:
    • Hjalti: Copy-pasting bones (in Armature Edit mode) is severely borken. This includes copy-pasting drivers and driver modifiers. Copying might work, but pasting just crashes Blender.
    • Rik: discussed with Dalai, to see how addressing these could be planned in:
      • the auto-normalization issues (see last meeting notes)
        • Rik: This would cover operations in the Mesh Edit mode too.
        • Dalai: Currently auto-normalization only works on vertex groups that are associated with deform bones.
        • Nathan: This is currently the only way to make this work, because there are vertex groups that should never be included in the normalization (like mask groups for clothing, left/right side, etc).
        • Hjalti: it would be nice to have a choice when manipulating weights, just a little checkbox to turn on/off normalization.
        • Dalai: it would be nice when, in Weight Paint mode, selecting a vertex group in the properties editor would automatically select the active bone.
      • shapekeys (multi-selection, soft limits on influence)
      • ‘Override Transform’ of bones with custom bone shapes (i.e. based on other bones’ transforms): the gizmo & pivot points aren’t using that custom bone shape’s transform, though. This gets in the way of using them for face controls that follow mesh deformations.
        • Nathan: that’s a very challenging problem to solve.
        • Sybren: there’s shortcuts we can take, but those always have downsides. When you start manipulating the widget, fix the pivot point at the control position.
        • Two flavours discussed:
          1. Draw the control shape where it is placed due to the mesh deforming. This has the downside it doesn’t follow your input, but it does stay put when you release the mouse.
          2. Draw the control shape where the input would move it. That may feel more direct, but when releasing the mouse, the control would snap to its “real” position.
        • Option 2 sounds good to the animators.
        • Rik: another issue is that they can the ‘Override Transform’ only point to bones of the same Armature, and not to Empties.
        • Nathan: probably to avoid dependency cycles.
        • Rik: they’d never be used as deformation bones, their only reason for existence is to be a control bone.
        • Nathan: doesn’t matter, Blender just sees Armature controls Mesh deform, and Mesh deform then can’t loop back to the Armature.
      • Hjalti has two feature requests about parenting Mesh to Armature:
        • Missing option “Make Vertex Groups based on Bone Selection”.
          • Christoph: it’s already a long menu. It might be more flexible to just parent the armature, and then in pose mode say “auto-weight these bones”. If that’s not possible, we should make it.
          • Sybren: agrees, is in line with Ton’s philosophy of having atomic, independently usable tools.
        • Clarify the “Armature Deform” option. Maybe make that just a header (and not a choice) and make the “With Existing Vertex Groups” the wording for that choice.
        • (and while discussing this: “With Empty Groups” does not actually empty the existing groups. Nathan: “Add Missing Groups” would make sense; Hjalti would be a bit confused about the “missing” part – missing from where?)
        • Other options are also a bit unclear w.r.t. what happens with pre-existing groups.

Patches: Review & Decision Time

  • #91134: Change autokey preferences “Only insert available” to “Only insert keyframes on existing F-curves”
    • Nathan: likes it
    • Christoph: only concern is that it’s a lot longer. But it’s also a lot clearer.
    • Nathan: we can workshop it a little bit to condense it a bit.
  • #86109: driver on an NLA animated time strip isn’t purple and cannot be removed
    • Christoph: Are drivers on NLA strips supported?
    • Sybren: I don’t see why it wouldn’t work, if it can be animated it should be fine.
    • Nathan: Is the depsgraph relationship built correctly right now? If not, how much work would it be to do that?
    • Sybren: wonders how this interacts with toggling tweak mode, and the time offset used by the graph editor & dope sheet.
    • Christoph: is going to make it work, but timeboxed. If it takes too long, we’ll leave it for when we do layered Actions.
  • #129210: After removing a shape key with animated value and creating a new one, the animation keyframes are copied to the new one
    • Christoph: Should this be marked as a known issue? Deleting animation data when a shapekey is removed can have a negative impact because the action might be re-used somewhere else. Either currently or marked as a fake user to use later.
    • Sybren: basically same as #110650: Drivers of sub-ID properties do not get removed along with the sub-ID
    • Christoph: drivers are stored on the owning data-block, but F-Curves are stored in the Action. That might have multiple users, or be meant for re-use. We may not want to delete F-Curves here.
    • Nathan: do the F-Curves target the shapekey values by name or by index? Christoph: by name.
    • Nathan: the unexpectedness of animation data surviving is probably less bad than losing the data when this is a shared Action.
    • Sybren: what happens when you animate & then delete a modifier? Christoph: the animation stays around.
    • Nathan: and when deleting a bone? Sybren: the animation stays.
    • Christoph: with material nodes, deleting the node also deletes the animation.
    • Nathan: in the future it might be a good idea to revisit this, to get a more defined vision on how to handle this.
    • Decision: for now, keep things as they are, and keep the animation around.
    • Nathan: looking at one of the use cases for Actions as an animation library, deleting this data would work for the currently-assigned Action, but would leave the other Actions in an inconsistent state. Even when keeping the animation data around is a bit weird, the library as a whole is consistently weird.
  • Felipe: proposes an option for Bendy Bones, making the custom shapes easier to work with: suggestions for the future of bendy bones in blender - Google Docs
    • Sybren: asked for a bit more clarification on the scope, and the impact on properties / matrices / etc.
    • Sybren: in general great that you make BBones more convenient to work with!

Next Meeting

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

2 Likes
2

Well, you would also use this if you want to deform by envelopes only, no? (with the additional required step to check “Bone Envelopes” in the modifier). Stumbled over this in #134687 - Ctrl-P "Armature with Envelope Weights" Does not use Envelope Weights - blender - Blender Projects

3

Functionality wise, we should probably have these listed as options?

  • Armature (modifier using [existing] vertexgroups)
  • Armature (modifier using envelopes) ← that one is new even
  • Armature (modifier using [existing] vertexgroups, create empty vertexgroups for bones with no corresponding vertexgroup)
  • Armature (modifier using vertexgroups created from envelopes [overwriting existing vertexgroups])
  • Armature (modifier using vertexgroups created from bone heat [overwriting existing vertexgroups])

But yeah, the wording… some of it could go into the enum tooltip…

4

You would, yes.

With all the different options, I’m thinking that there might actually too many options in there. Some of these absolutely make sense to have (well, all of them make sense); I think some other options could be covered by the “Armature (modifier using [existing] vertexgroups)” one, and then have operators to manipulate those vertex groups:

  • Vertex Groups from Bone Heat
  • Vertex Groups from Envelopes
  • Vertex Groups for all Bones (would keep existing bone groups, and create zero-weight groups for the rest)

That way it’s easier to manipulate those vertex groups, without having to go through the parenting menu (potentially requiring un-parenting and re-parenting). It would also make it possible to do these operators for selected bones only, giving even more control than the current approach.

5

I actually like the “only use operators to get vertexgroups/weights” approach (compared to having this as options for the parent operator). We have operators for the first two already, would just miss the “Vertex Groups for all Bones” op.

Not sure how long-time users feels about this (in practice, this would leave us with these two options for parenting (only)

  • Armature (modifier using [existing] vertexgroups)
  • Armature (modifier using envelopes) ← that one is new even
6

I think for convenience the “with automatic weights” option should be retained as well. I think it’s the most commonly used one.