Monday, August 22, 2011

Animator Poll - Frame Change Undo

This evening, the old issue of when (and if) frame changes should get their own entries in the Undo Stack. The key question is: Is the current approach in Blender good, or if not, what should be happening?


Now for some commentary on the matter.

Some terminology first:
- "undo push" = "an entry is added to Undo Stack"
- "Undo Stack" = what you see when you use Ctrl-Alt-Z
 
Each entry in the Undo Stack represents a snapshot of the current state of your scene+models/etc. (i.e. all the stuff in your Blender file at this point in time, but NOT including any View/Screen related stuff, such as screen layouts, editor settings, etc.). By "undoing" (Ctrl-Z), you're telling Blender to revert it's state back to the state it was in when that last snapshot was taken.

The current system in Blender:
1) Clicking or scrubbing to change frame in timeline results in an undo push
2.1) Typing arrow keys to step to other frames - one keypress = one framestep/jump - no undo pushes
2.2) Holding down arrow keys to keep moving forwards/backwards, effectively playing back the timeline - no undo pushes
3) Using number buttons (e.g. current frame button on timeline header) to change frame - undo push

Why does it work this way?
The current system is really an attempt to balance:
a) the need to have frequent-enough undo pushes, for times when we think that you as an animator "intended" to change frame to start setting a new pose on that frame, vs
b) not having enough undo pushes, resulting in cases where undoing a pose suddenly jumps you back to a completely unrelated frame (perhaps right back to the start frame or worse), meaning that you need try to remember what frame you were working on to recover that timing 
c) not flooding the undo stack with just frame-changed undo states everytime for example you start jumping between frames (or perhaps scrubbing?) checking on the pose change between those frames

Hence, the following assumptions were made. See how these map the two sets of points:
- To chose a frame to frame to start posing on, an animator will likely just click somewhere in the Timeline (1+a), then start posing the character.
- If there wasn't an undo push here, you may end posing a rig, undoing all the way, end up going over the invisible frame-jump (not registered as a separate undo state) and start keying your pose again on the wrong frame (1+b). [Side note: I've run into this myself a few times - posing on the wrong frame, only to notice quite a bit of work later]
- While scrubbing may result in the animator ending up on a frame different from the one they were originally on, or perhaps just end up on the same one again, this is ultimately just handled by the same operator as the timeline click. Hence, all the time scrubbing will ultimately just equate to a single undo push representing the endpoint of the scrub (1+c). If you aren't happy with where you end up after a scrub, it's just an undo push away.
- Editing number buttons automatically adds an undo push when the editing is done. Since you're entering a frame in directly, you most probably know what you're doing (i.e. you "intend" to do that). (3+a)
- A common technique for previewing motion without perhaps constantly bearing down on your mouse/tablet/pointing-member (whatever that may be) is to "single step" (left/right arrow, +1/-1 frame at a time) or "flip between" (jump between keyframes) repeatedly until you get a good feel of what you're doing. If each of these was a separate undo push, you'd soon end up with hundreds of irrelevant undo pushes from all that undo action (2.1 + c)
- Perhaps you find the playback too slow? Then try holding down an arrow key to get apparently "faster" playback (or at least it seems that way sometimes). Now, what you might not know is that doing that just ends up running the same operator as for single-stepping (2.1) everytime Blender detects that you've still got that arrowkey held. If we registered each one of those times that said operator runs, then we'd quickly get hundreds of irrelevant undo pushes too (2.2 + c)

How does everyone else do it?
Well, an unconfirmed source claimed that Maya just creates undo pushes regardless for each one of these actions. And apparently for that reason, that is one of the little banes of animator existence there.

As for anything else, I wouldn't have a clue (and probably wouldn't be legally allowed to do so to just "check them out" for the purpose of developing Blender ;)

Some other alternatives to what we've got now:
1) Patch up the other frame change operators so that they run as modal operators, which keep running until they key that calls them is released. Then we get single undo pushes for each of those sessions (though perhaps still not for the flip-flopping)
2) Something similar to the above, but integrated lower down (as part of operator functionality)
3) Go back to a state where we don't have any undo pushes for frame changes anywhere, while risking the problems of "b" (judging from the number of bugreports I often field on a number of other things like this, I'd safely expect a number of recurring reports, perhaps just clustered after releases though, on this very matter)

Alright, that's enough from me about this matter? Let's hear what the animators say!

7 comments:

  1. I think the current approach is ok but it's more useful to use the left and right arrow to change the keyframe instead of change the frame, and not generate undo push when using it (changin keyframe), because, in most of the cases the animators have the keyframes in frames not contiguous

    ReplyDelete
  2. Great poll

    For me

    - Up-Down arrows for next-previus Keyframes
    - Left-Right arrows for next-previus Frames
    - Not generate undo push when using it

    Daniel M. Lara
    pepeland.com

    ReplyDelete
  3. I COMPLETELY & TOTALLY(!!!!) agree with Daniel(pepeland) above. That would be a FAR more sane approach to animating in blender.

    pushes for changing keyframes ends up wasting time & memory(imo), I've never needed to go back a frame via an undo(when I can just go back to that frame without an undo), but rather I would prefer that the last action I did, to say a bone in pose-mode, or a curve, be the element in the stack I'm undoing.

    - Up-Down arrows for next-previus Keyframes
    (with shift or alt going in +10* increments, etc)

    - Left-Right arrows for next-previus Frames
    (with shift or alt going in +10* increments, etc)

    - Not generate undo push when using it
    (with shift or alt going in +10* increments, etc)

    ******!
    on another note, for my workflow, being able to change the "+10" increment in the preferences would be ideal. Sometimes I work on projects with a lot of sub-frame work being done, or a far higher FPS for the destined output medium, and having the ability to customize the frame(jump)-increment value in the preferences would allow me on say, a 30FPS project to skip only +10(default) frames with a shift+leftArrow, but on a project being output for 60-120FPS, I could set in the preferences the value to skip to be +25(or 50) frames(again triggered by a shift+leftArrow). As blender's animation side matures, thanks to your hard work, more studios that work in higher frame-rates will need such functionality IMO.

    Thanks again for the awesome work!!! Any estimate on when a merger might happen for this GREAT branch?

    ReplyDelete
  4. Hey guys,

    Thanks for the responses. I've committed some changes as per your suggestions (r.39597)

    Regarding the increment thing, it has actually been on/off my todo list for a while now. It was actually a 2.4 feature which somehow disappeared off the radar with 2.5. One of the barriers atm is where to put the setting! (We're chronically out of space in the "Dimensions" panel, unless we start making it look ugly and unbalanced)

    ReplyDelete
  5. Hey developer! Let me say something.
    By the topic: please add fuctionality to change active frame without changing the scene response (sorry my russian-english :). It like in Maya when you press MMB in the Timeline - frame changing, but scene does not changes.
    And there is no nessesity to trash undo-stack with time-changes.
    ----
    One of main reasons I chosen Blender: it's almost completely customizable. Working in Maya I've defined for myself "standart hotkeys" for animation. And transfered them to Blender with time. You know what?
    I don't use arrowkeys at all. My right hand is on the mouse & left hand is on the left side of the keyboard. With these hotkeys I don't feel myself octopus. So here they are (just for reference):
    Alt+Z = One frame back
    Alt+X = One frame forward
    Shift+Alt+Z = One keyframe back
    Shift+Alt+X = One keyframe forward
    Ctrl+Alt+Z = Go to start
    Ctrl+Alt+X = Go to end
    if you want to try it I will send you my config.blend

    ReplyDelete
  6. Daniel Lara +1 (e.g. the Ctrl-pg Up and Down thing to seek keys is horrible)

    ReplyDelete
  7. I consider changing frames to be changing the view. As per the MVC paradigm, changing current frame should not trigger an undo push.

    ReplyDelete