利用者:Aligorith/27X ActionManagement

About

... TODO ...

See also the original roadmap

Rationales and Use Cases

The action stashing behaviours were put in place specifically to address complaints by various users that they were finding it far too easy to accidentally lose actions. In particular, the biggest complaints related to:

• 1) Losing an action when starting work on the next one
  • 1a) The user firstly closes/unlinks the existing action, then presses "Add New" or simply inserts some new keyframes --> A "clean" start
  • 1b) The user simply presses the "Add New" with the old action still active --> Easier/Lazier way of 1a OR a simple way to preserve an earlier version of the action

In both of these cases, there are no problems if *something* causes the usercount of the old action to remain non-zero once it has been displaced to make way for the newly created action. A Fake User forcibly gives the action a user (effectively pinning it on a global/file level), whereas Stashing in the NLA means that the Object/Mesh/Material/etc. still has some link to the actions which can be used to affect it (benefits of doing this are that renaming bones or doing other rig changes can get applied to the actions as well).

From many of the threads discussing these things, one of the notions that came up repeatedly was that when you create actions, those are tied to the objects/materials/etc. that you created those actions for. That is, Blender should know that Actions 1, 2, 3 are for Object A, while Actions 4, 5, 6 are for Object B. The action stashing workflow seemed to be a good way to make Blender's behaviour match up with semantic expectations.

• 2) Losing an action when switching between different actions while working on a new one. (Or alternatively, working on multiple actions at once). The user already has some actions created (A1, A2, A3). They then create a new action (A4), and lay down 1+ keyframes, realise that they need to check on a previous action, then use the Browse button to switch to a previous action (A2/A3). After checking that previous action, they jump back to the new action they were creating (A4) and carry on. However, they may be interrupted at any stage of this process, and may end up saving the file with A2/A3 active, but without having done anything to preserve A4 yet.

• 3) "Closing" an action after checking on it As part of 2), the user may get distracted after A2, and want to start creating a new action (A5) from scratch (instead of using A2 as a base, or continuing to work on A4 for the time being). So, instead, they "unlink/close" A2.

In this case, we clearly don't want A2 to suddenly have nothing referring to it anymore.

Now, were some of these methods overly heavy-handed? Perhaps...

There is an inherent conflict/tradeoff here between protecting user data and making it hard/cumbersome to get rid of data you don't want anymore. This arises because the computer ultimately cannot possibly know what your intentions are.

• With great power comes great responsibility: At one end of the spectrum, you put the user in full control. That is, the computer does as you tell it to - it will save when you tell it to save, and it will not attempt to retain things that you've told it you currently don't have a use for.
• On the other end of the spectrum, if you apply too many safely precautions against the user shooting themselves in the foot, it becomes a cumbersome process to get anything done, as now users have to fight against the protections designed to keep them from doing anything unintentionally. (Note: Even something as passive as a warning prompt in one context can be a massive PITA for another)

Given the feedback that was trickling in - i.e. "data shouldn't ever be lost", "users should tell the software when they want something deleted" - the available evidence pointed to a need to be conservative/cautious here and lean towards saving things more often.

What's Been Implemented So Far?

• 2.74 - Stage 1 (The Essentials)
  • Introduced the Action Stashing concept to Blender (i.e. "unused" actions get stored in the NLA as strips)
  • When creating new actions, the previously used ones will get stashed to prevent them being lost
  • Fixes for the NLA to make it easier to use it for storing and referencing a library of actions
  • "Orphan Data" mode for the Outliner to make it easier to see and manage data which may get lost (or may be hanging around unwanted)

• 2.75 - Stage 2 (Important Fixes, Workflow Polish)
  • Tweaks and fixes for the way that the Browse dropdown and Unlink buttons work, to prevent them from doing "evil things (TM)", and to make it harder for users to accidentally lose work when toggling between actions
  • Operators for moving up and down in the NLA stack, to make it easier to work on a library of actions

• 2.76
  • Shift-clicking on 'X' to unlink now clears Fake User and removes the NLA-stashed action too.

• 2.77 (?) - Stage 3 (Extra Polish)
  • Datablock selector for the Action Editor so that actions for non-object datablocks can be viewed and edited in isolation
  • Hotkeys + Operators for switching between editors
  • Right-click menu in Animation Editor channel lists
  • Properties Region for Action Editor

Pending Changes

WIP Warning The following list of features are currently still under development!

Important/Critical:

• Add a "datablock level" selector to the Action Editor so that it is not restricted to work on object-level actions only. This is needed if the editor-switching hotkeys are to be added, as they won't make sense otherwise.

Workflow Polish (i.e. "nice to have, but can delay for another release if necessary"):

• Hotkeys for switching between anim editors, to be used when entering tweakmode or managing actions. For example, Ctrl⇆ Tab could be used to toggle between the NLA/Action Editors (i.e. NLA -> Action Editor when entering tweakmode at the same time, and Action -> NLA when exiting tweakmode), Ctrl⇧ Shift⇆ Tab does the same except that it isolates the action (i.e. it toggles 'solo' too). We could also have Alt⇆ Tab to switch between action and graph editors (though we may need to consider alternative keys)

• Option to automatically adjust preview range when changing actions. This is useful for game animators flipping between several different actions.

• Operator to cycle through stashed actions. In random order too?

• RMB context menu in the animation editor channel lists.
  • For "datablock" channels, this will include options to manage the actions
  • For other channels, this will include mute/toggle/visiblity options + renaming

• Properties Sidebar in Action Editor for additional settings