[Bf-committers] Autokey and 3D viewport outline

Nicholas Rishel rishel.nick at gmail.com
Wed Oct 17 02:48:03 CEST 2012 

Forgot to copy dlls over, it should run now. :B
http://www.graphicall.org/1009

On Tue, Oct 16, 2012 at 12:02 AM, Nicholas Rishel <rishel.nick at gmail.com>wrote:

> Done, the image doesn't quite do it justice due to scaling and lack of
> perception of time. Also, the color is placeholder since red - or at least
> the red I was playing with - isn't ideal due to contrast issues.
>
>
> On Mon, Oct 15, 2012 at 11:29 PM, Daniel Salazar - 3Developer.com <
> zanqdo at gmail.com> wrote:
>
>> 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
>> _______________________________________________
>> 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