[Bf-committers] Autokey and 3D viewport outline

Daniel Salazar - 3Developer.com zanqdo at gmail.com
Mon Oct 15 02:51:58 CEST 2012


It depends on your workflow. We are switching blend files all the time.

Example: animator works on animation file, needs a new prop so opens
the props file and adds a quick low poly version, links it back into
animation file.

By doing this, autokey animation has possibly been created on the prop
file. There are other similar situations

It is true that autokey status needs to be *immediately apparent* by
whoever opens the file, however it should be saved on blend file

Daniel Salazar
patazstudio.com


On Sun, Oct 14, 2012 at 1:40 AM, Nathan Vegdahl <cessen at cessen.com> wrote:
>> I would be very opposed to disabling auto-key on load
>
> I think you may have misunderstood me.  I am not suggesting that
> autokey be disabled every time you load Blender or a new file.  I'm
> suggesting that autokey and related settings should be a setting that
> does not get carried around by blend files.
>
> So, for example, an animator that uses autokey would turn it on and
> save it as part of their default settings.  Then it would always be on
> for them, even if they open someone else's file.
>
> Similarly, an animator (or other user) that does not use autokey would
> turn it off, and save _that_ as part of their default settings.  Then
> it would always be off for them, even if they open someone else's
> file.
>
> In short, I think that autokey and related settings may be a poor
> thing for normal blend files to carry around.  Some (most?) settings
> are great for blend files to carry around.  But I'm thinking autokey
> may not be one of them.
>
> --Nathan
>
>
> On Fri, Oct 12, 2012 at 9:31 PM, Daniel Salazar - 3Developer.com
> <zanqdo at gmail.com> wrote:
>> I would be very opposed to disabling auto-key on load, in the past it
>> was like that and resulted in lost work for animators all the time. If
>> an animator is activly working on a shot he should not have to
>> remember to activate autokey every time he/she goes for a coffee break
>> or switches files.
>>
>> I think the way it is current is getting quite close to what it should
>> be. Maybe a bit of a stronger hint wont hurt but it's certainly more
>> flashy than a static icon on the timeline
>>
>> Daniel Salazar
>> patazstudio.com
>>
>>
>> On Fri, Oct 12, 2012 at 10:20 PM, Nathan Vegdahl <cessen at cessen.com> wrote:
>>> Maybe we should take an entirely different approach to this.
>>>
>>> What if we just make auto-key settings not loaded from blend files by
>>> default?  That way people keep the auto-key prefs they're used to.  It
>>> doesn't seem like this is the kind of setting that makes sense to
>>> carry along with blend files anyway.  It's very specific to people's
>>> own workflows.
>>>
>>> Then there is no need for an indicator in the first place.
>>>
>>> --Nathan
>>>
>>>
>>> On Fri, Oct 12, 2012 at 9:17 PM, Nathan Vegdahl <cessen at cessen.com> wrote:
>>>>> It's fine to have an indicator that autokey is on,
>>>>> it just doesn't need to look as if something bad is happening.
>>>>
>>>> Just keep in mind that the original motivation of all of this was that
>>>> the auto-key toggle in the timeline was not visually obvious enough.
>>>>
>>>> In general, there is going to be a conflict between the purpose of the
>>>> feature and people who are annoyed by its non-subtley.  We already
>>>> have a subtle indicator: the auto-key toggle button.  The entire point
>>>> of this is to _not_ be subtle.
>>>>
>>>> (And incidentally, now that you mention it, I agree, red should be
>>>> reserved for errors.)
>>>>
>>>> --Nathan
>>>>
>>>>
>>>> On Mon, Oct 8, 2012 at 11:43 PM, Brecht Van Lommel
>>>> <brechtvanlommel at pandora.be> wrote:
>>>>> It was made optional now in svn, but I think that does not really
>>>>> address the issue. It's fine to have an indicator that autokey is on,
>>>>> it just doesn't need to look as if something bad is happening. Red
>>>>> should be reserved for errors. There is no need for a warning/error
>>>>> here, just good feedback about what is happening.
>>>>>
>>>>> For example improve the blinking so that it's more like the report
>>>>> message blinking in the info header (which is better visible), show
>>>>> the autokey icon in the 3D view header or next to the object name,
>>>>> color the header a bit yellow, or show a report that X keyframes were
>>>>> inserted after transform is done. I don't know which combination works
>>>>> best but the red border is just too much and the current blinking is
>>>>> not very visible by itself.
>>>>>
>>>>> Brecht.
>>>>>
>>>>> On Mon, Oct 8, 2012 at 3:19 PM, Francesco Siddi
>>>>> <francesco.siddi at gmail.com> wrote:
>>>>>> Hello,
>>>>>>
>>>>>> a new feature has recently been introduced in Blender: when Autokey is
>>>>>> turned on and some object/armature transformation is performed, every 3D
>>>>>> viewport gets a red outline and a message reminding the user of the fact
>>>>>> the a keyframe will be created at the end of the transformation.
>>>>>>
>>>>>> After talking with other users, it seems clear that this feature should at
>>>>>> least be optional, if not off by default. It's quite distracting to work
>>>>>> with a flashing outline all the time.
>>>>>>
>>>>>> Thank you!
>>>>>> Francesco
>>>>>> _______________________________________________
>>>>>> 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
>> _______________________________________________
>> 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