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

[malefico]

Hi,

After reading, I understand that the only practical reason for an 
animator to have a NLA metastrip (or NLA bag) would be to import a 
complex sequence of actions into a character/object. Is that right ?

On a slightly off-topic discussion I would like to express a wish here, 
not exactly a feature request since I don't have the technical 
background as to foresee the feasibility of this idea. So far shapekeys 
and drivers are a property of meshes. This has proved to have serious 
limitations, mainly great difficulty to transfer shapekeys among similar 
(topologically speaking) meshes, which usually means rebuilding 
shapekeys everytime a character changes/is created.

I was wondering if it would be possible to have a sort of shapekey 
defined in a topological way, and that be a property of objects instead 
of meshes, so ideally, if the mesh changes, then all "object shapekeys" 
could be transparently applied/trasferred to the linked mesh.

The above paragraph mind sound like nonsense now that I read it again, 
but I don't want to enter here in feature-based proposals but just to 
bring up the problem of current system and maybe inspire an original 
solution from the creative minds here.

Best regards

malefico.

Ton Roosendaal 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
>
>