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.
- Google Meet
- Previous meeting notes
- Workboard (17 bugs, 8 unclassified, 48 TODO, 49 known issues, 33 design tasks)
- Patches (37 open & tagged with ‘Animation & Rigging’)
From last meeting
- Quaternions: handling of quaternions on a technical level is being discussed at Quaternion Interpolation
- Test builds: People have been making branches for test builds. The list at https://builder.blender.org/download/branches/ is expected to grow further. Sergey will shorten the clean-up for old builds from 100 to 30 days.
- Sybren wrote technical documentation about Parenting. This can serve as a basis for improvements to the manual.
Short-term goals from last meeting:
- T80296 Fix Animation Channel and Bone Selection Sync . This requires some more design work, as discussed in Responding to selection changes. Sybren has fixed the issue that the existence of armature animation can block selectability of shader node animation channels (T62463). The rest of the issue has been moved away from the “short term” list.
- D6379 Add a Un-Bake FCurves operator: has been merged to master.
- User preference to turn off bone group colors in the animation channel list: T82134 has been created.
No new short-term goals were added.
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.
- 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.
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
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.