[Bf-animsys] NLA Mockups

[Joshua Leung]

Hi,

On Sat, May 16, 2009 at 7:34 AM, bassam <bkurdali at freefactory.org> wrote:

> On Sat, 2009-05-16 at 00:19 +1200, Joshua Leung wrote:
> > Hi all,
> >
> > To get the discussions rolling again, I've (finally) scanned some of
> > the mockups of how I imagined the NLA editor would work.
> >
> > Firstly, the original design docs (written around June-September 2007)
> > for the NLA system:
> > http://aligorith.googlepages.com/animsys2007_nlaplans.7z
> > Some of the things mentioned here are no longer relevant, but the
> > parts on NLA should still be largely relevant.
>
> >
> >
> > Keeping this in mind (and the plans I outlined in
> > http://aligorith.googlepages.com/250_NLA_GSoc09_overview.doc), I've
> One comment on your docs about editing an action being referenced by
> multiple strips, maybe if the user is editing keyframes in an action,
> then all the strips referencing it could get highlighted in some way?
> that way the user knows she is affecting multiple strips, and can do
> something about it if it is not intended behavior (if the nla is
> visible). I agree that blender should not make assumptions about what
> the user wants.

Yep. That was one idea of had (probably highlighting them in red or
something eye-catching like that). It should drive the unexpecting user into
shock, which is exactly what we want ;)


> on blending modes:
>
> does it make sense that 'blend' is the same as 'replace' but with a
> weight? i.e. 50% weight on the top strip leads to blending, but 100%
> weight on the top strip leads to replacing? (this is just devil's
> advocate)

Yep. That's basically what it does.

add currently could work for little tweak actions, for instance, if you
> have recorded some hand shake and want to layer it on top of a larger
> hand motion (or camera shake)

This morning I just recoded this in my branch (look out for the commit soon,
though not usable). I found that the old version actually didn't work as
such 'additive' things should, it was really just blend/replace in disguise.


> subtract I can't come up with a use case for.
>
> multiply I'm not sure about either- I know harkeyman said it would be
> useful for certain things but I never understood how ; I'll leave it to
> others to come up for a use case for the last two.

Let's implement it, play around with it, then decide if these are absolutely
useless :)


> >  recently made some more 'modern' mockups:
> > - http://aligorith.googlepages.com/250_nla_plans_02.jpg  <--- an
> > example of NLA with all the different types of interactions that could
> > occur.
>
> I really think an order of evaluation from the bottom up is better:
> 1- it is more consistent with the sequence editor.
> 2- it is more consistent with my understanding of the active action
> track, though I could be wrong on that one.
>
> If it is reversed (top down) then the sequence editor should probably be
> made to match it (or we should abandon trying to share ui between the
> two)- and most nle evaluate bottom up. bottom up is generally more
> intuitive for people in this view.
>
> Note: I think e.g. constraint and modifier stacks can remain top down,
> and do not need modification, since the ui for them looks quite
> different, but if you do change them to bottom -> top, that is ok too
> (but probably complexifies the ui code)

OK. The new mockups show this as bottom to top. The one labelled '02' was
from a few weeks ago before I heard about the preference for bottom up.


> *I'm not sure what the curved transistions between track 3 and 4 mean.

Those are just transitions between two strips on different tracks.


> > - http://aligorith.googlepages.com/250_nla_plans_01.jpg  <--- honing
> > in on this more carefully with a more simple example
>
> personally I like the 'action' line at the top of the nla, I would also
> wonder if it might be nice to have a 'clear' button as well as a push
> down (or simply by deleting the 'strip' next to the action), use case:
> animator is editing on the NLA.
> animator wants to tweak a strip's action, so double clicks, or uses a
> hotkey/etc to 'activate' the strips's action .
> the action is now in the active action slot on top.
> animator edit's that action, possibly using the dopesheet or just the 3d
> view.
> animator does not want the action to be active, and does not need to add
> a new strip, so just clear it from being active.

I was thinking that this could be simply done by getting out of strip-action
editing the same way you got in (i.e. via hotkey), though I don't see any
harm in having a button like that there.

Though I suddenly realised that having these buttons there inline might
confuse between 'actions/operators' and 'settings', though I personally
think it should be fine if we make enough of a visual distinction...

note: what happens if the animator just starts keyframing? does it just
> add a new action, or if there is an existing active action, adds the
> keys into that one? this seems the most error free way to go, otherwise,
> I forsee too much trouble trying to 'guess' the right action to slot the
> keys into.

Whatever action is the active action, the keyframes go into it. That's the
one of the main reasons for this whole action-line concept. As I said in the
doc, the user enters 'editmode' on a strip in some track, this strip's
action becomes the active one, and tracks after the track being edited get
disabled. Thus, the system will only 'see' the last action, and put
keyframes into it (and also editing via Dopesheet + Graph Editor). Once you
exit editmode, all is back to normal.


> corollary note: there should be an easy way to copy keys/curves from one
> action to another, presuming we have added them into the wrong one.

Dopesheet/Graph Editor copy + paste... Unless a more advanced method is
needed.


Joshua
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-animsys/attachments/20090516/db0f877a/attachment.html>