[Bf-taskforce25] RNA-IPO

[Joshua Leung]

Hi,

It's great to see some discussion on this. I've been spending the past few
days reexamining the roles of different aspects of the Animation System,
trying to simpliy it down to a more unified system, that will not be
unfairly biased towards certain types of animation (i.e. the current
'transforms over settings' bias, though admittedly, I'm more interested in
making keyframe animation tools many orders of magnitude "more awesome" than
those for mocap). Originally, I was planning on presenting an 'almost-done'
prototype later this week, but it seems it might be beneficial to
discussions if I released some of the work I've been doing. Appologies for
the long text...

Header-File of the Core Data Structures for the Animation System:
http://aligorith.googlepages.com/anim_types.h

Note: this is not the most up to date version of this file yet (I may update
it later today).

As can be seen, I have decided to abandon some aspects of the old system.
Notably:
1) IPO blocks are no more.
In the past (i.e. when the system was designed for Blender <= 1.0) , these
were used to separate settings on "ID-datablock" and/or "fake-datablock"
level. While this worked great when Blender was still a very small app, and
most data was stored directly in datablocks only, it is evident that this
has not worked well. The 'fake datablocks' (i.e. for Sequences,
PoseChannels, and Constraints), which used some ID-codes which weren't
actually used for any ID-block, required some complex context mungling and
special variables to be added all over the IPO Editor and Keyframing code.
Secondly, while this sort of separation may initially seem logical, upon
closer inspection, it can be seen that it causes quite a few problems for
users, as it means that in some scenarios, they may end up with a bunch of
separate IPO-blocks with perhaps 1 - 2 curves in each to control some
'simple' thing as a headlight of a car.

2) Actions therefore become the infamous "IPO-bag"
Since there are no more IPO-blocks, the motion curves must go somewhere.
Now, they are directly stored in Actions.
Action-channels are no more, as they simply referenced IPO blocks. Gone also
is the blocktype restriction, as using RNA-paths or a similar system removes
the need to have blocktypes to help keep the settings <-> curve matches
managable.
Action blocks are therefore the basic unit of animation reuse then. Let's
face it, reuse of IPO blocks was nasty and confusing...

3) F-Curves
As a result of the above, IPO-curves are now known as F-Curves, which seems
to be a more common name for motion curves. Mentioned earlier was the usage
of RNA-paths. The basic idea here, is that a F-Curve will correspond to some
setting based on the ID-block that the animation data (that the F-Curve
belongs to) is stored in, and use a 'generic' RNA-path originating from the
ID-block in question to the setting it affects. This should allow data to be
remapped easily, by trying to keep out as many specific references to data
as possible.

When this auto-remapping does fail though, the Remapping Table (stored
outside of an Action, but only relevant to the specific action + ID-block
pair it was created for, thus reducing the baggage stored in the Action)
acts as a mechanism for users to tweak the correspondance, by replacing
'offending' parts of the paths as necessary. Remapping Tables should be a
last resort that shouldn't need to be used too often (I hope).

It should also be noted here, that I've introduced the concept of
'modifiers', that operate on F-Curves to automatically generate or modify
them procedurally, thus providing greater control.

4) Separation of Drivers and Animation Data
Drivers/expressions (expressions are just PyDrivers) are now stored separate
from Animation Data. While the drivers are still stored as a member of
F-Curves, standard F-Curves stored in Actions cannot get drivers at all. In
production rigs, riggers/character-TD's want to keep such things hidden from
animators so that they cannot get accidentally removed, thus breaking rigs.
Besides, this separation of rig data (drivers are part of a rig, NOT
animation data) has several other benefits. Firstly, it should be more
efficient to not have to check if some curve is a driven or not before doing
stuff with it. Secondly, by storing them separate, we can now allow more
dependencies to be resolved ok, as the drivers can be sorted freely by the
depsgraph to be in a suitable order, thus allowing things such as bone-bone
dependencies within the same rig.

5) Animation Data block - stored in each major ID block
The bAnimData block is now used to group all animation-related data
together, so that it can be stored as a discrete unit per ID-block that will
be animatable (screens, actions, and a few others are justified exceptions).
List/stack of drivers, active action, and NLA tracks stack (tracks each
contain multiple strips, strips reference actions) are contained in this
block. Remapping info is stored for the active action here, and also in the
NLA strips for the actions they reference.
The animation data in the bAnimData block only affects the sub-data of the
ID-block in which it resides (i.e. only data that can be reached via
RNA-props from the ID-block that the bAnimData is stored in).

Phew... that should cover the main points...
Questions anyone?

Joshua
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-taskforce25/attachments/20090108/c135145b/attachment-0001.htm