Hi,<br><br>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...<br>
<br>Header-File of the Core Data Structures for the Animation System:<br><a href="http://aligorith.googlepages.com/anim_types.h">http://aligorith.googlepages.com/anim_types.h</a><br><br>Note: this is not the most up to date version of this file yet (I may update it later today). <br>
<br>As can be seen, I have decided to abandon some aspects of the old system. Notably:<br>1) IPO blocks are no more. <br>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. <br>
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.<br>
<br>2) Actions therefore become the infamous "IPO-bag"<br>Since there are no more IPO-blocks, the motion curves must go somewhere. Now, they are directly stored in Actions. <br>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. <br>
Action blocks are therefore the basic unit of animation reuse then. Let's face it, reuse of IPO blocks was nasty and confusing...<br><br>3) F-Curves<br>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.<br>
<br>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).<br>
<br>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.<br><br>4) Separation of Drivers and Animation Data<br>
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. <br>
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.<br>
<br>5) Animation Data block - stored in each major ID block<br>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.<br>
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).<br><br>Phew... that should cover the main points...<br>
Questions anyone?<br><br>Joshua<br>