[Bf-committers] Autokey and 3D viewport outline

Daniel Salazar - 3Developer.com zanqdo at gmail.com
Tue Oct 16 05:29:54 CEST 2012


Can you provide a pic? cheers

Daniel Salazar
patazstudio.com


On Mon, Oct 15, 2012 at 9:21 PM, Nicholas Rishel <rishel.nick at gmail.com> wrote:
> Feedback on this UI tweak to communicate that autokey is enabled would be
> appreciated: http://www.graphicall.org/1009
>
> On Sun, Oct 14, 2012 at 10:44 PM, Nathan Vegdahl <cessen at cessen.com> wrote:
>
>> Fair enough.
>>
>> I only ever use autokey with "only key available" enabled, so unless
>> something already has animation on it, it doesn't insert keys.  I find
>> it preferable, because even in scenes that I am animating, there are
>> often objects that shouldn't be animated but still may need to be
>> adjusted (especially in layout phase).
>>
>> I forget that a lot of people don't work with that option enabled,
>> though.  For me, personally, I would love for these settings to not be
>> carried with blend files.  But I can see that's pretty specific to the
>> settings I use.
>>
>> --Nathan
>>
>>
>> On Sun, Oct 14, 2012 at 5:24 AM, Bol Bib <bollebib at hotmail.com> wrote:
>> > I hope I'm forgiven for adding my 2 cents in a mainly developper centric
>> mailing list.
>> >
>> > as an animator I will tell you that is a bad idea.
>> > for 2 reasons
>> > 1)The
>> >  default preferences file is at the moment not versatile enough to
>> > tinker with User preferences on this level (not unless the GSOC
>> > concerning user preferences by vino gets included in trunk)
>> >
>> > plus it would not be apparent that this saves with the preferences as it
>> is an ACTION not a preference (imo)
>> >
>> >
>> > 2)
>> >  if I were to have a default of autokey on in my settings then that
>> > means that even when I'm modeling,texture painting or other stuff before
>> >  I even get near animating ,I will have to close the autokey every time I
>> >  open a blend. (If I understand you well enough,I might be mistaken)
>> >
>> > This seems counterproductive even if it's a wellmeaning idea.
>> >
>> > Autokey should only be activated when you are in animating stage,and
>> that means imo it should be a blend preference,not a default in User
>> preferences.
>> >
>> >
>> >
>> > A decent way of communicating/displaying that autokey is on should be
>> good enough...whatever way the blender devs agree upon....IMO
>> >
>> >
>> > pardon my intrusion ^^
>> >
>> >
>> >
>> >
>> >> Message: 10
>> >> Date: Sun, 14 Oct 2012 00:40:33 -0700
>> >> From: Nathan Vegdahl <cessen at cessen.com>
>> >> Subject: Re: [Bf-committers] Autokey and 3D viewport outline
>> >> To: bf-blender developers <bf-committers at blender.org>
>> >> Message-ID:
>> >>       <
>> CAE91w2vuiOHe8gbSd8nNrBKJdRDvSkxLAMf+ZyhQ4HRCe6PvQw at mail.gmail.com>
>> >> Content-Type: text/plain; charset=ISO-8859-1
>> >>
>> >> > 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
>> >>
>> >>
>> >> End of Bf-committers Digest, Vol 99, Issue 14
>> >> *********************************************
>> >
>> > _______________________________________________
>> > 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