2024-01-16 Animation & Rigging module meeting

Meetings
1

The meeting will be on 2024-01-16T11:00:00Z. It is open for everybody interested to join the video call (link below).

Present: Christoph Lendenfeld, Demeter Dzadik, Ivan Cappiello, MohammadHossein Jamshidi, Nathan Vegdahl, Nika Kutsniashvili, Pierrick Picaut, Rik Schutte, Sybren Stüvel

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

Links

Since the Last Meeting / Announcements

  • New face: Nika Kutsniashvili (@nickberckley), from Tbilisi, Georgia. Animator, presented about stop-motion animation at Blender Conference. Teacher as well, and works with shapekeys a lot, so has lots of different views from which to provide feedback.

Landed

Names are from the Git log. These are just the functional changes, no refactors/cleanups are listed unless they are particularly interesting for some reason.

Short-term goals / Ongoing Work

  • High prio bugs: None!
  • Nathan started a list of expected common use cases for animation layers/strips.
    - Use cases to keep in mind for designing the UX for the new animation system.
    - Was thought out before, now written down in a public place.
    - Is for keeping track for ourselves, as designers / builders of the system. Not for the Blender technical documentation.
  • Sybren: Bone Collections “done for now”.
  • Christoph: #115798: Anim: Add hotkey for keying set operators
    • Good to go, code changes have been approved.
    • Daniel Salazar was originally complaining about this missing. He just got back from holiday, so we’ll wait a week for his feedback.
  • Christoph: Talking with Demeter about keyframe insertion API.
    • The idea is to have a function on bones & objects “insert keyframe for transforms”, which will be a short-hand for keyframing the transforms without having to go over each channel, check rotation modes, etc.
    • Christoph: what’s the advantage over keying sets?
    • Demeter: would the new function account for user preferences?
    • Christoph: we could, not sure how to do this on the API level.
    • Nathan: it might be good to have two functions, one that explicitly gets the preferences passed in, and the other that has the default behaviour that’s always the same.
    • Module agrees with Nathan’s proposal.
  • #115915: Very strange constraint jiggling not present in blender 3.6.3
    • Sybren worked on this (branch), on a potential solution suggested by Brecht.
    • Solution seems to work on a test setup and the attached example file, but causes glitches on an actual production file.
    • Glitching is gone with -t 1, so a threading issue that suggests a missing dependency graph relation. That would make this fix quite a bit more complex than anticipated.
    • Christoph: this issue was caused by a sequence of fixes, and we should ensure that these remain fixed. Fixing all of them might not be possible.
    • Nathan: if we can fix it, it would be good to get it fixed. Unless the goal here is to lower the “bus factor” of who understands that part of the code, let’s ask Brecht for help.

Patch Review & Decision Time

  • Need artist feedback on #115525: Anim: Separate keying flags
    • Separates ‘Only Insert Needed’ into two flags, for manual keying vs. autokeying. Makes it possible to create new curves manually, while autokeying only keys on existing ones.
    • Rik is testing, seems to work well so far.
    • Some small issues with the clarity of the preferences UI. Currently there are two groups “manual keying” and “auto keying”. These repeat the same options with the same label, making things confusing when you just scan the labels.
    • Nathan suggests grouping by option instead (so ‘Only Insert Needed’), and then having checkboxes for manual & auto keying. Other options that get split out like this could expand this into a grid.
    • Christoph: There is a test build linked in the PR, please test & give your feedback.

Help Needed

  • 195bb4f8f5: Fix #115192: Inconsistent behavior renaming data-blocks landed. We may want to double-check that renames of bone collections are always doing the right thing.
  • #105243: Cannot limit IK minimum stretch
    • MohammadHossein wants to help fixing this, but couldn’t reproduce.
    • Nathan has run into this issue as well. He used a separate chain with Strech To constraints to work around it.
    • Nathan suspects this behaviour is quite deep in the IK Solver code.
    • Sybren: if we can do this with an absolute limit on the allowed stretch factor, that could be a nice addition. Tricky to get done well, though, as the IK solver itself only supports uniform stretching, and Blender has non-uniform stretching.
    • MohammadHossein: is a different IK solver backend an option?
    • Sybren: for a new implementation in rigging nodes we could, for sure.
    • Nathan: we should! The current solver has a bunch of useful properties that should be preserved, though.

Next Meeting

The next meeting will be on Thursday 2024-01-25T17:00:00Z. Again it will be open for everybody who’s interested. The provisionary meeting agenda will be updated before the meeting.

3 Likes