[Bf-animsys] Animation Proposal

[Nathan Vegdahl]

> I second the remarks regarding the move towards more "traditional"
> based workflows.

   And I third it.
   In general, moving the workflow more into the 3d viewport is a good
thing, I think.  The 3d viewport can show the "what", and time-line
style UI's (like the dopesheet) can show the "when".  At least, that's
a direction I'd like to see things move in.
   As an animator, the less I have to use conceptually abstract UI's
like the graph editor, the better (although it's always useful to have
in a pinch ;-)).

> Regarding directly editing keyframes on the timeline:
> In general, I'll have to admit to being quite pessimistic about the
> worth of this;

   Ditto.  IMO this functionality should stay in the dopesheet/action
editor.  The timeline should just be for scrubbing and managing
markers.

> Could you outline
> some scenarios where simply collapsing all the channels in the
> dopesheet doesn't satisfy this sort of workflow yet?

   I don't mean to sound like a broken record here, and my intent is
not to nag, so please don't take this the wrong way.  The animato
design is up to you, obviously.  But... since the dopesheet organizes
by action (which makes sense), and since actions are per-object, any
animation involving more than one object (i.e. two or more characters
interacting, or a character manipulating a prop) cannot be collapsed
to a single row in the dopesheet.

   If you want to preserve the action-per-object design, this problem
could be solved by having a top-level "summary" row in the hierarchy.

> Also on the subject of the IKEY, I should note here that I had
> originally intended keyframes to be able to be added simply by using
> some simply key (like IKEY) without a menu but with a semi-transparent
> tooltip confirming the operation which would appear and fade out in a
> non-blocking way. Alternatively, a more complicated hotkey combo could
> be used to show the menu to choose the keying set to use.
> Unfortunately, that confirmation menu doesn't seem immediately obvious
> how to implement, and last time I checked there might still have been
> hotkey clashes that'd need to be resolved.

   IMO, it's worth implementing that functionality even without the
tooltip for now.

--Nathan V

On Thu, Oct 1, 2009 at 1:14 AM, Joshua Leung <aligorith at gmail.com> wrote:
> Hi,
>
> A great read :) Sorry for the rather long mail, which seems to have
> gotten longer as I typed it...
>
> I second the remarks regarding the move towards more "traditional"
> based workflows. Indeed I've been taking inspiration from the
> workflows of 2D-animators when thinking about "the next step"
> regarding how to make the animation tools even better (see later
> comments).
>
> Regarding directly editing keyframes on the timeline:
> In general, I'll have to admit to being quite pessimistic about the
> worth of this; whether this is really something that really requires
> spreading this sort of editing to yet another place. Could you outline
> some scenarios where simply collapsing all the channels in the
> dopesheet doesn't satisfy this sort of workflow yet?
>
> Having said that, something which has been on my todo list for the
> past few months is to develop a generic "widgets API" for coding
> things like transform manipulators which are possibly what we're
> really looking for here. One of the primary tools which I feel would
> fit quite nicely under this would be some kind of "box transform"
> widget. That is, you draw a box over some region of keyframes, then
> use the handles provided by the box to manipulate the keyframes. From
> what I understand, this would be sufficient for most of the common
> tasks when blocking, i.e. moving bunches/sequences of keyframes back
> and forth. Functionality such as having to select and deselect
> individual keyframes comes across as being a bit of a nuissance for
> such a 'broad scale' operation I think.
>
>
> Regarding marking keyframes as breakdowns, etc.:
> This is currently supported by the DopeSheet, but I agree with you
> that it would probably feel more natural to be able to have keyframes
> tagged as being breakdowns/extremes/etc. when they are created.
> Currently, it's more of a create then tag situation, which makes it
> kindof like book-keeping rather than a useful aid.
>
> I don't really agree with using IKEY twice quickly, but perhaps
> something more like a toggle somewhere (timeline header?) where you
> can toggle the type of keyframes being inserted. This possibility I
> suggest since you're more likely to go through adding all of a certain
> type of keyframe first, then go and add some others to refine the
> motion (i.e. storytelling poses first in 1 pass, then blocking poses
> go in between those poses, etc.)
>
> Also on the subject of the IKEY, I should note here that I had
> originally intended keyframes to be able to be added simply by using
> some simply key (like IKEY) without a menu but with a semi-transparent
> tooltip confirming the operation which would appear and fade out in a
> non-blocking way. Alternatively, a more complicated hotkey combo could
> be used to show the menu to choose the keying set to use.
> Unfortunately, that confirmation menu doesn't seem immediately obvious
> how to implement, and last time I checked there might still have been
> hotkey clashes that'd need to be resolved.
>
>
> Regarding the Rig-Drawing Ideas:
> I'm not sure if you've seen the work by cesio (a py script/scriptlink
> which provided similar functionality). Seeing this, I added a kindof
> experimental modifier, the 'Mask' Modifier which you may have
> encountered, which does this sort of thing. The basic idea behind this
> modifier was that it only showed the parts of the mesh which were part
> of the vertex-group it was using. So, by linking up a script which
> captures what bone was clicked on, setting certain vertex groups for
> the mask modifiers on a duplicate copy of the mesh (with some custom
> material), you could get a similar feature. The only problem was that
> for the 2.4x depsgraph, selections of bones could not trigger proper
> updates of the mesh modifiers.
>
> I've begun to come to the conclusion that more 'mesh-based'
> visualisation techniques for rigs (i.e. ghosting and also selecting
> controls) should be the way of the future. These are certainly areas
> I'd like to work further on in the next few months, unless there are
> some more pressing demands for Durian.
>
> It's kindof timely that you mention the custom attributes drawing
> issue. The approach you are suggesting seems to be quite heavily
> influenced by Modo and probably more particularly Messiah. I'm not
> sure what the best way forward for this is yet.
>
>
> Animation Tools:
> * Match transforms - I think we've only got limited capabilities here
> so far, so yep, these will get worked on. Any more details for how to
> make this work nicer would be nice.
>
> * Colour keyframes on the stamp - are you referring to the stamp-info
> for renders?
>
> * Spacing tool - have a look at the "Pose Sliding" tools in 2.5 since
> mid September. The specific tool you describe sounds pretty similar to
> the 'breakdown' one, but there are also some to help with "pushing"
> and "relaxing" poses. I was kindof inspired to code these after
> browsing through a copy of Richard William's book, and seeing his
> discussion on "spacing" issues.
>
> * Euler filter - there's a framework for this lying around in the
> code. I just need some time to work on it (or if someone else is
> interested, I can review patches for this. Hint: the code is in
> graph_edit.c) ;)
>
>
> Regards,
> Joshua
>
> On Thu, Oct 1, 2009 at 11:40 AM, Gianmichele Mariani
> <g.mariani at liquidnet.it> wrote:
>> http://www.liquidnet.it/AnimationProposal.pdf
> _______________________________________________
> Bf-animsys mailing list
> Bf-animsys at blender.org
> http://lists.blender.org/mailman/listinfo/bf-animsys
>