[Bf-taskforce25] defaults & tweaks list

Jason van Gumster jason at handturkeystudios.com
Sat Jul 11 23:44:40 CEST 2009


Hello,

Brecht Van Lommel <brecht at blender.org> wrote:

> OK, mainly I'm coming from this point of view for simple cases. I was
> just playing around with the animation system a bit, keying things
> from buttons. If you type in a new value on a keyed property, then
> most likely you want that keyed, otherwise you will lose your changes
> anyway, so why not do it? One possibility is to only do this for
> buttons automatically, since it's a very explicit change anyway, the
> button turns into a different color.

At first blush this sounds like a good compromise, but it's kind of
inconsistent behavior to have autokey enabled on some things and
disabled on others. Furthermore, the fact that everything in Blender is
animatable complicates matters. On some features, the only way to
adjust them is through properties and buttons. It doesn't make sense to
autokey them if you're just trying to set or change them. The auto key
available option helps mitigate this a bit, but then we're still left
with the consistency issue..

> > When I animate, I often have situations where I know either the
> > pose I want *or* the timing that I want, but not both. This means
> > that I spend time moving or rotating elements at frames where I
> > don't want keys... or explicitly setting placeholder keys for rough
> > locations, but nothing detailed in the pose until later. I also
> > have occasions where I move a limb in real time to get an idea of
> > how it moves and deforms the mesh... but I don't want to set any
> > keys.
> 
> I think this is only true without the "auto key available" option set?
> With that option enabled you have to manually key it once first, so
> nothing will be keyed automatically, but there will be an automatic
> keyframe if it is already keyed. I think the use cases you mention
> here would still work as expected?

Sure this works on objects/bones you've not keyed yet, but more often
then not, those parts aren't the ones that I'd be playing with. The
things that are keyed elsewhere are the ones that I'd be moving around
or rotating to do quick perspective tests or color tests... but I don't
want them keyed. Furthermore, it gets complicated if I adjust a keyed
property on a frame that has a key. If I adjust that property to
play/test, then I lose my key each time because it's overwritten. This,
too is not ideal.

> The last one, moving things temporarily without keying, to test out a
> pose, is not as easy, but could be supported by a undo hotkey to undo
> all the changes on the frame.

This feature could be helpful (especially to autokey users)... but I'd
rather just work with autokey disabled and not have to worry about it.
 
> OK, so if I understand this correctly, the difference will be that
> since you only have to key some property once, you are not
> continuously reminded of them by having to insert keyframes manually.
> One other way to remind of this would be to show a little message in
> the to be created console that something got automatically keyframed,
> perhaps with a yellow dot like the button color, to make it clearer
> what is happening.

It's not just a reminder. When you manually key, you know what's been
keyed and you generally know what to expect. There's the issue Nathan
brought up about the potential for lost keys, but I actually find it
easier to fix a lost key than a superfluous one. And with autokey on a
complex rig, you could potentially insert quite a few keys at the same
time by adjusting a controller. Not all properties are in view at the
same time, so how would you remind the user of that?

Ultimately, if you have autokey on by default, my first thing is going
to be to disable it and save that as my user preference because I still
have that freedom (I mean, we're not talking about removing manual
keying altogether, right?). I just think that manual keying is the
expected behavior and that the majority of animators are similar to me
and use autokey as an accentuation to their workflow rather than their
primary tool.

  -Jason


More information about the Bf-taskforce25 mailing list