利用者:Aligorith/250 IPO Recode

Motivations (Flaws with current system)

IPO's in General

• Only data with ID get IPO blocks (Sequence is a hack...)
  • Doesn't allow for certain data (like modifiers and nodes) animation
• Reliance on #define-s for each property that needs to be keyframed
  • Doesn't allow for custom animated properties
  • High maintainance - many new options are not made keyframable due to this
    • Each value to be keyframed needs to have a define (access number) created, have this number added to arrays (name and value), lookups set up, added to keyframing menu, etc.
    • As it depends on numbers (adrcode), adding new vars at runtime is not good, as there may be index clashes. This is not good for adding custom types.
• The situation involving adding keyframes is a mess
  • Figuring out where to insert keyframes to (including allocating the destination if necessary) involves the need for a whole bunch of flags to be passed
  • Visual and Needed cannot work with each other as they are implemented as separate copies of the basic insertkey code. These should be unified into the insert_key method somehow
• IPO blocks are executed in a way that is based around the idea that only Object/Bone animations can have any dependency-based execution order
  • All "data" IPO's are evaluated at once, in a preset order (by blocktype)
  • All "object" based IPO's are then evaluated in a later passes after the depsgraph has sorted them out

IPO Editor

• Only one IPO block shown at a time.
  • Users would like to view multiple in order to better see what they are doing, and also do simultaneous edits.
• Current context stuff - very ugly handling. Sometimes works wrong.

IPO's and Animating

• There are problems related to when IPO results are flushed onto objects/poses, thus clearing the pose.
  • Currently solved with DO_UNLOCK/DO_LOCK type of flags which must be set to disable this from happening.
  • There's also a hack (for armatures only) which tags a bone as having unkeyframed changes. This tag only gets cleared on frame change.
• Due to the hardcoded nature of the way properties are exposed for animating, the way to insert keyframes is also hardcoded.
  • Users cannot define some new groupings of properties to keyframe together for more efficient work
  • This leads to less productivity, from having to remove excess keyframed stuff, and also having to use several different groups to keyframe all the necessary properties at a time.
• Bitflags are exposed in a very nasty way
  • While it is technically easier to just give the user a direct dump of data from the variable a bunch of bitflags are stored on, it's very confusing.
  • Direct dumping of these is not intuitive for users to use (i.e. Layer for Objects, or Mode for Materials)
  • Furthermore, some of these are not totally reliable (in a test I did a while ago, the "Mode" channel for Materials was downright unpredictable/unreliable in what it did. It restored incorrect settings too I think)

Wierd Aspects

• Time IpoCurves are wacko. They are quite confusing, particularly when they appear in the same block that they affect.
• ShapeKeys stuff in IPO editor. Strange, and also very confusing stuff.
  • What's up with RVK's being added at different starting heights (as if they were absolute ones)
  • Why the limit of time = 100 = stop animating???

Timing System

• This is not really related that much with IPO's, but still related.
  • There are many different things that can alter the current time: MBlur, Fields, MapOld->MapNew, Time_Offset per Object/Per-Group, Slow Parenting (and offsets related to that) Time IPO-curves per IPO-block, NLA-Scaling Per NLA-Strip
  • Some of these don't apply onto each other very well (i.e. Time-IPO curves are really nasty, and Time-Offset complicates matters).
  • NLA-Scaling often screws things up

New System Proposal

Overall Goals

• "Everything is animatable"
  • any definitions that need to be made, should only need to be done in one place by the coder
  • system has to be flexible enough to provide for properties made available during execution
  • bitmapped flags/settings must be able to be able to be set independently
• Blocktypes must not be identified using ID's
  • a special set of constant-values will be created specially for this purpose
  • allows for sub-datablock data such as modifiers, to be animated, without resorting to adding "hack" ID codes
• Keyframing code + methods to be more flexible
  • more combinations of keyframing options, and property combinations should be possible
  • user has more control over this (define their own keying sets) for increased efficiency
• Drivers and normal IPO-curves should be separated
  • allows riggers to use drivers and NOT worry about animators breaking them through unlinking/deleting animation stuff and accidentally removing drivers
  • allows animation to be added on top of result from drivers (where necesssary)
  • this way, drivers are clearly separated into "rig" stuff (like constraints) as opposed to "animation" stuff
• Execution order
  • Points to consider:
    • drivers need some values to drive using
    • sometimes, riggers want to be able to apply constraints after IK (not that important, unless someone has a concrete example)
    • animation data is not restricted to pure ipo-stuff... there's also nla-evaluation that can occur
  • "ultimate solution" is to make depsgraph a node-system like network (Maya "Hyper-Graph" anyone?), where there is one-way flow (allow direction switchers based on custom values???) between nodes
    • first-pass (i.e. 1st-node-tree traversal), tags which nodes need to be updated/executed due to changes in their parents
    • second-pass (i.e. 2nd-node-tree traversal), only nodes which are tagged are executed (as executing nodes takes time)
    • this way, we could get multi-threaded action into the system (makes things harder to debug though)
  • "simpler solution" is to impose a few restrictions on what drivers can/can't do
    • all non-muted animation data get evaluated first -> drivers are then evaluated (looking at the the results of the animation data only) -> animation data is then placed back on top of drivers (nla may need recalc) -> constraints done on top -> ik (if applicable)
    • this is less elegant, as it requires a double-calculation in many places, and also restricts what the user can do
• Time control in general should be limited to a "macro" level instead of the "mixed" levels we have now
  • If an ipo-block has a Time curve, it MUST NOT affect the timing of the block it appears in. This is because it gets hard to visualise what the actual time a keyframe will occur at.
  • Ipo-blocks should only have Time curves if: a) it is an ipo-block for a nla-strip, in which case the Time curve is used to control the time in the action being used; or b) used as a reference, to control something else...
  • Globally, we could have a single Scene "Time" control curve, which will replace (not act with) the MapOld->MapNew stuff.
• Animation Editors should be able to display/edit data from multiple sources, not just a "active" source
  • Only what's shown can get edited
  • Filters/modes could be used to control what gets shown
  • For Action/IPO editors, there will need to be some changes to make sure that they can cope with not just editing an "active" block's data - and also able to move things in/out of these blocks (as logical).

"Everything Is Animatable"

• For everything to be animatable, "Everything must be Keyframable".
• The bKeyableType system is designed to cater for this.
  • bKeyableTypes are structs which contain information about the name of the property, what type of data it is, limits for its values, and how to read-from/write-to this property.
  • A script (sdna2kt.py) automagically generates a *.c file (keyabletypes.c) containing arrays (one array per blocktype) of definitions of these. It does so by parsing the DNA_*_types.h files, and extracting special "tags" hidden in the comments. These tags only need to contain enough info for generating a set of bKeyableTypes, with other settings being created from default settings. Only tagged variables (they must not pointers) can get animated.
• As can be seen, this is not a totally automated process. However, if all coders tag any new variables they add (thus helping to document them in the process), we can get most things animatable. Things such as pointers, etc. which are harder to resolve using standard ipo-curves are currently not able to be animated.

Experimental Ideas:

• Each animated channel explicitly targets some variable in a datablock, and allow users to keyframe/store channels from different blocktypes in a single place