[Bf-animsys] William - NLA Tests Vid (2009 June 10/11)

[Nathan Vegdahl]

> Actually I don't think this is so much of an issue. Luckily I think it's a
> misinterpretation to say that all management of actions happens in the NLA.
> The Action Editor (hidden inside Dopesheet) still has an active action,
> currently stored in ID blocks.

   Ah... okay.

   Yeah, I think part of the confusing thing about all of this is that
"tweak mode" is like making clips active, rather than actions.  Also
that it's possible to not have an active action seems strange, which
then results in adding keyframes --> new action.
   Maybe this is something I could get used to, but it does seem to
introduce confusion in the interface.

   So an alternative proposal: what if we make it more action-centric,
rather than clip-centric, so the action being edited is the one that's
active in the action editor?  The active action can then be reflected
in the NLA editor by highlighting all the clips that reference the
active action.  Then pressing tab in the NLA editor isn't changing
into a mode, but rather is a shortcut for making the action of the
selected clip the active action.

   But if we go with this workflow, a tricky part is then: how to deal
with duplicate clips in the NLA editor?  In other words, if there are
several clips that reference the same action, and if that action is
active, which clip defines the editing timeline?  Any ideas?  Maybe
just whichever clip is closest to time cursor?

--Nathan V


On Fri, Jun 12, 2009 at 7:35 AM, William Reynish<william at reynish.com> wrote:
>
> On 12 Jun, 2009, at 8:50 AM, Nathan Vegdahl wrote:
>
> Regarding the tweak mode:
>
>   I don't think the issue is that you have to hit tab to tweak a
> strip.  Personally, I think that's fantastic, and mirrors really well
> "edit mode" for objects, as well as keeping things clear to the user
> as you said.
>
> Hmm, maybe, but the confusing thing is what happens when you're not in 'edit
> mode' and insert keyframes. Apparently, this automatically creates a new
> action above all others in the NLA. To move that action clip around you have
> to freeze it. This is really confusing IMO - Blender shouldn't assume to
> create actions without user input. Instead, Blender should always have an
> active action, one where new keyframes go.
>  This active action can be any action the user has created, or a new one.
> I see the 'Edit Mode' feature more like 'Make Local' in the 3d View. You use
> it to focus on one action, undisturbed by other actions. It's a little weird
> if it's the only way to get at actions, at the very least because, as you
> say, actions can be used for so many things.
>
>   Rather, the issue is that when you specify a strip to be tweaked
> (by hitting tab), you can no longer select and move around other
> strips until you exit it.  In other words, it blocks the NLA
> interface.
>
>   Perhaps, instead, hitting tab can be more like "marking" the strip
> to be tweaked, rather than entering a mode?  That way it doesn't block
> the rest of the NLA interface.
>
> Right. But then again then why have that edit mode at all ? ;) Why not just
> have an active action ID browser in the dopesheet to select the action you
> want to work on. This is where new/tweaked keyframes go.
> Of course the NLA controls what you actually *see* , because everything is
> piped through the NLA. If you want to see the current action undisturbed by
> NLA stuff, it'd be useful to have a 'Make Local' button (or even Mute
> Unselected - hotkey can be '/' to be consistent with 3D view). This would be
> more useful than an edit mode, because it's non-blocking.
> The difference between this and the current NLA branch is this:
> -no manually jumping back and forth to edit actions or NLA strips
> -user seamlessly works on both actions and NLA
> -user can immediately see the 'result' of the action changes made in
> context, instead of having to switch modes to actually see how the action
> looks when combined in the NLA editor
> -replace Edit Mode button with Mute Unselected to see current action as-is,
> undisturbed by other strips in NLA.
>
>   On a somewhat related note, I'm curious if you have any ideas for
> how to deal with actions that aren't represented as strips in the NLA
> editor?
>   For example:
>
>   1. Bob is creating a library of actions to be used by a crowd-sim
> script he wrote.  While he could put these actions on the NLA editor
> as strips in order to work with them, this seems rather clumsy.
>
>   2. Jerry is creating and editing actions that are used only for
> action-constraints in a rig.  Again, he could line them up in the NLA
> editor, but this seems clunky and a bit ill-suited to the task.
>
>   3. Barbara has already created some actions in another file and she
> appends them into the current file.  She now wants to add them to the
> NLA as strips, even though they are not already represented there.
>
> Actually I don't think this is so much of an issue. Luckily I think it's a
> misinterpretation to say that all management of actions happens in the NLA.
> The Action Editor (hidden inside Dopesheet) still has an active action,
> currently stored in ID blocks. The confusing and annoying part is that the
> NLA seems to automatically add new actions when not in Edit Mode. Plus, I'm
> really not keen on the whole 'freeze' workflow - to me an action is an
> action, and having to freeze it to put it in the NLA editor seems
> unnecessary. Of course you need to add or remove clips, but that's slightly
> different IMO.
> Tha NLA is used for managing clips (clips=actions instantiated in NLA
> editor) however, and I think that's fine.
>
>
>   Mostly what I'm thinking here is that actions have a lot more
> potential uses than only NLA mixing.  And right now it feels like the
> NLA editor is becoming an interface not just for mixing actions, but
> also for creating/managing them.  But creation and management of
> actions is relevant to use-cases outside of the NLA editor.
>   Certainly it's useful to have some overlap here, but I wonder if
> maybe it's a bad idea to combine mixing and managing too much, in the
> same way that combining mixing and editing turned out to be a bad idea
> in the 2.4x NLA interface.  Maybe there needs to be a separate
> interface to take over the primary creation and management of actions?
>
> --Nathan V
>
> _______________________________________________
> Bf-animsys mailing list
> Bf-animsys at blender.org
> http://lists.blender.org/mailman/listinfo/bf-animsys
>
>