2022-09-15 Animation & Rigging module meeting

Meetings
,
1

The meeting will be open for everybody interested to join on Google Meet (link below).

Present: Beorn Leonard, Brad Clark, Daniel Salazar, Demeter Dzadik, Fani-Eleni Pandi, Jacques Lucke, Jason Schleifer, Luciano Muñoz, Nate Rupsis, Sarah Laufer, 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

  • Jacques Lucke, Blender developer working on geometry nodes, will be in Amsterdam during the Animation Workshop.
  • Blender 3.3 LTS has been released.
  • Flamenco 3.0 has been released. Sybren will have significantly more time for the Animation & Rigging module.

Landed

Short-term goals

Animation Workshop Prep

24-26 October there will be an Animation & Rigging Workshop at Blender HQ. The goal will be to design a framework/paradigm for a new rigging & animation system in Blender.

Jason, Brad, and Sybren already did some preparatory work. Sybren condensed that into some scribbels and very rough UI designs. During the meeting, this was taken as a starting point to clarify further what will become the founding principles for the workshop (and beyond).

Functionality: migrate from “fat rigs” to “slim rigs + richer tools”

  • Jason: if the tool determies the functionality, how do riggers expand this functionality? Will it be possible to create your own tools?
  • Brad: Rig & tool work together. Rig defines relationships between components, and tool can cherry-pick those. Can help avoid cycles in the rig.
  • Sarah: what would happen with animation curves when switching between IK and FK tools?
  • Sybren: For example, IK can be used to set a pose. After that pose is keyed, it’s irrelevant how it got to be there.
  • Brad: the ephemeral system is basically working with an instantly-drying marker. After you release the tool, it “dries up” immediately and the result is set.
  • Jason: predictability of tools is important. Maybe we can always ghost around the current frames, so you can see the impact of manipulations over time.
  • Jason: in the context of tool extendability (or not), and moving functionality from the rig to tools, expresses a worry that the power riggers have now (by putting together amazingly complex rigs) would be lost when the same functionality in tools cannot be extended by them. Also: Why is AnimBot not part of Maya itself? Is there a reason to have such tools defined only by add-ons?

About the wording of the principle:

  • Jason: “Workflows should define…”?
  • Brad: Contextual interaction is missing in animation. When editing a mesh, you have specific tools for specific context / workflows, like “extrude these faces”. For animation all you can do is drag bones around and hope they do what you want.

Animation Layering

  • Brad: Anim layers (in other software) seem to influence the entire scene. The clip-based system of Blender feels safer, because you know your changes are bound to that clip. Animating should be “putting tracing paper down” and then use the one you want. Blender should make it feel as fast as putting a piece of paper down.
  • Jason: if there is a way in which a layer can help to fix a “pop” in someone else’s shot, simply by adding a layer instead of counter-animating the pop, that would be fantastic.

“Performance” or “Interactivity”?

  • Jason: performance is super important, things should be crazy fast.
  • Luciano: interactivity (of manipulation) and performance (of playback) is both super important.
  • Jason: those are also two separate people, animators resp. riggers.
  • Sybren: let’s go for “Interactivity & Performance are creative freedom”
  • Jason: predictability is something to throw in there. One of the keywords in designing Premo was “intuitive”. Takes into account experience of users in the design, but also important to keep in mind when designing tools.
  • Luciano: aiming for needing less documentation is a good guideline.

“Multiple views on the rig”

Sybren described the collection of rig profiler, rig explainer, bone pickers, and custom bones as “multiple views on the rig”. It’s a practical view, though, and not yet a nice principle. Module decides it belongs under the principle of predictability & understandability.

“Make Animators Animate”

  • Jason: instead of “make animators animate” what about “keep animators animating”?
  • Iteration of work should be included as well. Posing characters is fun, but the ability to easily handle feedback & make adjustments can be equally important.

“Change should not be punished, but embraced”

  • Module: keep it.

After the meeting, Sybren talked with Ton & Francesco, and turned it into “Change should be facilitated”. With a footnote that “change” in this case is from the perspective of the riggers & animators, and not a free ticket for Blender developers to wildly keep changing UI/UX every release.

Patch Review & Decision Time

We did not have time to look at the patches below.

Next Meeting

The next meeting will be on Thursday 29 September, 18:00-19 CEST (Your local time: 2022-09-29T16: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.

13 Likes
2

The principles we have distilled so far can be found on Google Docs: Animation Workshop: Principles. Note that this is a live document that can change at any time.

2 Likes
3

Apologies for writing here, I can’t really find a relevant design task on the workboard where this comment would fit better.

From what I understand, an example of this could be bbone handle controls : either have the rigger connect up explicit bone controllers as bbone handles, or let an active tool draw gizmo handles and control these properties instead. Am I reading this correctly ?

The ephemeral rig system is fascinating but it only holds up for animation that’s very keyframe-dense. In effect, the interpolation from the control rig ceases to matter, in favor of that of the deform rig. That means you can’t always rely on interpolation to get predictable results, you have to have many keyframes, even if just for IKs and rotational movement.

Cheers,

Hadrien

4

Apologies if this is the wrong place to comment.

The “mantra” - Keep animators animating is indeed a much more apt way of approaching the way forward. My personal interpretation of that is the tools should just flow along as the animators animate in a manner of speaking, aka, shouldn’t be a hindrance or take time away from the “acting” side of animation. An example that instantly comes to mind is repetitive tasks such as updating the motion path whenever you make changes in the graph editor; ⚓ T47569 Motion paths are not updated. (Not to be mistaken with the editable motion trails addon, this is merely for instant feedback reflecting the changes one have done)

3 Likes