[Bf-committers] looking for advice

[Charles Wardlaw]

>
> This doesn't solve the particular issue, but why don't we enable autokey
> by default for values that already have curves? Why would you want move
> a bone that has a keyframe, and not have it replace/insert a keyframe
> when you move it? Now that we have undo and autokey features, this seems
> the most logical behavior.


>From an animator's perspective, it's best to not use autokey.  I'm sure that
people will disagree with me on this, but they way I've been taught to
animate and the way our head of studio (an 18-year vet, ex-Dreamworks) likes
to animate is to find the pose you want, then set the key for every control
on the skeleton.  You don't set the key until you've gotten to place where
you're happy with how the character is posed, and sometimes getting there is
five or ten changes away.  Sometimes you want to undo back and set a key
again.  This sounds like an inefficient workflow but really isn't; none of
the animators in my studio, and few of the ones I've met outside this
studio, use autokey.  The main thing that this allows is a quick reset to
the previously keyed values if you scrub the timeline, while still allowing
the animator to feel out a pose and undo / redo as long as the playhead is
not touched.  The other reason is that you're certain all the channels
related to animating your character are set at that frame; when you use
autokey it sometimes sets one channel but not everything, and then when you
move into retiming you get swimmy motion and broken poses.

Since the most logical behavior is what the animators are already doing, and
since all other packages let a user undo in this fashion, Blender's way
becomes a hurdle towards adoption.

Your idea of enabling autokey for objects with values already set is a good
one, but then what would be the point of having the autokey button at all?
Just for new objects without any keys set yet?


I guess this happens when you move a proxy object, but don't add an
> action? Perhaps this is a matter of doing that, if you change a proxy
> object, automatically add an action. This is just a guess though.. But
> just like the above, I don't see the point of allowing you to edit
> something conditionally which you can then restore from some cache. This
> seems to me exactly why we have undo.


The issue I was having had to do with unkeyed values.  I tried twice to
scale the rig -- once in the original rig file and once the scene where the
character was linked.  If I set keys only on loc / rot, when I reloaded the
file the bird exploded.  In the bird rig on the BBB DVD the bird's geometry
is actually scaled down a bit (if I recall); this also was not maintained
after saving and loading a file that linked him in.  I think what's
happening is that if there are keys on the armature, then it recalculates
everything and any values that are unkeyed either get set to default values
or to something else.  The animation on the rig itself was still there in an
action; would adding one immediately make any difference?

Maybe I'm overthinking this, but regardless of what would be the best
solution for the problem I have to get Blender's undo to mimic the way undo
works in Maya / Houdini / everything else and need to find the proper
workflow for linking in characters, or fix the what's currently broken in
the system.  The two have seemed to be related thus far, which is why I
brought them up together; if they require two separate solutions then I'd
very much appreciate hearing your thoughts on how to tackle them.

~ Charles