2025-02-27 Animation & Rigging module meeting

Meetings
1

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

Present: Andy Beers, AnimSebs (Dillon Goo Studios), Christoph Lendenfeld, David Woolf, Jeremy Bots, Jorn Boven, Julien Duroure, MohammadHossein Jamshidi, Nate Rupsis, Nathan Vegdahl, Nitin Rawat, Raymond Luc

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

Ongoing Work

Playback Behavior With Scene Frame Range

Sebastian Parborg has been working on fixes with audio-synced playback. While testing, he noticed something odd but unrelated to audio sync:

When you start playback with the frame head earlier than the start frame, playback first jumps to the start frame. However, if during playback you scrub to earlier than the start frame, then playback continues from there without jumping to the start frame. This feels inconsistent, and it seems like we ought to have one consistent behavior for both cases. Which behavior makes more sense?

  • Nathan: note that you can still play outside of the scene frame range if desired by using the preview range feature.
  • Ray: thinks it should snap to the start frame.
    • Module agrees.
  • Decision: always snap to be within the set frame range during playback, including when scrubbing during playback.

Selecting F-Curves in the Graph Editor

Context: #43933 - Graph Editor: (Auto-)Focusing Channels - blender - Blender Projects

With box select, when you overlap with a curve but no keys, the whole curve is selected. When you click-select on a non-key part of a curve, however, nothing happens.

  • Question 1a: is the box-select behavior useful as-is?
    • Jeremy: use it for global adjustments.
    • Ray: what Jeremy said, and also to quickly select a visible curve (sometimes easier/faster than using the channel list) and shift-h to isolate it.
    • Consensus: yes, this is very useful.
  • Question 1b: would it make more sense for it to select the curve without selecting the keys?
    • Nate and Animsebs: what would be the use case for selecting the curve without the keys?
    • Nathan: maybe if you already have keys selected, and you just want to shift-h isolate the curve without losing your key selection? Seems niche, though, and not the common case.
    • Consensus: better to select all the keys as well.
  • Question 2: should click-select follow the same behavior, for consistency?
    • Tons of thumbs up.
    • Ray: I currently work around the lack of this by selecting a key, and then hitting L.
    • Consensus: yes, it should.
  • Decision: box select should keep its current behavior, and click-select should be updated match (so clicking on a non-key part of an f-curve selects the whole curve).

Splitting Up PRs, and Where to Ask Dev Questions

Context: #135062: Auto Normalize functionality for vertex groups (edit mode) and weightpaint operators (weightpaint mode).

  • Andy: I have questions about how and if I should split up an issue into multiple PRs. Where should I ask questions about this (in the chat, in the issue, …)?
  • Nathan: always feel free to ask development questions in the chat. It’s a development channel, and that’s what it’s for.
    • If the questions are specific to a particular issue or PR, you can also ask in the chat, but if you want to keep the discussion in the issue or PR (which is often a good idea) then you can post there.
    • Also, always feel free to poke us in the chat with an @ if you want to make sure we see something (regardless of whether that something in an issue/PR or in the chat itself).
  • Christoph: regarding splitting up an issue into multiple PRs, sometimes it’s not clear ahead of time if/how something should be split up. In such cases, feel free to just dive in with a single PR, and then you can split it up later as things become clearer through actually coding the thing. We do this all the time.

Next Meeting

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

2

I think ability to not snap to range start should be an option. I’ve been abusing that hack with playing first and moving playhead later, because alternative is constantly changing preview range. Sometimes I’m working on part B of the animation and have preview range there, but want to quickly see part A for reference, and if playhead insisted on jumping I would have to change preview range to part A, see, and then change it back to where it was, it’s quite annoying.

2 Likes
3

That’s a fair point, and a use case that we didn’t consider during the meeting. We can certainly consider making it an option, but if we can avoid adding yet more behavior options I think that would be preferable.

I do think that (option or not) the behavior when starting playback and the behavior during playback should match each other, though. It feels odd to me if those behaviors are different, and it makes the during-playback behavior rather hidden IMO.

4 Likes