[Bf-committers] looking for advice

[Nathan Vegdahl]

> 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.

   As an aside, this will be easily solved in 2.5 with the use of
custom keying sets (i.e. you can set autokey up to key an entire
character upon every change).

--Nathan V

On Fri, Jul 3, 2009 at 7:57 AM, Charles
Wardlaw<cwardlaw at marchentertainment.com> wrote:
>>
>> 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
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>