2024-05-30 Animation & Rigging module meeting

Meetings
1

The meeting will be on 2024-05-30T16: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: Christoph Lendenfeld, David W, Eduardo Rubio, Luciano Muñoz, Nathan Vegdahl

Links

Since the Last Meeting / Announcements

  • Bundled add-ons are now on the extensions platform.
    • Copy Global Transform and Pose Library are “core add-on” and cannot be turned off any more (evil laugh).
    • Sybren Stüvel claimed Bone Selection Sets.

Landed

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

Blender

Add-ons

Technical Documentation

User Manual

Ongoing Work

Demo Time: Fixed Margin for Timeline / Dope Sheet / Graph Editor

Sybren Stüvel put together #122320: Anim: use fixed margin for Timeline / Dope Sheet / Graph Editor and wants feedback. Let’s take a look!

  • Luciano: I actually prefer the wider margins of the old behavior. The margin is too tiny now.
  • Eduardo: I also think it’s too tiny.
  • Nathan: the new margin is too small, but the old one is too large on typical editor sizes. The issue is that the old behavior is relative, so it depends on the width of the editor. Tiny editor = tiny margin, large editor = large margin.
  • Luciano: isn’t that good, though? E.g. if a person has a small vs large screen.
  • Nathan: not really about screen size.
  • Luciano: but it is about editor size. What about use relative above a certain window size, and absolute below?
  • Nathan: wouldn’t you want the opposite?
  • Eduardo: that’s what I was thinking, too: absolute margins above a size threshold so they don’t needlessly waste space, and relative below it so the framed content doesn’t get squeezed too much.
  • Decision: fixed margin for large editors, switching to relative at smaller sizes. And the fixed margin should be larger than the current one in the PR.

Discussion: Keying Multiple Selections From Properties

  • Luciano: when you have multiple characters or objects, and you want to key it via the properties (e.g. hovering over x location and hitting i), it only adds keys on the active object. Also for deleting keys from there. This is annoying: no way to do this for all selected objects.
  • Nathan: yeah, you can manipulate properties on multiple objects with alt-{change}. Weird that we can’t key them.
  • Luciano: honestly, the alt-{change} thing always felt weird to me. If I have multiple things selected, just change the property for all of them.
  • Nathan: agreed. And visualizing when a displayed property represents more than one selection. I’ve always wanted that. The alt thing feels like a work-around.
  • Luciano: and currently alt-i is for “remove keyframes” anyway.
  • Nathan: maybe we just change it’s behavior to “key for all selections”? How many people use that hotkey? I didn’t even know alt-i it existed.
  • Eduardo: you have to select an armature to go into pose mode, and then it’s selected with the bones. You probably wouldn’t want the armature object to be keyed with the bones when in pose mode.
  • Christoph: I don’t think that should be a problem. We can tell from context that we’re in that situation and special-case it.
  • Luciano: related but separate thing: it’s also weird that hovering and hitting “i” keys all elements of an array property (like location x/y/z) rather than just the individual one you’re hovering over.
  • Nathan: I think I agree with that as well.
  • Luciano: and there could a modifier key (shift?) to key all items in an array if needed.
  • Christoph: just hitting “i” three times while moving the mouse a little isn’t a big deal.
  • Nathan: I propose making a design tasks for both of these:
    • Keying a property on multiple selected objects/bones/etc. at once.
    • Keying only a single element of an array property when hovering over it.
  • Module agrees.

Discussion: Editable Motion Paths

Next Meeting

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

7 Likes
2

Thanks for demo’ing :slight_smile:

@looch & Eduardo, could you elaborate on your preference? Is it about ease of box-select? Seeing more of the surrounding keys for context? Some other reason?

3

@sybren the reason given was ease of selection. With the keys so close to the border you have to be careful to not hit the scrollbar (which already starts to enlarge at that point) or any other element.

1 Like
4

Thanks for the clarification, I can make that work :slight_smile:

5

Yes, I had the same concern about box-selecting keys. There should be a margin wide enough to not have to aim surgically between the keys and the scrollbars. Thanks for polishing this. Also nodding enthusiastically at the prospect of “i” not keying whole property arrays anymore, this was annoying

2 Likes
6

I was thinking optionally that margin can be more useful if its based on frames so if we are displaying 20 frames and we set a default marging of showing one frame back and one frame forward should be enough, maybe the percentage is in frames or so it will say 20 frames and we’ll get a margin of 10% of the total ammount of frames that will be displayed so its 2 frames, but if it not an exxact ammount we’ll round the number so we always have an exact frame start and ending
This not only would be handy but beautiful to display to the user.

7

I’ve updated #122320: Anim: use smaller margin for Timeline / Dope Sheet / Graph Editor for the feedback gathered here.

Except for @looch’s feedback – sorry dude, I tried some round-to-entire-frames code, but in the end it all produced a bit dodgy results. For now I’ll leave things un-rounded.