[Bf-animsys] Animation Proposal

[Joshua Leung]

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