[Bf-taskforce25] RNA-IPO

[Roland Hess]

Brecht -- I think is a really useful concept.

Long long ago (before ED/Orange) I had written up a complete animation 
system proposal, and one of the things I had mentioned was the need for 
some hiding of the backend from the user, and a more unified animation 
eval pipeline. I had originally suggested that all animation route 
through a master evaluator (the NLA at the time), and that anyone 
animating anything would create an Ipo (of course), but would also, in 
the background, create both an Action and an NLA entry, unbeknownst to 
and un-noticed by them. Of course, if the user is just doing simple 
animation, they only ever work with the Ipo curves.

However, if they need to get an overview of a bunch of Ipos, they go 
into the Action editor, where they find their work already visualized. 
And if they need even higher level tools, they move to the NLA Editor.

Something like what you're talking about would make that very possible, 
as well as a couple of other cool things for animators.

The first that comes to mind is the ability to tag such a SuperAction 
with an Ipo of it's own and chain it to a driver. You make a whole 
SuperAction for a change in facial expression -- really tweak it out -- 
then set that to be driver by a single controller. And, if the promise 
of the event refactor really kicks in, you could have that driver 
chained to a real interface widget instead of a cheap "bone" control in 
the armature, and have it all animation controls gathered under a single 
SuperAction for convenience.

So yes, I think this is a very useful idea and worth pursuing in the future.

Roland

> Hi,
> 
> I'm not an expert at the animation system at all, however to me there
> does seem to be overlapping functionality here which is not useful but
> rather historical. I think that we could make the system more powerful
> by introducing something that is a merger between an IPO-block, an
> Action, and a list of NLA strips. Let's call this a SuperAction. It's
> not necessarily a merger but perhaps more like a base class .. the thing
> that you manipulate to organize animations at a high level.
> 
> (Note I'm not the one who works on the animation much at all, so take it
> as an just idea which is perhaps not feasible to implement in practice!)
> 
> 
> Let's think of all structs and properties in a scene as having a static
> and fixed value. A SuperAction then is a change to those values, which
> can be just a change at one frame, but of course also over time. It is a
> datablock that you can apply at some point in a scene, typically at an
> object, or a material, but also at the scene level affecting multiple
> objects for example.
> 
>>From the user point of view you don't need to think necessarily of what
> it contains, IPO blocks, Actions, NLA strips .. it's just a set of
> changes to the thing you apply it to. Kind of like a diff/patch or
> perhaps a branch in developer terminology.
> 
> For simple cases it's just attached to a single ID block modifying it's
> values. In that case it would just contain some Ipo curves and
> expressions for example, and you don't have to worry about naming it or
> making it reusable. In more complex cases you can of course then give it
> a proper name and use it on multiple objects.
> 
> 
> Now the second important thing is that SuperActions can use other
> SuperActions. If you want to put everything in a single SuperAction that
> would be possible, but if you want to reuse some part of that, a few Ipo
> curves, a leg animation or a full character animation, you can make that
> it's own ID block, and reuse it in another SuperAction. In fact that is
> how I imagine NLA strips to work then, you can combine multiple
> SuperActions, blend them, apply modifiers etc, and the result is again a
> SuperAction.
> 
> The contents of a SuperAction are a bit more complicated because they
> can contain a bunch of different things. The point is that you would
> edit them differently depending on the contents but from the outside it
> looks the same, it's just some change over time.
> 
> Also important is, how do you know what the contents of a SuperAction
> affects? This is where RNA paths come in. For example you could have an
> action attached to a Group containing multiple objects. This could
> contain RNA paths and IPO curves for example.
> 
> Group SuperAction:
> objects["body"].bones["lefthand"].loc[0] -> IpoCurve
> objects["helmet"].rot[0] -> IpoCurve
> 
> However you might want to split that up a bit for clarity or reuse:
> 
> Body Wave SuperAction:
> bones["lefthand"].loc[0] -> IpoCurve
> 
> Helmet Tilt SuperAction:
> rot[0] -> IpoCurve
> 
> Group SuperAction:
> objects["body"] -> Body Wave SuperAction
> objects["helmet"] -> Helmet Tilt SuperAction
> 
> 
> There are many possibilities and difficulties with such a system which I
> can't all predict or explain, this is just the rough idea.
> 
> Brecht.