2025-03-27 Animation & Rigging module meeting notes

Meetings
1

The meeting was on 2025-03-27T17: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: Aras Pranckevičius, Christoph Lendenfeld, David Woolf, Dorothee Dittrich, Nathan Vegdahl, 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.

Since the Last Meeting / Announcements

  • Blender 4.4.1 is likely to be released early April.

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

  • Blender Artists post about having separate keyframe transform snappings for the drivers editor.
    • Christoph: do people think this is a good idea?
    • Sybren: yes, makes sense to separate those.
  • Missing option to duplicate a Slot with its animation data. Should the “New”/“Duplicate” button just do that, when there is a slot assigned? Got this feedback on devtalk.
    • Module agrees.

Help Needed

  • Mass F-Curve creation API. Aras noted (in the chat) that mass F-Curve creation is now quadratic in complexity, due to the uniqueness checks done for every individual curve. Should be fairly simple to create a function that takes a Span<FCurveDescriptor> and returns a Span<FCurve*> where ensuring uniqueness is left to the caller.
    • Aras is going to try and create a PR.
  • Andy: asks for more background info about slotted Actions, so that he can jump in and help when there’s bug reports.

Next Meeting

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

3 Likes
2

Coming back to this: in the middle of the discussion I didn’t really know how to respond to this, but I’ve collected my thoughts a bit better now.

There are plenty of properties that aren’t animatable in Blender. The PROP_ANIMATABLE flag in RNA exists in order to indicate which properties are and aren’t animatable.

A bit of historical context: Blender 2.5’s “everything animatable” mantra wasn’t literal, but rather stemmed from how extremely limited the set of things you could animate in Blender 2.4x was. There were so many things that obviously made sense to animate, but you couldn’t simply because each individual case had to have animation support added by hand.

The goal with 2.5 was to open the flood gates for all of those things by just having animation supported on properties by default. However, if it didn’t make sense to animate something, or if it couldn’t reasonably be supported for underlying technical reasons, things could of course still be marked non-animatable. That was part of the design.

Maybe it still makes sense to allow directly animating and driving vertex positions, but I’m not yet personally convinced. It feels to me like a simple oversight in disabling their animatability in RNA, which is a common mistake in Blender because animatable has been the default since Blender 2.5. For example, you used to be able to animate the render output file format, switching from PNG to MP4 mid render (with very odd results) until it was eventually fixed by marking it non-animatable.

Of course, animating vertex positions conceptually makes a lot more sense than animating the render output file format. However, that doesn’t necessarily mean that directly animating them (as opposed to animating them via modifiers, shape keys, etc.) makes technical sense in Blender right now.

In fact, it turns out there are a plenty of weird things you can keyframe on meshes right now via the outliner, including things that change the topology of the mesh (such the vertex indices of mesh edges) which don’t make much technical sense to directly animate. Which further leads me to think that this is all just a PROP_ANIMATABLE oversight.

I guess I’m basically just concerned that we may be leaning into trying to make something work that was never intended to, and that this may have knock-on consequences later as we then have to support it.

1 Like
3

Let’s have further discussion on this topic on the bug report, so that subscribers are notified:

#132423: Crash/Freeze when having multiple drivers on vertices positions

1 Like
4

Good point, thanks! I’ve re-posted there.