2023-08-24 Animation & Rigging module meeting

Meetings
1

The meeting will be on 2023-08-24T16:00:00Z. It is open for everybody interested to join on Google Meet (link below).

Present: Alexander Gavrilov, Beorn Leonard, Christoph Lendenfeld, Demeter Dzadik, Eleni Pandi, Jason Schleifer, Jeremy Bot, Nate Rupsis, Nathan Vegdahl, Stimes

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

Links

Since the Last Meeting / Announcements

  • Sybren StĂźvel and Nathan put together a loose “MVP” spec, to start implementing the new animation data model. Nathan will work on writing this up.
  • Demeter: the pose library/shelf has changed locations. Just FYI to the module.

Landed

Short-term goals / Ongoing Work

Bone Collections & Colors

PR: Replace Bone Layers+Groups with Bone Collections #109976

  • Demo time!
  • Discussion: we want to land it this week, for Blender 4.0. BUT, it will break Rigify.
    • Sybren StĂźvel: before landing, we should have an upgrade guide for switching to the new API, and we should coordinate updating Rigify. OR we should have a compatibility layer in RNA, to keep things transparently working.
    • Alexander: probably need custom properties on bone collections before Rigify can be properly upgraded.
    • Nate: compatibility layer would allow more transparent upgrade path, also for other addons.
    • Alexander: also the scripts of already generated rigs.
    • Demeter: a reliable compatibility layer would be difficult, e.g. with fewer than 32 collections. Better to make a clean break.
    • Alexander: maybe just a visibility toggle compatibility layer, for generated scripts of existing rigs.
    • Nathan: if custom properties on collections are needed for a Rigify upgrade, let’s investigate how quickly we can do that before making a decision.
    • Nathan: will check tomorrow how hard it is to add custom properties, and get back to the module.

Patch Review & Decision Time

  • Moving forward with arbitrary bone orientations (i.e. moving away from the hard-coded y=‘along the bone’).
    • This has been discussed as a wish often, and came up recently in the #110912: USD: Skeleton and blend shape import pull request as well.
    • To decide: do we make this a true goal? Or do we officially decide to not do this?
    • Needs a design task & a priority.
    • Nathan: include Bassam Kurdali in this, he’s been thinking about this, in the context of Blender, for a decade+ now.
    • Sybren (not present at the meeting, but discussed this beforehand) is in favour. Also notes the ‘orbit control’ mentioned by Jason Schleifer is in line with this as well. Or the ‘rest pose’ for objects we’ve discussed as well. Or the additional ‘layout transform’ that the layout artists at Pixar set, which acts as an extra parent of anything the animators do. So the final solution should likely not be to hard-code just one other matrix in there. Then again, maybe starting with a practical solution to the bone orientation is good enough for now (in order to not make this a big beast).
    • Nate: if it requires touching the underlying transform system, maybe too much to bite off. If we can do something less ambitious, that might be preferable.
    • Jeremy: it would be useful for me, but if it’s too much work don’t worry about it.
    • Demeter: what about just changing the visualization to look like the bones are pointed differently (similar to Sybren’s ball visualization proposal).
    • Nathan: lots of things other than visualization are affected by bone orientation, like auto-weighting, envelopes, connected bone chains, etc.
    • Jeremy: visualization would be good enough for my purposes.
    • Christoph: prefers a proper solution, not patched on.
    • Decision: with everything else we’re already doing, seems too big to tackle properly. So it’s a non-goal for now. (Maybe in the future.)
  • Nathan is working on moving Denys Hsu’s Graph Editor Handle Selection PR forward in #111143. What should the operator parameters be?
    • Nathan: please look at the PR and give feedback there.
  • Priority of and who should tackle Drivers of sub-ID properties do not get removed along with the sub-ID #110650
    • Demeter: in production, this spams people with errors/warnings, which just makes artists ignore errors/warnings.
    • Nathan: since it’s been this way for a while and hasn’t caused critical issues, just normal priority. But should definitely get fixed.
    • Christoph will look into it.
  • Designing a Python API for copying drivers: PyAPI for copying drivers #111276
    • Demeter: everyone is writing their own Python approximation of this, so it seems like it should be built in.
    • Decision: let’s do it.
    • Demeter: please look at the issue and give feedback on design.
  • Decide on a new name for the “Bake Curve” operator :#111049: Animation: Rename “Bake Curve” to “Keys to Samples”
    • Christoph: everyone gets confused by the current name, thinks its part of the baking feature.
    • Jason: “samples” makes me think I can still tweak it. But “freeze” also seems lacking.
    • Beorn: what about “compress”? Since it makes the file size smaller.
    • Nathan: doesn’t always make it smaller. Depends on the original density of the keys.
    • Jeremy: committed?
    • Demeter: likes “Keys to Samples”. Seems the most accurate.
    • Nathan: likes “Keys to Samples” too. Freeze could be confused with locking editing.
    • Nathan: main thing is that people shouldn’t confuse it with baking.
    • Decision: “Keys to Samples”

Help Needed

Next Meeting

The next meeting will be on Thursday 2023-08-31T16:00:00Z. Again it will be open for everybody who’s interested. The provisionary meeting agenda will be linked in the #animation-module channel before the meeting.

7 Likes