[Bf-animsys] NLA Mockups

[bassam]

On Sat, 2009-05-16 at 12:50 +1200, Joshua Leung wrote:
> 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.
yeah, I think there was something odd about it, now that you mention it.
>  
>         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 :)
cool, fine by me )
>  
>         >  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.
cool. 
>  
>         *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... 
I don't mind if it's buttons or hotkeys, better let the interface folks
weigh in on this... broken? william?
> 
> 
>         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.
cool, this is what I expected as sane behavior.
>  
>         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. 
nope, that's fine.
> 
> 
> Joshua
> 
> 
thanks for taking the time to answer.
bassam