2020-10-29 Animation & Rigging Module

Present: Bassam Kurdali, Christoph Lendenfeld, Daniel Salazar, Luciano Muñoz, Stanislav Ovcharov, Sybren Stüvel, Wayde Moss

The main goal of this meeting was to identify the most pressing bug fixes & papercuts to work on in the Animation & Rigging module , in order to make 2.91 as polished as possible, and to discuss limiting the open amount of work & ideas to flesh out. That is, to make sure ideas are implemented & finished, or scapped/put in the freezer, before piling on more ideas-to-do on the workboard.

To keep the discussion focused, the meeting was timeboxed to 1 hour.

Links

From last meeting

Short-term goals

Short-term goals from last meeting:

No new short-term goals were added.

TODOs

The list of TODOs on the workboard should reflect a limited number of things that can be picked up by anyone. This means that these tasks:

  • have been approved,
  • do nothing controversial,
  • have all the required information to implement fully.

It was decided to cap the maximum number of TODO items in the tracker to 10. This is the same number as the Cycles project is using. It also corresponds to broadly 2 TODOs per developer in the module, which is kind of nice.

To handle the current number of TODOs (48) the following structure was thought up. With this, existing TODOs can either be moved into the right spot, be re-tagged as “Design” when their description is not specific enough yet, or several TODOs can be merged into a larger design task when they are about the same broader topic.

New meaning for existing columns

  • TODO: as described above (approved, uncontroversial, fully specified)
  • Design: design tasks that are currently being worked on. Once a design is completed and approved, the task can either be turned into a TODO task, or one or more TODO sub-tasks can be created.

New colums

  • Design done, Low priority: design tasks that are pretty much done, but don’t have high priority when it comes to implementing them.
  • Needs Investigation: or things that need investigation to come to a decision whether to actually continue with it or not. This is mostly meant for already-existing tasks that look interesting, but that need an actual time investment before a decision can be made.

Wiki lists

Existing tasks can also be moved to the wiki, to one of two lists on a “Decided not to do” page, or to a “bigger project” page:

  • To never do / antipatterns: for those ideas that seem desirable, but go against core Blender design principles.
  • Might revisit at some point: for design limitations that we have no intention of lifting at the moment, but that could be revisited in the future.
  • Bigger Projects (open for suggestions as to a better name): for “bigger vision”-like ideas, for example node-based constraints, animation without (visible) bones, animation layers. These ideas are interesting, should have a place somewhere, but are too big to fit into one design task.

Each task on either “decided not to do” list should get a little explanation of why it’s there, what made it difficult to do, and a link back to any related task on Phabricator. The task on phabricator, when it’s closed and moved to the wiki, should get a link to the wiki.

How to proceed further

Sybren will do a first pass of the current TODOs, to quickly weed out tasks that are clearly not TODOs as per the new definition. After that we’ll open a simple poll to ask people which TODO they find most interesting/pressing/important. This will be announced in #animation-module.

There are also two “TODOs” that are basically lists of TODOs from the old wiki: T55365
Blender development todo list – Animation System
and T55366 Blender development todo list – Editors, both of which at some point should be gone through to extract TODOs from in any of the above lists.

New Module Members

Bassam Kurdali and Christoph Lendenfeld officially became members of the Animation & Rigging module.

Handling changes to Constraints

Bassam voiced concern about how changes & fixes to constraints are handled. On one hand we should be very careful to not break existing rigs, but on the other hand we should welcome developers who send in patches that actually solve concrete problems. The current way of working within the module, where we make more custom test builds of Blender, is a good start, as that allows for testing on various existing files. Luciano added that it may help to point out specific versions of Blender that may include potentially-breaking changes, such that patches can be more easily accepted but put on hold for specifically that release.

Daniel Salazar expressed that the release notes should have a clear list of changes to constraints, to make it possible to test rigs on new/upcoming releases.

Nice approach to design tasks

By Christoph Lendenfeld: T81836. In one glance, a task description like this shows what it is related to, where to get a test build, and what the larger context is for the task.

Next Meeting

The next meeting will be on Thursday 12 November, 15:00 CET/Amsterdam time. Again it will be open for everybody who’s interested. The provisionary meeting agenda will be linked in the #animation-module channel a few days before the meeting.

5 Likes

Addendum: T82210: “Bake Action…” bakes wrong on flat curves was discussed. It was agreed upon that the operator is doing two things (baking an action and cleaning up the resulting curve) and that the cleanup pass should become optional.

1 Like