This was a feature request from a few years back (IIRC from ZanQdo?) to make it
easier to reuse one set of driver variables across several different drivers.
Dev Notes:
* Finally it's done! All that trouble for two little buttons.
* Grr... cmake... grrr!
Support for driver variables that don't resolve to numbers, eg:
objects, bones, curves... etc.
Without this, Python expressions to access this data needed to use an absolute path from `bpy.data`,
however this is inconvenient, breaks easily (based on naming) and wouldn't set the dependencies correctly.
Now, when trying to insert a keyframe on a driven property (using IKEY, or with
autokeying enabled), the keyframes will get created on the Driver's F-Curve
(instead of creating a new FCurve that goes into the active action, but will never
do anything). Furthermore, the x-value of the new keyframe will be the current
result of the driver expression.
Why/Motivations:
This way, it becomes easier to create corrective drivers, as you can position all
the targets the driver depends on, then adjust the driver value until it does what
you need, and then you keyframe that value to bake it into the Driver F-Curve
(in effect, "training" the computer how to behave in that case).
Usage Notes:
* In practice, that particular workflow is still quite clunky to achieve, due to some
quirks of how the driver system and the UI widgets interact. Specifically, you'll
need to disable/mute the driver before trying to edit the setting (to prevent the
driver from immediately resetting the value - before even autokey fires!). However,
if you're using the Graph Editor to preview/monitor/manage the keying process, you'll
then want to re-enable the driver before changing the targets, so that you can see
how much of a change you'll want to be applying!
* The warning about editing driver values may need to be disabled or selectively
knocked out. I had it disabled while testing this functionality, but it's actually
harmless in its current state (if just a bit annoying).
When attempting to change a driver variable name to an "invalid" name,
an indicator will now be shown beside the offending variable name.
Clicking on this icon will show a popup which provides more information
about why the variable name cannot be used.
Reasons that it knows about are:
1) Starts with number
2) Has a dot
3) Has a space
4) Starts with or contains a special character
5) Starts with an underscore (Python does allow this, but it's bad practice,
and makes checking security of drivers harder)
6) Is a reserved Python keyword
When the active action is a NLA strip, the keyframe indicator colors for buttons
and the 3D view indicator (i.e. the current frame indicator changes color) didn't
work correctly. This was because they were still checking for keyframes in
"global" time space, whereas they needed to be applying NLA corrections to
"look inside" the remapped action.
This is only a (hacky) partial fix, actually, since `RNA_property_animated()` will still
not work in those cases... Better that than nothing, though.
Thanks to Campbell for review.
Since this is now pretty much the de-facto "minimum distance between keyframes",
we might as well expose this in this header so that other places which need similar
thresholds can perform similar checks (needed for my next commit)
Summary:
Crash was happening because of fcurve modifier stack
used modifier's DNA to store temporary data.
Now made it so storage for such a thing is being
allocated locally per object update so multiple objects
which shares the same animation wouldn't run into
threading conflict anymore.
This storage might be a part of EvaluationContext,
but that'd mean passing this context all over in
object_where_is which will clutter API for now without
actual benefit for this.
Optimization notes: storage is only being allocated
if there're Cycles modifier in the stack, so there're
no extra allocations happening in all other cases.
To make code a bit less cluttered with this storage
passing all over the place added extra callbacks to
the FModifier storage which runs evaluation with the
given storage.
Reviewers: brecht, campbellbarton, aligorith
CC: plasmasolutions
Differential Revision: https://developer.blender.org/D147
- when an fcurve had no selected keyframes, a default fallback value was used which caused view-selected to include frame 1, even when no selected frames were there.
- the vertical axis was always reset, ideally we would center vertically too but the way this operator currently works we only know about the frame range,
now don't change the vertical scroll when viewing selected since it would always jump to the top of the screen (view-all still acts this way).
than one curve is displayed
The range calculation used to use a fixed 0-1 range whenever it couldn't find
any values for a particular F-Curve. However, this was then taken by the
aggregation calculation to be used as just another value, leading to problems if
only vertices of a very high-value curve are selected to be included.
Modified the range calculation to ensure that suitable vertices were found
before trying to take the range values returned.
F-Curves
It is possible to get the old behaviour (handles excluded) by bringing up the
Operator Properties (F6) while in the Graph Editor (this doesn't work elsewhere
due to the context requirements of this stuff).
Implemented basic audio animation.
* AnimatableProperty: Propper cache writing and spline interpolation for reading (the solution for stair steps in audio animation)
* Animatable properties so far are: volume, pitch, panning
* Users note: Changing the pitch of a sound results in wrong seeking, due to the resulting playback length difference.
* Users note: Panning only works for mono sources, values are in the range [-2..2], this basically controls the angle of the sound, 0 is front, -1 left, 1 right and 2 and -2 are back. Typical stereo panning only supports [-1..1].
* Disabled animation of audio related ffmpeg output parameters.
* Scene Audio Panel: 3D Listener settings also for Renderer, new Volume property (animatable!), Update/Bake buttons for animation problems, moved sampling rate and channel count here
Not really a "bug", but it was on my todo anyways. Based on patch
[#26508] by Campbell, with a few modifications including extending
this to the Action/DopeSheet editor too.
* Keyframing operators now use the reports system for displaying all its error messages.
- The benefit of this is that users no longer need to check the console for error messages if keyframing fails.
- Unfortunately, reports are not currently viewable in any space/view in Blender, so...
* Added a temporary operator (UI_OT_reports_to_textblock), which can be accessed in the UI from the button which appears in place of the icon when more than one report exists. This dumps the current list of reports to a textblock "Recent Reports", from which they can be viewed.
This isn't really nice, but at least we now have a way to view these again, which makes debugging some things a pain.
* Bugfix #24606 - when trying to add keyframes to F-Curves with F-Modifiers already which alter the curve significantly enough that the keyframes will have no effect, there are now warnings which aim to alleviate any confusion.
- some remove() functions took an int argument rather then the item to remove.
- disallow None argument.
- raise an error if the item isnt in the collection.
* Copy/Paste operators for F-Modifiers
Available in Graph and NLA Editors. Use the Copy/Paste buttons beside the 'Add Modifier' buttons.
Copy copies all the modifiers of the ACTIVE F-Curve or Strip depending on the editor.
Paste pastes modifiers from the buffer to all the selected F-Curves or Strips, adding the new modifiers to the ends of each list.
* 'Stepped Interpolation' F-Modifier
This modifier holds each interpolated value from the F-Curve for several frames without changing the timing.
This allows to preview motions 'on-twos' for example without altering the timing, or having to go through setting heaps of keyframes. In this case, Andy wanted to use this for CG <-> StopMo.
Now the compositing node tree will update on frame change if any of the
nodes are animated.
This doesn't work for playback (i.e. alt a), that's better off waiting until we
have some kind of frame caching system.
Highlights:
* Support for Multi-Target Variables
This was the main reason for this recode. Previously, variables could only be used to give some RNA property used as an input source to the driver a name. However, this meant that effects such as Rotational Difference couldn't be used in conjunction with other effects and/or settings to achieve the powerful results. Now, a variable can take several input targets, perform some interesting operations on them, and spit out a representative value based on that.
* New Variable Types
With the introduction of multi-target variables, there are now 3 types of variable that can be used: single property (i.e. the only type previously), Rotational Difference (angle between two bones), and Distance (distance between two objects or bones).
* New Driver Types
In addition to the existing 'Average', 'Sum', and 'Expression' types, there is now the additional options of 'Minimum' and 'Maximum'. These take the smallest/largest value that one of the variables evaluates to.
* Fix for Driver F-Curve colouring bug
Newly added drivers did not get automatically coloured in the Graph Editor properly. Was caused by inappropriate notifiers being used.
Notes:
* This commit breaks existing 2.5 files with drivers (in other words, they are lost forever).
* Rigify has been corrected to work with the new system. The PyAPI for accessing targets used for the variables could still be made nicer (using subclassing to directly access?), but that is left for later.
* Version patching for 2.49 files still needs to be put back in place.
* Added function for F-Curves to find the F-Curves in a given list which affect some named data, such as bones, nodes, or sequence strips.
* Added a BezTriple offsetting callback to be used with the F-Curve+Keyframe loopers in use for many of the keyframe editing tools.
- renamed .add() to .new() for rna collection functions since they dont add an existing item.
- remove 'name' as an argument from the new driver target function, better to keep the api minimal and let scripters use the data api for editing values after.
- added some api functions to keep rna api from becoming a mess.
This commit restores the 'Relax Pose' tool, and also introduces two others: 'Push Pose' and 'Pose Breakdowner'.
Be aware that this commit is just the initial starting point, with some parts yet to be done.
A short description of these tools follows:
* Relax Pose (Alt-E) - makes the current pose more like the poses on either side of it
* Push Pose (Ctrl-E) - exaggerates the current pose
* Breakdowner (Shift-E)[not working yet] - when this works, it will allow for interactive selection of a good in-between pose to act as a breakdown.
Todo's:
* Connect up the 'percentage' slider in the operator settings to allow these effects to be dialed in/out, exaggerating/relaxing/moveing-between-keyframes by varying degrees until the desired effect is reached.
* Allow these effects to be interactively dialed in/out. The idea is to use the mouse to interactively set the percentage slider value initially, then use the percentage slider to tweak later.
* Figure out why breakdown breaks down
* Text labels on NLA-Strips should now draw properly for most short-strips now. Previously, the padding on the text was a bit too extreme, so for very short strips (less than 4 frames or so), the text was often pushed down into the bottom-right corner of view.
* Optimised the keyframe-highlighting code for buttons a bit. Replaced the custom linear-search with the binary-search used when inserting keyframes (and for the 3d-view keyframe-indicator). There should be some theoretical improvements due to this at least...
* Made NLA Editing functions more aware of transitions.
- A transition can only be added between a pair of action-clips. Previous, two transitions could be added next to each other, which has undefined behaviour
- Deleting a strip with transition(s) on either side will remove the transitions too. Feedback welcome on this
- The 'type' setting for NLA-Strips is no longer editable. This was dangerous as it could result in transitions with undefined behaviour (though nothing would happen).
* Menus for adding F-Modifiers now only show relevant modifiers (i.e. 'Invalid' is not included in the list, and 'Cycles' doesn't need to be shown for NLA since we've got repeat)
* Function Generator and Noise F-Modifiers now have complete GUI's. A few settings were missed during the porting process.
* F-Modifier buttons now have their source-ID's included in the RNA Pointers used. This didn't get them animateable directly, but is a step closer.
* F-Modifier API is now in its own file in blenkernel
* Renamed and refactored these so that they're no dependent on F-Curves, since all they really used was the fcu->modifiers list
* Added missing license blocks to a few files
When an F-Curve doesn't contain any keyframes anymore but it still exists, the F-Curve's value is not recalculated and flushed anymore if the F-Curve's value will not change. That is, if the F-Curve doesn't have any other data, i.e. drivers or generator-modifiers, which would still change its value, it wouldn't be recalculated to have a value of zero.
This solves the problem of deleting all scale keyframes, whereby objects/bones would appear to 'vanish'
== Transitions ==
Transition strips are now able to be created + evaluated. Transitions allow for interpolation between the endpoints of two adjacent strips in the same track (i.e. two strips which occur in the same track one after the other, but with a gap between them).
- The current behaviour when only one endpoint affects some setting is non-optimal, since it appears somewhat inconsistently extend/replace values...
- Transform code needs a few fixes still to deal with these
== Strip Adding Operators ==
* New strips referencing Actions can be added using the Shift-A hotkey while in the strips-area. You must have a track selected first though.
The new strip will get added, starting from the current frame, in the selected track(s) only if there is enough space to do so. Otherwise, the new strip gets added at the top of the stack in a new track.
* New transition strips can be added with the Shift-T hotkey while in the strips area. You must have two adjacent strips selected for this to work.
== New Backend Methods ==
* Recoded the strip/track adding API to be more flexible
* Added a new method for testing whether F-Curve has any modifiers of with certain attributes. Will be used in a later bugfix...
== Bugfixes ==
- Fixed bug with strip-blending which caused the blending modes to be useless.
- NLA buttons now use proper poll callbacks instead of defining checks
- Commented out missing operator in menus, silencing warnings in console
- Removed obsolete/incorrect comments
* Refactored F-Curve Modifier stack evaluation into functions which can be reused for F-Curve Modifiers on NLA-Strips
* Started setting up temporary accumulation buffer system for use when evaluating strips
* Loading files saved with 2.5 works again now without crashing. Was crashing when trying to load Grease Pencil data (even though there was none)
* Fixed some msvc compiler warnings in own code
Time-Modifying F-Curve Modifiers now get special callbacks to allow them to specify what frame they need to be evaluated on, instead of forcing a re-evaluation of the preceeding curve + modifier-stack. This should be more robust than the old way in general.
It still remains to be seen if some tweaks to this are still needed, as the full consequences of the propogation of modified time-spaces have yet to be fully explored.
For now though, evaluation works by finding the last modifier on the stack which modifies time, and asks it what time it modifies the given time to. This modified time is used to evaluate the F-Curve data only. The modifier stack gets evaluated using the original time instead.
Now it is possible to write a Python Expression using the variable names for driver targets (see mockup from initial commit) to substitute the appropriate values into the expression.
In the __global__ namespace for PyDriver evaluation, the following modules are available:
* __builtins__ - i.e. the builtin Python functions
* bpy - new Python API
* math or m - math module
For example:
Consider a driver with three targets, named: A, B, C
Now, you could write an expression like:
C if A < 5 else B
or even:
2*C if A < 5 or A > 20 else m.PI*B
Of course, you don't have to have three targets, the above was just an example.
TODO:
* Bring back way to load pydrivers.py
* Blender.Noise equivalent would be nice to have
P.S. I hope I haven't made any terrible Python API coding errors here (i.e. mem leaks, etc.)
Drivers now support multiple targets which act as 'variables'. The targets have a short 'name' (see later), and reference some property (in much the same way as F-Curves do, using RNA-Paths) which acts as the 'value'.
These named variables can then be used in a Python Expression which relates them to each other for more fine-grained control over the result of the driver. By using only the names of these variables in the expressions, we are able to define expressions/relationships in a much more readable way, as data access is separated from data use. This makes the underlying relationships easier to understand.
By default, if no Python Expression is given, the variables are simply averaged together, so old files won't break. :)
For example, check the following diagram (thanks Cessen/Nathan V from Peach team):
http://download.blender.org/ftp/incoming/250_drivers_mockup_cessen.png
TODO List:
* Depsgraph building for new driver relationships doesn't work yet. This needs to be recoded again, but this new system makes this much easier, since the targets are clearly defined (i.e. no need to parse py expressions to get list of objects)
* Graph Editor interface for editing these needs to be rewritten
* Python function for evaluating these expressions is needed (Campbell?)
- I key over a button inserts a keyframe.
- Alt+I removes a keyframe.
- With right mouse button a menu with these options pops up.
- Buttons are colored green if the property is animated, yellow
if it is on a keyframe. I followed the colors from the UI
mockups, but the flicker on keyframes seems too distracting in
practice?
- This only works for properties on the ID itself at the moment,
path callbacks need to be filled in for all structs but mesh
still.
- It doesn't work when you're over a related label, that needs to
be made to work.
- I made it insert keyframes outside of any keyingset. Not sure
how this is supposed to integrate?
* Currently, this only works for the 'Expanded polynomial' mode, but this will be expanded to include the other modes too. Now you can modify the values and interactively see the graph in the view change.
* Disabled the backdrops (modifier 'panels') temporarily, as ROUNDBOX UI elements currently swallow all events, which is not good.
Note: the code here still uses the old-style UI definition code since the new stuff is still under heavy construction.
- Completed cleaning up the drawing code so that F-Curves with modifiers now get drawn to reflect this.
- Added a temporary operator to add modifiers (hotkey Ctrl-Shift-M)
This operator can be activated using the 'Alt-C' hotkey for now, and operates on selected + editable F-Curves. This is currently still highly experimental, and does crash
I've implemented this as a way to test out the FPoints/samples code, which will be used to provide better support of the dense F-Curves which result from importing Mocap/BVH data. These should use considerably less memory + have a few additional benefits over keyframes when they're working in a stable fashion.
Only object layers have been done for now. The implementation of this should provide a good indicator for how this should be done. Unforunately, the code for animating layer visibility is not that straightforward, since scene->base->layer (not set) settings need to be synchronised with the object->layer (set by Animato) settings.
This commit brings back the drawing code for the 'Graph Editor'. I've decided to call it this, as currently it can show either F-Curves for Animation stored in Actions, or F-Curves for Drivers.
Currently, it shows all curves, since some of the necessary filtering code (i.e. for limiting curve visibility) hasn't been put in place yet. At least this serves as good proof that we can have F-Curves from multiple sources at least.
It should be noted that the code still has to be modified to work with some of the new Animato features, such as F-Curve Modifiers (cycles are an example of one of the features that use this). Also, a nicer way to set the colours of the curves needs to be investigated.
Notes:
* Fixed a few bugs in RNA User-Preferences wrapping
* The keyframe drawing uses the new-style drawing for handles from AnimSys2. There's a minor bug that sometimes occurs, where a distorted handle gets drawn at the origin of the grid on the first run. Hints anyone?
* Removed most of the old data from SpaceIpo struct, as the new code uses that. Maybe later, the directories/files at least should get renamed.
* Removed ancient hack for NVidia/TNT drivers. It is probably no longer needed, but could be restored if someone needs it.
* Added back Auto Preview-Range tool (i.e. set preview-range from keyframe extents)
* Restored delete keyframe tool. For now, this doesn't delete empty F-Curves, even though its keyframe-api counterpart still does. I still need to figure out how to do this in the best way.
* Fixed crashes when selecting keyframes in 'object' summary channels
* Removed prototypes for a few unused/depreceated functions...
* Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so.
* Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use...
* Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code).
* File writing code should now only write the new data to files
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
Joshua Leung
Campbell Barton
Bastien Montagne
Sergey Sharybin
Joerg Mueller
Nathan Letwory
Brecht Van Lommel
Matt Ebb
Arystanbek Dyussenov
Joseph Eagar
