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

[Joshua Leung]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-animsys/attachments/20090612/7a2e3847/attachment.html>