2025-04-03 Animation & Rigging module meeting

Meetings
1

The meeting will be on 2025-04-03T16: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: Andy Beers, Christoph Lendenfeld, Nathan Vegdahl, Sybren Stüvel, Jeremy Bot, MohammadHossein Jamshidi, Nacho de Andrés, RedMser, Spencer Magnusson, Srivathsav Kyatham

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

  • Blender 4.4.1 is slated for release next week on Tuesday, 8. April.

Landed

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

Blender

Ongoing Work

Patches: Review & Decision Time

  • #136672: Cleanup: Remove deprecated constraints
    • Module approves!
  • #136661: Anim: Freeze Transforms Constraint
    • Sybren: this is fragile, easy to loose the frozen transform.
    • Sybren: we can also make existing constraints easier to use (like Create Empty button?)
    • Nathan: also such a ‘freeze’ constraint like this may make it hard to parent that frozen transform to the armature’s root bone. A rigger may make a nice rig, but when used in practice it might always lock to a world transform and be hard to use. It may be too much of a foot-gun.
    • RedMser: this workflow is coming from animating in other software, where it works well. I’ll have to investigate whether these issues occur there too.
    • Nacho: this is a great leap in the right direction. It could be made safer by using an approach similar to the Armature constraint (which references a transform relative the bone’s rest pose, which is visual and not so easy to lose). Nacho uses this as a more predictable version of the Child Of constraint.
    • Nacho: it would be really nice if the Armature constraint could be set to limit itself to loc/rot/scale x/y/z as well, and maybe even have weights per channel instead of a boolean.

Help Needed

Testing & feedback wanted:

Next Meeting

The next meeting will be on 2025-04-10T16: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

About animating/driving vertex positions, I assume that is exactly what AnimAll add-on is (ab)using, although not sure since I’ve never used it. I would suggest looking into it bit, since it was built-in add-on til 4.2 and lot of people depend on it. Add-on developers might have thoughts about the topic.

4 Likes
3

Ah… that’s a good point. I’ll look into it.

4

I’ve used AnimAll mostly for animating Bezier curves (as a sort of After Effects’ Path Animation replacement for a project). If I need it again, I hope it still works :pray:.

1 Like
5

Ohh, this will be very handy! This one I use it regularly on C4D.

1 Like
6

Isn’t the layered animation system supposed to get a vertex cache layer so that animators can do shot sculpting on the timeline? Won’t that solve the problem of animating vertices?

3 Likes
7

Regarding the Next/prev keyframe Graph Editor hotkeys thing mentioned above I just wanted to point out that this issue of hotkeys needing to be unified and leading to confusion between modes is a larger issue for all of Blender that should ideally be addressed at some point.

I suggested as much in an RCS proposal for 2.7 a few years ago: Right-Click Select — Blender Community

Also highlighted in this walkthrough tutorial of how to create a custom keymap: https://youtu.be/Qfg4Y4rbsXs?si=njb-X72xlvpCsPn0&t=1168

1 Like
8

I understand your point. That’s more for the UI module to deal with than this one, though. Unless you have concrete suggestions for Animation & Rigging specifically, in which case please write them down in a RCS proposal. But avoid “Operations like”, and make the list concrete and exhaustive. That way it’s much easier to discuss, implement, and mark as “done”. Might be a good thing to tackle for 5.0.

9

True, it is inherently beyond the scope of this group. I figured I’d bring it up here since the topic came up in this context. I don’t think I have any module-specific suggestions on this beyond there also being some animation hotkeys that are duplicated between modes (like Insert Keyframe) but for me I would prefer the issue was addressed across Blender.

Should I revise the original general purpose RCS suggestion to be more precise re: which keys would need to be unified? There’s a lot. Or is it fine to leave that one as broad as it is since it concerns basically the entire keymap?

I could update the image to be of the 4.x keymap editor. Is it better to edit a years old RCS page or should I create a new general purpose one for the current version to get more eyes on it?

10

I would suggest making it concrete, in a way that a developer can actually work on it. So indeed, don’t leave it to others to guess which ones you would merge, but list each of them. And also which hotkey then should be assigned. Or maybe whether no hotkey should be assigned, but the operators unified, so that when someone does assign a hotkey themselves, it only needs a single one.

I could update the image to be of the 4.x keymap editor. Is it better to edit a years old RCS page or should I create a new general purpose one for the current version to get more eyes on it?

Update the proposal, because it’s still the same proposal.

Since we’ve gone a bit off-topic for this thread, let’s make this the last that’s said about this. If you want to discuss it further, DM me.

1 Like