[Bf-committers] looking for advice

Charles Wardlaw cwardlaw at marchentertainment.com
Mon Jul 6 14:44:48 CEST 2009


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


More information about the Bf-committers mailing list