Try   HackMD

The meeting will be on [date=2025-06-26 time=18:00:00 timezone="Europe/Amsterdam"]. 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:
JWvD
Christoph
Nathan
Sybren
David W
Joseph
Rasmus Härbre

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

Patches: Review & Decision Time

  • #138877: insert keyframe behavior not consistent between all animation editors about keyframe deselection of non keyframe keys (e.g. grease pencil)
    • Christoph: GP and Mask keys do not get selected on insertion. So also the "deselect on insert" isn't really needed there.
    • Question: keep this as-is, or also add the select-on-insert?
    • Sybren: I would think it's nice if they would also select on insert.
    • Nathan: Agrees consistency would be good.
    • Christoph: will split that off from this bug report, as that also has a genuine issue with Shape Key keyframes that needs fixing.
    • The rest will need to be discussed with the GP resp. Motion Tracking teams.
  • #140677: Anim: Frame jump by delta operator
    • Where to specify the size of the jump? Scene property?
    • Nathan: it used to be that Shift+Left/Right keys would jump by 10 frames. Was really useful for blocking, when timing is not yet important. He appreciates this PR.
    • Nathan: maybe the default should be 10, just to go back to what the feature used to be.
    • Christoph: this PR is specifically about introducing the jump size in the UI. The regular frame jump operators already have a parameter for this, so you can already bring back those hotkeys.
    • Joseph: there's already a place in the UI that sets the default key type, in the Keying menu in the Timeline. We could expand that to set the default jump size.
    • Sybren: likes that.
    • Nathan: this PR also adds buttons to the UI to use these operators, so it's not just about setting the step size.
    • Christoph: likes this. We may not need new operators, then, because the existing one can take its default from the UI?
    • Sybren: if the regular frame jump operator already has default=1 frame, we'll need another one if that has to have some other default.
    • Sybren: what default value, though? 24 is also something relatively arbitrary.
    • JWvD: 10 frames seems nice. It gives some space between frames when blocking, but it's not as much as 24.
    • Joseph: 24 has more dividers than 10, so placing things in between is easier.
    • Christoph: it's not that important, because you can just re-space things after you put keys in between.
    • Nathan: for sub-frame editing (like tweaking motion blur), it could be really nice if we could set smaller-than-1 jump sizes.
  • #140863: WIP: Added an invoke function to marker_select_leftright so that it can operate the same as selecting keyframes to the left and right of the playhead.
    • Makes Ctrl+Click on markers work the same as on keys (select all keys on one side of the playhead, depending on the clicked position).
    • Ctrl+Click on a camera marker should select the camera object (according to the keymap), but that's broken.
    • To decide: fix the broken behaviour? Or accept this PR?
    • Joseph: there already is a Select Active Camera operator in the viewport, so we don't really need both. Nathan likes this.
    • Sybren: might be cumbersome to use this to quickly go through a few camera markers, though.
    • Christoph: Ctrl+Click on camera markers does seem to work in 4.3.
    • Joseph: it doesn't work in 4.4 though.
    • Nathan: let's talk with some people who do layout & previz in Blender, as they'll be most impacted by this feature.
    • Sybren: will talk with Hjalti and maybe some others.
  • #141029: WIP: Fix #138399: Key handle jumping when scaling to 0
    • To decide: is this improvement enough to land, and should it be in 4.5
    • Nathan: thinks the new behaviour is better than the current behaviour.
    • Joseph: can you store the pre-transform in the 'invoke' of the operator?
    • Christoph: it's the transform system, it only knows about the selected handles, but because some of the handles are connected, it modifies more than it restores.
    • Sybren: it can store information about unselected items as well, for example for proportional editing. Adding the unselected handles (the 'unselected opposites' of selected handles) in there might be enough to at least fix the "cancel doesn't really cancel all changes" issue.
    • JWvD: scaling to 0 could set the handle type to 'Free', so that at least the other handle doesn't get affected.
    • Christoph: people are sometimes already complaining about Blender automatically changing handle types.
    • Rasmus: would it make sense to have a minimum length for the handles? Like not go under 0.1?
    • Sybren: thinks that's a good idea. The "pointy shape" can be gotten by Free handles as well, so there is no need to use 0-length handles for this.
    • Christoph: is going to try and implement the minimal handle length only for F-Curves (there is much overlap with 3D curves in the viewport).
    • Nathan: implementation wise, it's probably easiest to set a minimum horizontal distance. That way you don't have to worry about different units, scaling, etc.

Next Meeting

The next meeting will be on [date=2025-07-03 time=18:00:00 timezone="Europe/Amsterdam"]. Again it will be open for everybody who’s interested. The provisionary meeting agenda will be updated before the meeting.