[Bf-committers] Autokey and 3D viewport outline

Tue Oct 16 05:21:51 CEST 2012

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
>