2024-02-29 Animation & Rigging module meeting

Meetings
1

The meeting was on 2024-02-29T17:00:00Z. It is open for everybody interested to join the video call (link below).

Present: Bassam Kurdali, Brad Clark, Christoph Lendenfeld, David W (Studio Galt Mocap), Eduardo Rubio, Jeremy Bot, Nate Rupsis, Nathan Vegdahl, Raymond Luc, 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

  • This meeting we tried BigBlueButton for the video call. It worked well, didn’t have any video connections drop like we saw with Jitsi.
  • Demeter Dzadik commented on #112635: Proposal: New Bone Color Presets describing the Blender Studio experience with the new colors. In short, instead of having 3 colors that pop, they have 20 colors that are good enough.

Landed

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

Blender

Ongoing Work

  • High Prio bugs:
  • Christoph:
    • Christoph’s weekly report
    • #117287: Anim: Add Sharpness to Ease operator, test build is available, animators please test!
      • Brad: did we ever change or think about the ease type tools working on selected points like og animaide, Christoph?
      • Christoph: yes, OG Animaide operates on all data between the first selected key and the last one. Blender operates on selected keys only.
      • Sybren: select first/last keys could be a good option, but should be a separate tool to ‘select time’
      • Nathan: Source Filmmaker has good options for this too, we should check it out.
    • exploration: #118662: WIP: Rewrite Graph Editor drawing code
  • Nathan:
  • Sybren:
  • Animator meeting at Blender HQ, with Rik Schutte, Hjalti Hjálmarsson, and Pablo Fournier:
    • Continued discussion of the new animation data model.
    • Hjalti & Rik have concerns about the indirection of Outputs, and general perceived complexity of the model. But also acknowledge that some of these things may be needed to accommodate the variety of use cases we’re targeting.
    • Pablo thinks the new data model is already good, and appreciates the flexibility it provides.
    • Hjalti & Rik would like to see if we can simplify the data model or otherwise adjust it to be easier to grasp without hurting our target use cases.
    • Nathan (based on earlier discussion with Sybren) thinks part of the issue is that we need to take time to figure out how to introduce and explain the data model in an easy-to-grasp way. But certainly, the data model itself influences how easy it is to grasp as well, and we need to be mindful of that.
    • Hjalti would like to walk through a realistic (non-trivial) example case, using the new data model. He thinks that would help a lot to really solidify/grasp how it works in his head.
  • Sybren: Regarding the confusion about the name ‘Output’, how about ‘binding’ or ‘pairing’?
    • Jeremy: “binding” feels more like an animation related action. :wink:
    • Bassam: “binding” maybe confusing because it’s also used in other places? Like delta mush smoothing, or mesh deform binding.
    • Nathan: it’s used as a verb in other places, and we’re using it as a noun.
    • Brad: likes “pairing”, but “binding” is also used in retargeting, so could match well.
    • Bassam: getting used to it, fact that we use it elsewhere makes it feel familiar.
    • Nathan: if “binding” is the noun, what is the verb?
    • Sybren: “to bind” the animation with the animated data-block?
  • Sybren: code wise, ChannelsForOut was renamed to ChannelBag (also in celebration of the desire for an ‘IPO Bag’ from ye olde days), and ‘output stable index’ was renamed to ‘output handle’.

Patches: Review & Decision Time

  • #118658: Fix: View in Graph Editor not working when object is unselected What to do when the FCurve is not visible through the filtering code.
    • Everybody has mixed feelings, between “Blender should just do what I tell it” vs. “Blender shouldn’t change people’s filter settings, because they may not even know what changed or how to get it back”.
    • Sybren: showing warning + zooming to where the FCurve should be is the least intrusive option.
    • Christoph: we need proper pinning of FCurves, then we can just pin the FCurve.
    • Brad: let’s go for the warning, and then see how we can improve the thing in the future.
    • Nathan: the message should explain what to do to make the FCurve visible, though. Not just say “cannot show”.
    • Bassam: is there an option to flash the button where the ‘offending’ filter is? So we can visually alert the user what is keeping the curve from being visible? Or alert them what was just changed to make this possible.
    • Sybren: I don’t think that’s possible.
    • Nate: are F-Curves ever hidden by default? Or will this only be a case where the user intentionally hid something?
    • Sybren: I don’t think so – this is more about the user showing “only selected” but the thing is not selected or even cannot be selected (like a World property).
    • Nathan: it might be good to keep the message simple, “Hey the FCurve you zoomed to is not visible because of filters”.
    • Nate: This behavior should also be document in the manual.
    • Decision: zoom there, give a warning if necessary. Improve in future if needed.
  • #118502: Fix #117927: Limit rotation constraint flipping: to merge or not to merge?
    • Nathan: seems like an obvious win to me, but it could technically break rigs that are somehow depending on the old (IMO buggy) behavior. I think the risk of breakage is low.
    • Bassam: votes to merge
    • Nate: should we change this behaviour in 4.1? Or would 4.2 be a better goal?
    • Nathan: agrees, 4.2 is a good target.
    • Bassam: if the old behaviour was indeed so unpredictable, the new behaviour could have actually been the behaviour by chance. I struggle to see how the old behaviour was desirable.
    • Nathan: I strongly doubt anyone is relying on the old behaviour intentionally. It could have been depended on by just toying around until things “work” though.
    • Nathan: the output wasn’t random, though, just hard to predict from a user standpoint.
    • Decision: land the change in the main, release in 4.2.

Next Meeting

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

5 Likes