2022-10-03 Character Animation Workshop Prep meeting

The meeting was open for everybody interested.

Present: Brad Clark, Bruce Wilson, Charles Wardlaw, Christoph Lendenfeld, Demeter Dzadik, Esteban Papp, Fani-Eleni Pandi, Jason Schleifer, Luciano Muñoz, MohammadHossein Jamshidi, Nate Rupsis, Nathan Vegdahl, Nico Sanghrajka, Rik Schutte, Sybren Stüvel

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


Meeting Goal

The goal of this meeting was to discuss the principles that will be foundational for the design work during the upcoming Character Animation workshop.

Relevant documents:

What’s stopping you from animating in Blender?

Luciano: Can be summarised into missing features from other tools; Blender working differently than expected, like baking, constraints, and not winning anything in switching to Blender.

  • Jason: this goes to the “intuitive” principle.
  • Luciano: important to build up from familiar workflows.


  • Who is the audience we’re designing things for? Complete beginners, or professional Blender users, or professional animators in general? Focusing on the transition is best: quick to start & still powerful. Easy for “new to blender” user, including experienced animators. Quickly get good results.
  • Sybren: this aligns with Blender’s overall target audience: giving professional tools to individuals and smaller studios. Part of the Blender 2.8 design was to allow simplifying the interface for beginners, and allowing gradual expansion into Blender’s full feaure set.
  • Fewer tools that work well together & branch out from there.
  • Haven’t seen: what are the overall animator workflows? Blocking (no interpolation) and polishing (interp usper important) require completely different toolsets.
  • Luciano: Blender shouldn’t lock it down, otherwise we get the key “colours” that are only for too-specific things.
  • Jason describes it as “phases” animators work in.

Interactivity & Performance are Creative Freedom

Going back from the long “what’s missing” document to the “principles” document.

Bruce: people don’t know what “crazy fast” means. When designing Premo, the requirement “Rigs should be 10 FPS” was as first interpreted as “10 FPS with stand-ins”, but no, it should be full rigs with renderable geometry that should be 10 FPS while manipulating the rig. This frame rate is minimum for “illusion of interactivity”; more is of course better.

  • Esteban: also responsibility of the rigger. Bruce confirms, this is for both the software and riggers.
  • Charles: 24 FPS with multiple chars would be a good aim.
  • Jason: 10 FPS is for interaction, playback should be at the project speed.
  • Luciano: aim for 60 FPS, then?
  • Bruce: how important is playback, vs. waiting for 1 pass so things can get cached?
  • Charles & Luciano & others: super important.
  • Bruce: multiple characters deforming at 24 FPS is not really achievable (with their sims and everything). Using idle time & speculation to precompute future frames will certainly help to create the illusion of speed. Setting a bar that always guarantees 24 FPS playback severely limits the rig possibilities.
  • Nathan: Hardware differences make it hard to promise, but as a guideline it’s good.
  • Charles: how much deform is on the GPU in Premo? Jason/Bruce: nothing.
  • Esteban: it’s tricky, because the deformations are not easy to put on the GPU. Riggers (in Premo) are coding, and don’t have GPU experience. It limits a lot what an artist can do.
  • Sybren: it should be possible to do Cycles renders on a CPU, so there will always be the necessity to have a CPU implementation as well, making it rather complex to handle both and keep them producing the same deformations.
  • Luciano: it would be good to have a rig from the Blender studio as benchmark.

Nathan: “Intuitive” may be too fuzzy.

  • Luciano: should be more defined, same with “familiar” – for whom?
  • Nate: “comprehensible”
  • Nathan: “teachable”; Bruce: points back to the audience / learning curve mentioned earlier.
  • Eventually it’s settled that it’s ok to be a bit fuzzy in these principles.

Change Should be Facilitated

Should be as easy as possible for riggers to make changes without breaking shots.

  • Jason: in the workshop we’ll have to specify which changes are expected to be non-breaking.
  • Luciano: maybe “iterations” should be facilitated?
  • Jason: it would also include things like vertex order changing.
  • Nathan: should facilitate changes “upstream” & “downstream” (towards anim & other changes that are affecting the rig)
  • Jason: notes & version numbers on rigs can help figuring out what changed.

Jason: throw in experimentation in there too? Being able to swap between versions of an asset, as a means of experimenting with something.

  • Nico: this would help comparing changes in weights painting
  • Bruce: exploration of ideas at animation level, A-B testing, was done in Premo.
  • Rik: Blender’s Actions already help here, duplicating an action, modifying it, and switching is great.
  • Jason: could work with layered animation, but constraint setup & timing changes should be in there too.

Luciano & Nathan: we have to set the scope for the workshop, what we can do and what we want to stay away from. For example, fundamentally changing how hotkeys work might be out of scope because it could mean too many changes to other Blender areas.

Empower Animators to Keep Animating

Rik: avoid hunting for functionality. Button bar with clear iconography would help.

  • Sybren: that’s an interesting one. Ton’s vision is to aim as much as possible for buttonless, or even UI-less, animation workflows. Then again, AnimBot fans seem to be happy with a single buttonbar where they can find all their tools.
  • Rik: what is the end product? Animator wants to quickly edit stuff. From design perspective clean & right is nice, though.
  • Nico suggests making an optional toolshelf, where riggers can throw tools onto & customise it.
  • Bruce: one of the concepts (with Premo) was the “surgeon’s assistant”, where you get handed the tools you need right now.
  • Jason: works for riggers as well, set up your own tools.
  • Jason: Blender’s workspaces are great, but limited at this point. It should be very simple to create them by novices as well. And to configure on a personal basis instead of getting stored in the blendfile, so that each animator can work in their own preferred way.
  • Charles: could be a custom poll() function (in operators, panels, etc.) that respond to certain “modes” like “rigging”, “blocking”, “detailing”, etc.
  • Jason: what kind of things do animators need to animate? How do we future-proof Blender for this?

Bruce: Atomic tools vs Orthogonal: orthogonal tools will be easier to master than having to learn all kinds of might-be-related atomic tools to build things up on.

  • Important as “lens” when going over the items in the “what’s missing” document: is this super specific, and does it work well together with the rest?
  • Atomic is good for underlying model, but not for UI/UX. There orthogonality is important.
  • Charles: Modo has this, where smaller atomic tools can be combined into powerful things.

Brad: right now the rigger doesn’t have a good way to help facilitate/empower workflow, the rig is fixed and then you have to tool around/work around what the rig settings give them.

Single Words for Principles

Jason: principles in Premo were single-word, like “Direct”, “Fast”, “Intuitive”, “Fluid”. He suggests:

  • Fast - Interactivity & Performance are creative freedom
  • Iterative - Change should be facilitated
  • Focused - Empower animators to keep animating and riggers to keep rigging.

Contextual Interaction

Various people wonder whether the “Contextual Interaction” principle is actually needed.

  • Bruce: “Contextual interaction” can be big point under “Focused”, becomes “Focused & Direct”
  • Sybren: explains “contextual interaction” as a change in perspective, from the current “dumb tools + smart/heavy rig” to “smart tools + dumb rig”.
  • Sybren: “Empower Animators To Keep Animating” is more the focus of the entire workshop.
  • The rest agrees, and “Empower Animators To Keep Animating” is now used as the workshop subtitle.
  • The name of the “Empower Animators To Keep Animating” principle is changed to “Focused - Keep Animators Focused”.

Bruce: “Animate in the 3D View” (sub-point of the Contextual Interaction principle) reminds of Premo principle “Direct”. Very important, and not yet covered by the rest.

  • Nathan: yes, always had that idea of doing more in the 3D viewport.
  • Nathan wants to steal “Direct” from Premo.

Luciano: many of the tools actually exist to make up for lack of interactivity. The graph editor is more for finer detail, but shouldn’t be necessary all the time. Bruce hears that a lot: the desire for faster rigs and less tools.

  • Esteban: the interactivity is really key to work in the 3D view, otherwise it’s just frustrating the animators.

Riggers vs. Animators

Nico: what’s the focus of the workshop, animation, or rigging, or both?

  • Charles: it’s a Sam-and-Frodo thing, animators can’t work without riggers.
  • Nathan: the systems are also literally integrated.
  • Nathan: riggers make animators’ life easier, and making riggers’ life easier impacts animators as well. Focusing on animators is thus fine for the workshop, as that will certainly impact rigging workflows as well.

Bruce: think about what’s rigger’s & animator’s responsibility? Separation of concerns.

  • Rigger makes beautiful sculpt
  • Animators take that and make beautiful poses.
  • Not sure whether riggers are responsible for creating all of the workflow of the animators.
  • Supervising animator selects from the controls the rigger exposes which control sets are given to the animators.
  • Jason: those “pages” of controls (in Premo) are set up for a specific context, blocking vs detailing for example. Can be customised per shot.
  • Esteban: the controls shown there were also context-sensitive.
  • Jason: was not a bone picker, but more like having collections of properties in the N-panel customisable, orderable, groupable, etc.

The Suzanne Principle

Jason: being a good “Blender citizen” principle should be in there.

  • Bruce: ties in with who we’re making this for, the audience.
  • Jason: it’s also about how we’re implementing these tools. To avoid designing in a vacuum.
  • Luciano: “Let the animation part be Blendery”
  • Sybren suggests calling it “the Suzanne principle”, which is much liked.

The “What’s Missing” document

The list of items is too long to go over in detail one-by-one.

  • Bruce: we should characterise & understand what these items are. Long-term fundamental change vs. nice-to-have-now papercut, high/med/low priority. Now what do you want to do with the engineering efforts?
  • Emoticons will be used for this, to signal things in the Google Doc. The people present at this meeting will go over the doc and use the emoticons for the classification. This’ll help in preparing the next meeting.

Esteban: maybe we should change the structure of the doc, to help them write down bigger changes than just incremental improvements.

  • Nathan: this is showing the current frustrations people have. Important to inform us & keep in mind.
  • Esteban: as with Premo, a more “this is a blank slate” question could work better.
  • Sybren will set up a new Google Doc for this, so that people who answer there aren’t influenced too much by the already-existing list of more incremental improvements.

Next Meeting

The next meeting will focus on the “What’s Missing” and the upcoming “What if you had a Blank Slate” documents. It’ll be on Thursday 13 October, 17:00-19 CEST (Your local time: 2022-10-13T15:00:00Z). Note that it is in the regular module meeting slot, but starting one hour earlier and lasting one hour longer.

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.


So, in prep for today’s meeting, I am having a look at this meeting’s notes.

I have some feedback for this point (I wish i could have attended):

  • Rigging Nodes could implement skinning features that maybe make the upstream/downstream problem a little easier. It already has the ability to do automatic skinning and make new objects with existing geometry. No modifier support at this time besides Armature Deform.
  • The fact that skin-weights are a property owned by the mesh datablock (which in turn, is owned by the modeller not the rigger) is a point of pain here - a fast Data Transfer “fixes” this, but overrides for vertex groups would be even better.
  • I have, on one occasion, used a trick to automatically update a rig in all the files that used it (needed to swap some names during production and fix the animation channels).
    • The Armature has a PointerProperty to a Text Datablock
    • The text datablock is a function that works in a driver
    • The armature object has a IntProperty that is “version number” which has a driver on it
    • The driver will run and increment the version number and keyframe the new version number.
    • The driver function must check the version number, and remove itself if the rig is up to date. It can do any other important work when it runs.
    • All in all, it was too much of a hack to use reliably in production - but something like versioning is possible for rigs in the current Blender if you’re really clever.