[Bf-committers] looking for advice

[Nathan Vegdahl]

> That sounds interesting.  When a more complete build of 2.5 hits I'll have
> to have a look.  But are they also easily disabled?

Well, "disable" isn't the right word.  All keying in 2.5 is done
through keying sets.
The default sets are things like "loc/rot/scale of the current selection".

But the user can also create custom keying sets, like "loc/rot/scale
on this explicit list of objects/bones".

So disabling full-body keying is as easy as switching back to one of
the default sets.

At least that is my understanding (I may have mixed up some details).

--Nathan V


On Mon, Jul 6, 2009 at 5:44 AM, Charles
Wardlaw<cwardlaw at marchentertainment.com> wrote:
>>
>> 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).
>
>
> That sounds interesting.  When a more complete build of 2.5 hits I'll have
> to have a look.  But are they also easily disabled?  Full-body keying is
> held onto until the refinement pass; there's no reason to full body key a
> character for finger motions, for example.
>
> @Martin: Thanks for the patch.  My weekend was shot doing animation, but the
> head of pipeline here has 2.5 up and building on his Ubuntu laptop, so when
> he comes in tomorrow I'll see if I can get him to apply it to his local
> tree.  I still haven't been able to get 2.5 to build on my Mac due to an odd
> Python error at link time, and it's looking like I've been drafted for AS3
> programming now at work so I won't be able to check into it personally for a
> while.
>
> It's good to know that you're in Montreal.
> ~ Charles
>
>
>
>
>
>
>> --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
>> >
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>