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

[Nathan Vegdahl]

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.
   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.


   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.

   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

On Thu, Jun 11, 2009 at 5:47 AM, Joshua Leung<aligorith at gmail.com> wrote:
> Hi William,
>
> A few comments about issues raised in your vid:
> http://www.reynish.com/files/blender25/newnla.mov
>
> - Firstly, the crashes you got. I haven't been getting any crashes in any of
> the ways that you seemed to be getting. Loading old files, keyframing as you
> did also, etc. all work without crashes. No idea what's going on there with
> those :/
>
> - The offset bug (where offsetting the clip resulted in actions not being
> played) you pointed out, I fixed earlier today. I kindof discovered it in
> another way, but at least its now fixed :)
>
> - The bug where moving the strip past frame 0 resulted in clipping has been
> fixed (just now). However, this sort of clipping behaviour still remains for
> now with transforms (on my todo!).
>
> - Moving strips between tracks - on the todo for transforms. Probably need
> to code some special transforms for this...
>
> -  About that issue with the bottom strip not playing when the top one
> wasn't really overlapping it. In theory, that's something you can tweak by
> changing the extrapolation mode for the top-strip using the NKEY properties
> (those weren't working yesterday, since they didn't work on the defaults by
> worked fine in my own defaults file). However, perhaps some more automated
> system for handling that might be in order...
>
> The basic cause of the problems here, was that the top strip was exerting
> its influence before+after its own range since when it was added, it turned
> out to be the 'first' NLA-strip so got the extend-before+after option. Since
> we're treating each track as a separate layer which gets added on top of the
> previous layers, the top strip ended up overwriting the results of strip in
> the first track. Watching your video, I realised that how I've made this
> work doesn't quite work with in-practice usage (if users start drastically
> shuffling the order of strips as you did).
>
>
> - Regarding the whole action/tweaking/etc. concepts. Perhaps the current
> interface doesn't communicate this clearly, we're going to need a note of
> this somewhere, or this idea sucks in which case I'm stumped :/
>
> The easiest way to think about how the active action works is by saying, the
> active action (the orange/pink channel that shows up under the names of the
> objects) is always evaluated last and on top of whatever NLA stuff we've set
> up. Inserting keyframes will result in keyframes being added to this action,
> and if no such action existed before, a new action is created. The active
> action is attached to / is a property of the AnimData block, no matter what.
>
> The motivations behind this are:
> 1) You don't need to think, "where are my keyframes going", since they only
> ever go to the active action
> 2) NLA has 2 usage scenarios - a) use and combine multiple existing actions
> into some sequence, b) create animation in a layered/multi-pass
> (blocking+refinement) process. Both of these inevitably require some
> 'tweaks' to be made on top of the existing motion created through
> stacking+arranging strips, so you'll need to add some keyframes in places to
> get this working nicely.
>
> Going on the OLD + UGLY 2.4x way, we'd have to add a new strip using a blank
> action before we started, but that almost inevitably results in some strip
> that is oversized, will be scaled in a weird way or have keys placed in
> 0.0000000001 or so frames from each other due to weird scaling issues,
> etc.;  not to mention the added complexity for the animator of remembering
> that you've got some NLA stuff already, so you need to throw half of what
> you know about animating in Blender out the window for a moment to satisfy
> the NLA dinasaur that you want a new action to start adding tweaks in. This
> is really quite an ugly scenario, that IMO was one of the areas in which the
> old NLA system seriously locked many users out on, and was the cause of
> numerous ugly bugs (/me admits to still having nightmares after seeing a
> file demonstrating these problems)...
> Anyways, in the new system, you simply start inserting keyframes. If you're
> not tweaking some action already used by some strip, the keyframes get added
> to a new active action, which will override the ugly motion you're trying to
> correct. Once you're done, you simply push it onto the NLA-stack as new
> clip, and voila! ugly motion fixed.
>
> Now, I mentioned 'tweaking' actions used by some strip already. As you
> pointed out in your vid, you have to explicitly enter tweakmode on a strip
> to edit its action. Why did I do this?
> If you just selected a strip, and had this happen, there would be quite a
> lot of technical fumbling that needs to go on behind the scenes, setting the
> active action of the AnimData block to the action of the strip and storing
> the previous one, disabling all tracks after the one being tweaked, and
> flagging all strips which use the same action; then this is potentially a
> lot of overhead incurred as a simple consequence of clicking on a strip to
> perform some operation on it, something which occurs VERY commonly.
>
> Let's take a step back and have a look at a few of these behaviours. We
> store the current active action to restore after we leave tweakmode as we
> might have been midway through some tweaks there. Disabling all tracks after
> the one in which the strip occurred, comes from the second usage scenario
> (block + tweaks), where by editing a strip in an earlier track, we're going
> back to an earlier/rougher stage (like in construction histories) so we only
> want to see the effects of editing this early stage (and not of all the
> later ones too on top of our basic edits, cluttering our view). Flagging the
> strips which use the same action is really a bit of a safety feature,
> intended to remind or alert a user that they may be making some change to
> the action the mulitple strips use, thus creating unintended consequnces
> (I'm sure this happens quite a bit, though hopefully not too often)
>
> However, the most important issue here, is that if we just enabled editing
> on any action as soon as we clicked on it, we'd start messing with the
> clarity of simply inserting keyframes and pushing this down to create a fix
> for some problem we see. Users would start getting confused about how they'd
> be able to start making changes to the results of the NLA stack. We'd
> effectively be stuck in the old mindset of "add strip of blank action, of
> some arbitary 1 size fits all length, then try and add keyframes to this to
> fix the problem", which just gets in the way of the primary job of animators
> which is creating motion (not figuring out how to add a block of the right
> size to a stack of blocks).
>
> Sure, this approach is somewhat clunky, entering and leaving tweakmode per
> strip. There are a few things we could do to alleviate this a bit, i.e.
> allowing to change between strips in the same track?. Also, the editing
> in-place issue/request mentioned in the vid is somewhat todo.
>
> --
>
> Phew! Hopefully this clears up some of the issues, and I hope I haven't
> missed out any really important pieces of info here.
> Joshua
>
>
> _______________________________________________
> Bf-animsys mailing list
> Bf-animsys at blender.org
> http://lists.blender.org/mailman/listinfo/bf-animsys
>
>