[Bf-taskforce25] NLA system thoughts

[Nathan Vegdahl]

>> 3) The user should have to *explicitly* create new actions.  Blender
>> should *never* *ever* implicitly create actions without explicit user
>> intervention telling it to do so. (The default scene action is the
>> only exception.)
>
> What? this doesn't make sense.... You're implying that actions shouldn't
> ever be created by either Blender or the user!

Sorry, my explanation was confusing.  I mean that *only* the user
should create actions.  Blender should never do so implicitly.
(Obviously at least one of them needs to be able to do so.  I'm saying
that it should be the user.)

For example, right now object-linked actions are created implicitly
when you insert keys on an object.  IMO this is a bad behavior.  The
user should have to do this explicitly.  I know this doesn't fit in
with your object-per-action philosophy, but I guess I'm rejecting that
as well.  The way things are right now makes actions seem more like
low-level per-object storage, instead of high-level animation
organization.

--Nathan

On Fri, Mar 6, 2009 at 2:26 AM, Joshua Leung <aligorith at gmail.com> wrote:
> Hi,
>
> On Fri, Mar 6, 2009 at 1:49 PM, Nathan Vegdahl <nathanvegdahl at gmail.com>
> wrote:
>>
>> 1) The NLA editor should be, ideally, extremely similar to the
>> sequence editor.  There really isn't any reason to have the two
>> interfaces be particularly different, or to have the user interact
>> with them any differently.  Therefore: why not use the same UI code?
>> This unifies the user experience greatly, and reduces coding work both
>> now and in the future.  Only very small changes would need to be made
>> to accommodate NLA editing.
>
> Certainly there can be a great amount of overlap between the two. However,
> where this idea breaks down is when you start trying to figure out which
> 'Object' or datablock the strips belong to. Perhaps this is why you proposed
> the single scene-level action?
>
> Or were you meaning with this idea that the fancy strip-drawing code and
> multiple-strips in a single row things should be used? If this is what you
> meant, that certainly this is what I intend to do. NlaTracks can contain
> multiple strips.
>
>>
>> 2) IMO, ideally by default there is a single scene-level action that
>> *all* animation goes into.  Then, if someone is just animating
>> normally (i.e. no NLA) they don't have to know anything about NLA, and
>> they don't get confused by action references popping up all over the
>> place in the Graph Editor and Dopesheet.
>
> Hmm... I don't really like this idea too much... at least not yet ;).
>
> The reason why I've currently got the system set up to create actions per-ID
> (i.e. mostly object, but can be other things such as materials, lamps, etc.
> by default), is that as soon as you want to directly make one datablock use
> some keyframes created for a similar one, you get stuck with the problem of
> having path matching issues.
>
> Also, for efficiency sake, it should be known that settings should be
> animated in an action that is located as close to the datablock where the
> setting exists.
>
> Another more worrisome problem though, is being able to maintain some of the
> organisation-related goodies we can provide easily by simply sticking (for
> the most part) to attaching to objects/datablocks with flexibility to do
> things some other way. Once you start trying to lump everything from several
> objects, potentially several characters with hundreds of bones each, from
> the same scene into a single action, it will quickly become prohibatively
> difficult to manage these for the animator as it quickly becomes confusing
> which character a particular bone or channel belongs to.
>
> I remember at one stage I've contemplated auto-generating hierarchies for
> channel displays based on the RNA-paths, but abandoned the idea due to the
> complexities + overhead involved with that. For each channel, you'd need to
> disect the path to obtain the relevant hierarchial divisions, and based on
> these check whether the channel fits in under the same headings as a
> previous one did, and create/add levels + the channel as appropriate. Also,
> this leads to the problem of making sure that any 'channels' (i.e. levels,
> etc.) created dynamically can be expanded in some way...
>
>>
>> 3) The user should have to *explicitly* create new actions.  Blender
>> should *never* *ever* implicitly create actions without explicit user
>> intervention telling it to do so. (The default scene action is the
>> only exception.)
>
> What? this doesn't make sense.... You're implying that actions shouldn't
> ever be created by either Blender or the user!
>
>>
>> 4) Similarly to #3, the user should typically have to *explicitly*
>> switch the action they are currently working on.  Blender should
>> *almost* never implicitly switch actions, except where it really makes
>> sense to do so. (I can't think of any cases where it would make sense,
>> but I have a gut feeling there might be some.)
>
> This isn't that relevant with the dopesheet/graph editors, but is probably
> relevant for the action editor.
>
>>
>> 5)  The typical workflow for working with actions should be to
>> create/switch to the action you want to work on, and start animating
>> as you normally do.  All keys that you add (regardless whether they
>> are for objects, materials, modifiers...) go into the currently active
>> action.  And all displays/editors reflect the current action.
>
> To a certain degree, absolute Keying Sets solve this problem for the most
> part.
>
>>
>> 6) The action that you are currently working on should be obviously
>> reflected in the UI somewhere.
>>
>> More complex features can be layered on top of these 6 points (such as
>> actions within actions), but unless someone can convince me otherwise,
>> I think it's important that this be the basic way that NLA works in
>> Blender.
>>
>> I hope my explanations made sense.  If any of you need clarification,
>> do not hesitate to ask.
>>
>> --Nathan
>
>