[Bf-animsys] 2.5 animsys overview + NLA "Bag" proposal

Nathan Vegdahl nathanvegdahl at gmail.com
Thu May 7 20:25:40 CEST 2009


To answer some of my own questions and concerns:

Localizing actions to objects and other ID blocks would be handy for
at least rigging.  For example, for action constraints it would be
nice to link the action to the object.  This keeps the rig as more of
a self-contained "package".

So I've changed my mind.  Aligorith, as is often the case, is right. ;-)
I'm on-board for actions linked to arbitrary ID blocks.  It's useful
for things outside of a strict animation context.

However, within the context of animation and animators, so far linking
actions to the scene by default still seems like the best solution to
me (paired with the workflow stuff I outlined earlier).  I'm open to
other ideas, of course.

--Nathan V

On Thu, May 7, 2009 at 9:49 AM, Nathan Vegdahl <nathanvegdahl at gmail.com> wrote:
>> You can ignore the 'nla bag' idea for now, that was a proposal...
>
>   Well, just one more thing that occurred to me after I wrote the
> first e-mail.  It's also relevant to whatever design we do come up
> with:
>
>   Actions are used for more than just the NLA editor.  For example,
> they are used for animation in games.  I also imagine they will be
> used to create a library of animations for characters in crowd
> simulations (like Massive).
>   The "NLA bag" proposal is limited to the NLA timeline, making it
> impossible to use for games/crowd-sim/etc.  Whatever "Ipo bag"
> solution we come up with should not limit its use to the NLA editor.
>
>> but you do disqualify Joshua's design and coding work
>> with your idea.
>
>   Really?  Based on your summary, it appears to work very well (even
> naturally) on top of Aligorith's existing work.  I may be
> misunderstanding something, but it seems more like a change of
> direction from this point forward rather than something that requires
> redoing work.
>
>   But in any case, I'm actually fine with ditching the discussion
> from our IRC meetings so far (it's just discussion).  But only if we
> can figure out another *simple* and *unified* way for the user to
> interact with everything, that doesn't require many steps in the
> workflow and doesn't require the user to think too much.  Something
> that a stupid user (like me) can easily keep in their head.
>
>> Moving them all centrally into the scene, or even globally, will create
>> a system that's totally out of control. We want duplication systems,
>> group (& library) linking, proxies, a sane and fast dependency system,
>> etc. All such specs require a well balanced and localizable animation
>> system.
>
>   What do you mean by duplication?
>
>   How does this interfere with linking and proxies?  If actions are
> relevant, they can just be linked too, no?
>
>   How would this impact the dependency graph?
>
>   I'm not attacking here.  These are genuine questions.  I'm trying
> to understand the problems involved.
>
> --Nathan V
>
>
> On Thu, May 7, 2009 at 6:32 AM, Ton Roosendaal <ton at blender.org> wrote:
>> Hi Nathan,
>>
>> You can ignore the 'nla bag' idea for now, that was a proposal... but
>> you do disqualify Joshua's design and coding work with your idea.
>> There's a whole lot of good reasons to keep the actions within a local
>> context. Everthing Joshua and Brecht (RNA) have done sofar assume this.
>> It's already very flexible, and allows 'ipo bags' on every data item,
>> but *inside* context (of object, group, or any other ID item).
>>
>> Moving them all centrally into the scene, or even globally, will create
>> a system that's totally out of control. We want duplication systems,
>> group (& library) linking, proxies, a sane and fast dependency system,
>> etc. All such specs require a well balanced and localizable animation
>> system.
>>
>> What's essential is obviously is to enable 'what you want', but within
>> a design that will also survive what you want as well; which is a very
>> fast, re-usable, flexible and future proof system. :)
>>
>> I think it's well possible to make advanced editing possible, within
>> the current Animato specs. Just a matter of very well analyzing where
>> these use cases are, and how to present it well in the editors. If not,
>> then we have to go back to the drawing board...
>>
>> -Ton-
>>
>> ------------------------------------------------------------------------
>> Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
>> Blender Institute BV  Entrepotdok 57A  1018AD Amsterdam The Netherlands
>>
>> On 7 May, 2009, at 6:46, Nathan Vegdahl wrote:
>>
>>>    Thanks for the summary, Ton.  I think this is good to look again at
>>> the current state of the system, so we're all on the same page.
>>>
>>>    Firstly, I want to point out what an awesome job Aligorith has done
>>> with this.  I've been jumping all over him lately (sorry Ali!) without
>>> taking the time to acknowledge the kick-ass stuff he's already done.
>>>
>>>    One of the thing that's really cool about this system is that it's
>>> so flexible.  In fact, it's such a solid base that I imagine we could
>>> layer just about any user-level paradigm on top of this.
>>>
>>>    The IRC meetings were largely (entirely?) about what this
>>> user-level paradigm should be.  How will actions and the NLA system
>>> work from the user perspective?  If anyone cares to read them, here
>>> are the IRC logs:
>>>
>>> http://storage.cessen.com/temp/nla_chat.txt
>>> http://storage.cessen.com/temp/nla_chat_2.txt
>>>
>>>    Presently the most relevant thing from those meetings was the early
>>> decision to use a "select/create action --> then animate" workflow.
>>> The key points of this workflow are:
>>>
>>> 1. Actions are treated as first-class citizens.  For example: just
>>> like objects, you manually create and delete actions.
>>> 2. There is always a single "active" action.
>>> 3. When you animate, it goes into the currently active action.
>>>
>>>> And of course, a nice 'merge' or 'meta' operator then can
>>>> create the much wanted "Ipo Bag", which should be named
>>>> NLA bag I guess... :)
>>>
>>>    I don't think meta-strips are a good substitute for Ipo bags.  For
>>> one thing, due to possible blending/mixing/transitions within a
>>> metastrip, there is no guarantee you can edit them directly as an
>>> action.
>>>    Also, if we depend on meta-strips for Ipo Bag functionality, how do
>>> we then visualize meta-strips in the Graph and Action editors?  Do the
>>> graph and action editors then get redefined to visualize NLA
>>> timelines?  How is that going to be made simple and understandable for
>>> the user?
>>>
>>>    At the very least I don't want to have to jump through hoops to use
>>> Ipo bag functionality, because for me it is a common and primary
>>> use-case, not a secondary curiosity.  IMO it should be as easy and
>>> simple as possible.
>>>    Speaking for myself, I would ideally like *all* actions to be Ipo
>>> bags, because that's as simple as it gets.  I would love for "action"
>>> and "Ipo bag" to be synonyms, honestly.  And the system Aligorith has
>>> written is easily capable of that by simply linking all actions to the
>>> scene.
>>>
>>> --Nathan V
>>>
>>> On Wed, May 6, 2009 at 7:31 AM, Ton Roosendaal <ton at blender.org> wrote:
>>>> Hi all,
>>>>
>>>> I've spent time with Joshua in irc to get a clear picture to present
>>>> here.
>>>> The first three points represents what Joshua already coded, or
>>>> intended to make.
>>>>
>>>> 1)
>>>>
>>>> Here's the basic structure of the new anim system:
>>>> http://download.blender.org/institute/animsys.png
>>>>
>>>> (For non coders: "Pointer" means "Using". A single Action or Material
>>>> can be re-used all over in Blender, this linkage we do in C code with
>>>> pointers. :)
>>>>
>>>> Each of Blender's "Library" data blocks, which have a relinkable
>>>> generic "ID" header, now also have an AnimData extension. It's
>>>> implemented for about 10 types now, including the Scene ID block (not
>>>> in diagram).
>>>>
>>>> Let's call these things "ID blocks" and not "data blocks" to
>>>> distinguish them from all smaller data segments in Blender (bones,
>>>> constraints, and so on).
>>>>
>>>> The "AnimData" blocks are generic containers appended to ID blocks,
>>>> where the Actions can get linked, and where drivers/nla/expressions
>>>> reside.
>>>>
>>>> The new "Action" is a relinkable container of rna paths and fcurves.
>>>> An
>>>> rna path is a string that can find any data, including all bones,
>>>> modifiers, constraints, and so on.
>>>>
>>>> However! It requires the right context to work, with the linked "ID"
>>>> defining the starting point, from which rna paths can figure where to
>>>> apply fcurves at.
>>>> This means that an Action linked to Object, can have fcurves affecting
>>>> a material. But, such Actions won't do much when directly linked to a
>>>> Mesh or Material itself.
>>>>
>>>> Sofar it's clear I hope!
>>>>
>>>> 2)
>>>>
>>>> Let's zoom in on a single ID block with NLA:
>>>> http://download.blender.org/institute/animsys1.png
>>>>
>>>> The NLA consists of 'strips', which each can link to an Action. The
>>>> strip defines time, scaling of time, blending, etc.
>>>>
>>>> Note that an Action can also be directly linked to AnimData now, which
>>>> will always be executed now, with NLA being acting on top of it,
>>>> replacing it (if it works on same data).
>>>>
>>>> 3)
>>>>
>>>> We zoom out again:
>>>> http://download.blender.org/institute/animsys2.png
>>>>
>>>> Here we see a single hierarchy of ID data, with two levels of NLA
>>>> working.
>>>> Actions or NLA used this way will allow localizing things nicely.
>>>>
>>>> However, we still are too limiting for our animators. They want one
>>>> strip to control a complete massive warrior battle, right!
>>>>
>>>> 4)
>>>>
>>>> For (at least) Scenes and Groups, we can allow any strip to have own
>>>> local "ID context".
>>>> http://download.blender.org/institute/animsys3.png
>>>>
>>>> The NLA editor can nicely visualize it, and allow editing every strip.
>>>> And of course, a nice 'merge' or 'meta' operator then can create the
>>>> much wanted "Ipo Bag", which should be named NLA bag I guess... :)
>>>>
>>>> How modifiers, walk/strides etc will fit in I didn't look at yet.
>>>> Let's
>>>> first check if this could be a good basic to further work with?
>>>>
>>>> -Ton-
>>>>
>>>> ----------------------------------------------------------------------
>>>> --
>>>> Ton Roosendaal  Blender Foundation   ton at blender.org
>>>>  www.blender.org
>>>> Blender Institute BV  Entrepotdok 57A  1018AD Amsterdam The
>>>> Netherlands
>>>>
>>>> _______________________________________________
>>>> Bf-animsys mailing list
>>>> Bf-animsys at blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-animsys
>>>>
>>> _______________________________________________
>>> Bf-animsys mailing list
>>> Bf-animsys at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-animsys
>>>
>>>
>>
>> _______________________________________________
>> Bf-animsys mailing list
>> Bf-animsys at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-animsys
>>
>



More information about the Bf-animsys mailing list