2024-04-11 Animation & Rigging module meeting

Meetings
1

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

Present: Bassam Kurdali, Christoph Lendenfeld, David W, Eduardo Rubio, Luciano Muñoz, Nacho de Andrés, Nate Rupsis, Nathan Vegdahl, Nika Kutsniashvili, 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

  • Change in workflow for developers: committing directly in main is going away, going via a PR is preferred. That way the buildbot can build, and we get less intrusive “oopsies” with unforseen inter-compiler differences.

Landed

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

Blender

incoming from others:

Technical Documentation

Ongoing Work

Active-and-unselected discussion

  • Sybren: people feel strongly about this both ways, some use active-but-not-selected as an easily togglable pivot point.
  • Nacho: could it be a toggle? Is in the same vein as left-click or right-click select. Sybren: could be an issue for developers, making workflows harder. Bassam: I’m against an option, but would be ok with it changing.
  • Luciano: despises the current can-be-active-but-not-selected
  • Bassam: agrees the current behaviour is confusing, especially to new users.
  • Nate: we can go for Brad Clark’s suggestion of actually implementing this, and seeing how loudly people complain :slight_smile:
  • Bassam: could there be a separate ‘highlight mode’ that makes it more clear that there is something active but not selected? Luciano: agrees, it’s hard to distinguish these bones. For objects it’s a bit clearer due to the visibility (or not) of the object origin.

Patches: Review & Decision Time

  • #120411: UI: No way to provocate real time updates of Scene Duration in Status Bar The current frame of the scene duration doesn’t update during playback. Is that something users are missing?
    • Christoph: redrawing the footer takes time, as it needs to also update mesh statistics.
    • Sybren: fine to keep it as it is now.
    • Luciano: Profiling & fast animation is important. In the viewport, showing the playback info (FPS) as efficiently, so without all the mesh stats would be good.
    • Sybren: so better not, as it’s just the frame number, which can be found in different places as well.
    • Decision: file as ‘known issue’, with the extra info that if it can be redrawn without re-fetching all the other info, that would be preferred.
    • Nathan: can imagine that memory usage during playback would also be nice.
    • Sybren: all the stats could be useful to see during playback, in certain cases, for certain people. So that shows this is not a bug, but a feature that should be carefully designed.
  • #119376: Theme colors for time visualization What colors should be used to display past/future data and where should that setting be located (personal theme, or somewhere in blend file, or both?).
    • Christoph: currently the colors are just picked from other theme colors, like the “active vertex color” for the keys on the motion path.
    • Christoph: chose pure red & green, because that’s what Krita uses. Sybren suggested this were “programmer colors”.
    • Nathan: likes a “heat thing” where things cool down over time: “warm” is for “before” and “cold” is for “after”. Sybren likes that.
    • Nika: Falk asked about this in the Grease Pencil module chat as well. Matthias Mendiola suggested red & green, because that’s what almost all 2D animation systems use.
    • Nacho: what does Grease Pencil use now? Consistency would be good. Christoph: muted green for “before” and somewhat purple for “after”. Nika: that’s an awful choice.
    • Nathan: for my type of red-green colorblindness, these particular shades are easily distinguished.
    • David W: Future blender orange, past, maya turoquiose
    • Nathan: not for this PR, but maybe some subtle motion in the color (like old-style palette based color shifts) would be nice to have, as an option.
    • Luciano: having speed/acceleration based colors would also be nice – for the future.
    • Christoph will make a PR with a test build, to see things in practice.
  • To re-visit & see where we are: #84901: Curves Interactions in the Graph Editor for another time.
  • Got some useful feedback about the Select Key / Handles operator in Select Handles operator doesn’t remember preferences from previous call #119487.
    • Should we add “Select Left Handle” and “Select Right Handle” to the graph editor selection menu as well?
    • Nathan: additionally, I think this partly comes down “it’s hard for users to create their own menu items for operators with specific parameters set”.
    • Nika can send a PR to add two more operator “Select Left Handles” and “Select Right Handles”.
    • Nathan: “Select Bone Handles” currently doesn’t de-select the key. For “Select {Left/Right} Handles” it should probably deselect the key.
    • Nika: The operators should probably just delesect the key and select whatever handle it should. With shift pressed it could then keep the keys selected as well.
    • Sybren: Might work well in a pie menu? Or with a toolbar with buttons & icons that visualise what they do. But that’s not really something the UI module likes.
    • Nathan will add the menu items.
  • #120519: Anim: don’t include handles when calculating FCurve bounds in Graph Editor How much are the scrollbar-sliders in the Graph Editor used and would it matter if they didn’t account for key handles
    • Making the scrollbars not take handles into account, makes the drawing 20% faster when there is lots of keys.
    • Bassam likes it, more than the possiblity of having to scroll
    • Christoph will make test build.

Help Needed

Next Meeting

The next meeting will be on Tuesday 2024-04-16T10:00:00Z. Again it will be open for everybody who’s interested. The provisionary meeting agenda will be updated before the meeting.

5 Likes