* Updating dependencies for drivers now clears the disabled status of the relevant Driver FCurve too
* Changing the type of ID-block used for Driver Targets and Keying Set Paths will now clear the pointer to the ID-block if it is of the wrong type.
* Convert all code to use new functions.
* Branch maintainers may want to skip this commit, and run this
conversion script instead, if they use a lot of math functions
in new code:
http://www.pasteall.org/9052/python
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
Note sure what to do with this one, and personally think
we should avoid using macros for this kind of thing:
V_GROW(edges);
source/blender/editors/mesh/loopcut.c:232: warning: value computed is not used
Example code: http://www.pasteall.org/7332/c.
New API functions: http://www.pasteall.org/7330/c.
Maximum number of dimensions is currently limited to 3, but can be increased arbitrarily if needed.
What this means for ID property access:
* MeshFace.verts - dynamic array, size 3 or 4 depending on MFace.v4
* MeshTextureFace.uv - dynamic, 2-dimensional array, size depends on MFace.v4
* Object.matrix - 2-dimensional array
What this means for functions:
* more intuitive API possibility, for example:
Mesh.add_vertices([(x, y, z), (x, y, z), ...])
Mesh.add_faces([(1, 2, 3), (4, 5, 6), ...])
Python part is not complete yet, e.g. it is possible to:
MeshFace.verts = (1, 2, 3) # even if Mesh.verts is (1, 2, 3, 4) and vice-versa
MeshTextureFace.uv = [(0.0, 0.0)] * 4 # only if a corresponding MFace is a quad
but the following won't work:
MeshTextureFace.uv[3] = (0.0, 0.0) # setting uv[3] modifies MTFace.uv[1][0] instead of MTFace.uv[3]
* Animated ShapeKey F-Curves/Drivers are now visible in the Animation Editors.
* As a result of this, the old 'ShapeKeys' mode (which would display all the shapekey channels, even if they had no keyframes yet) in the DopeSheet, no longer works for now. However, it would have been of no use as no sliders were shown anyway.
* Drivers which depended on the rotation of bones now work again. These now point to the right RNA properties, and get some extra 'time' corrections (for degrees -> radians change).
* 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...
* 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
Started cleaning up FModifiers in preparation for allowing them to be used on NLA Strips.
This commit separates the 'Built-in Function' mode for the Generator modifier out into its own modifier, since it was being quite frequently used (and the RNA wrapping for this used to be quite hackish).
BACKWARDS COMPATABILITY WARNING:
Old files with FModifiers saved (i.e. old 2.5 files, but not any others) will not load correctly as a result of these changes (the wrong modifiers will be shown). I've decided that there are not likely to be many files affected by this yet, but doing this will result in a much nicer modifiers-define list in the long run.
In TweakMode, the keyframes of the Active Action are now shown (and can be edited) in NLA-mapped time, with appropriate corrections applied when editing. This works in the DopeSheet and Graph Editors :)
To do this, got rid of the old wrappers/API-methods, replacing them with new-style ones. A few methods previously (in this branch) used only for evaluation are now used for this purpose too. As the same code is used for editing + evaluation, this should now be much better to work with.
I've only done a few brief tests now, but I think I might've muddled the invert-flags on one or two cases which I'll need to check out tomorrow. So, beware that there may be some weird and critical bugs for the next few days here...
Also, added proper license headers to new NLA files.
TODO:
- testing + bugfixing due to this commit
- show range of keyframes in NLA Editor active-action line
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
For fun, added 'sinc' (i.e. y = sin(pi*x)/(pi*x)) as a type of builtin function usable through the generator modifier. This makes a nice 'jolt' which tapers off.
* 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.
Restored the code to get this working. I haven't tested this to verify it, but it 'should' work...
Also, deleted old gpencil.c file in editors, since it was causing compiling errors.
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.)
The Python API to define Panels and Operators is based on subclassing,
this makes that system more generic, and based on RNA. Hopefully that
will make it easy to make various parts of Blender more extensible.
* The system simply uses RNA properties and functions and marks them
with REGISTER to make them part of the type registration process.
Additionally, the struct must provide a register/unregister callback
to create/free the PanelType or similar.
* From the python side there were some small changes, mainly that
registration now goes trough bpy.types.register instead of
bpy.ui.addPanel.
* Only Panels have been wrapped this way now. Check rna_ui.c to see
how this code works. There's still some rough edges and possibilities
to make it cleaner, though it works without any manual python code.
* Started some docs here:
http://wiki.blender.org/index.php/BlenderDev/Blender2.5/RNATypeRegistration
* Also changed some RNA_property and RNA_struct functions to not
require a PointerRNA anymore, where they were not required (which
is actually the cause of most changed files).
* Added extra parameter to generic unique name finding function BLI_uniquename() for specifying the delimeter between non-unique parts of the name and digits.
* Driver target variables now get unique names by default.
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?)
This new modifier clamps the values of the F-Curve to lie within specified bounds, much like Limit Location/Rotation/Scale constraints do. You can limit by time range(s) and/or value range(s).
* Copying objects with animation data now works correctly. Previously, actions were not getting copied correctly, leading to loss of data in some cases.
* Action and Graph editors now display the name of the Action concerned (for 'Action' folder channels), making it easier to tell which AnimData blocks are sharing the same actions
* Added some code to make relative KeyingSets (converted from absolute ones) work better.
- 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?
When inserting keyframes in the 3D-View (support will be extended to other editors in due course) using the IKEY hotkey, the menu which appears will now consist of 3 parts:
* 'Active Keying Set' - this option allows you to use the user-defined KeyingSet which is active for the current scene (i.e. the one seen in the TimeLine/Outliner headers)
* User defined Keying Sets - a list of all such available KeyingSets is included, and entries can be chosen from there
* Built-In Keying Sets - see later...
To achieve this, several changes needed to be made first:
* Added support for 'relative' in addition to 'absolute' Keying Sets. Relative Keying Sets are Keying Sets which operate on data from the current context (i.e. a 'location' KeyingSet will add location keyframes for selected objects/bones/nodes as opposed to location keyframes for some particular object). The is a tentative 'templates' requirement system here, which still needs to be fully fleshed out.
* Added support for builtin Keying Sets (i.e. 'Location', 'Rotation', 'Scaling', and 'LocRot' as a few initial demonstrations), which replaces the temporary Insert Keyframe operator for the 3D-View (IKEY). These are effectively relative Keying Set definitions which are included in Blender by default and stored in a list separate from user-defined ones. Volunteer help in defining a few more of these for other editors will be welcome soon.
* Removed/replaced much of the crappy temporary Keyframing operator code, though a few tweaks could still be done.
This setting means that instead of blindly replacing the existing values, the generator modifier will instead apply its effects on top of any existing modifiers (and/or curve data).
Thus, it is now possible to apply effects such sin/cos-based oscillations on top of keyframed motion.
* Envelope modifier now works correctly. Previously, the mapping was being done in the wrong order.
* Extra controls for modifiers now only draw when the F-Curve is the active one, so the view will be less cluttered in other cases.
Got the basic envelope modifier code working, including primitive drawing of relevant helper info in the graph view. It doesn't work in a very intuitive way yet, so I will recode it soon.
* Added GUI and fixed bugs in the Cycles Modifier. This replaces the old Cyclic Extrapolation settings, giving more fine-grained control over the results. You can now specify whether the keyframes are repeated before and/or after the range independently, also, the maximum number of cycles on either side can be controlled.
* TODO: it would be nice to have the last value held for cyclic+offset.
* Deleting modifiers now works
* Finished code for Expanded Polynomial and Factorised Polynomial UI's.
* Started UI code for 'Builtin Function' mode. There are still 4 controls to add there to use something other than simple mapping
* Finished/fixed up verification code for these so that values get initialised ok.
* 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.
* Rewrote the Generator modifier to be more efficient and support more options
* A few UI tweaks for this, but the UI for this is still not yet functional though.
- 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.
