[Bf-taskforce25] defaults & tweaks list

Nathan Vegdahl cessen at cessen.com
Sun Jul 12 01:21:50 CEST 2009


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

Yeah, I agree with Jason whole-heartedly here.  If autokey is on it
should affect everything, and if it's off it should be off everywhere.
 It's weird having it behave differently depending on where you are in
the UI.

--Nathan V

On Sat, Jul 11, 2009 at 2:44 PM, Jason van
Gumster<jason at handturkeystudios.com> wrote:
> 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
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25
>


More information about the Bf-taskforce25 mailing list