Recently @sergey found that hard-coding evaluation of certain very
common driver expressions without calling the Python interpreter
produces a 30-40% performance improvement. Since hard-coding is
obviously not suitable for production, I implemented a proper
parser and interpreter for simple arithmetic expressions in C.
The evaluator supports +, -, *, /, (), ==, !=, <, <=, >, >=,
and, or, not, ternary if; driver variables, frame, pi, True, False,
and a subset of standard math functions that seem most useful.
Booleans are represented as numbers, since within the supported
operation set it seems to be impossible to distinguish True/False
from 1.0/0.0. Boolean operations properly implement lazy evaluation
with jumps, and comparisons support chaining like 'a < b < c...'.
Expressions are parsed into a very simple stack machine program
that can then be safely evaluated in multiple threads.
Reviewers: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D3698
Rebuilding depsgraph is not enough, with COW we also need to ensure COW
copies get updated accordingly.
Had to tweak the generic update system here, since it was always passed
a NULL pointer for the callback arg, this should not change existing
behavior (besides crash fixing ;) )...
Limit to a restricted set of built-ins, as well as the math module.
Also restrict of op-codes, disallowing imports and attribute access.
This allows most math expressions to run
without any performance cost once the initial check is done.
See: D1862 for details.
The copy/paste driver variables buttons currently only work when used in the
Graph Editor as they rely on being able to have the "active F-Curve" context
info that's only present in the Graph Editor (in Drivers Editor mode).
Instead of having them constantly greyed out in the popover, it's easier
to just hide them for now. Besides, this is probably more of an "advanced"
feature that we don't need to expose in the simple UI.
This fixes the problem where the "Show in Drivers Editor" button would
not actually select and highlight the driver under the mouse.
(TODO: The channels still aren't getting selected properly in the
channels list, but at least the properties show correctly)
Otherwise, it's not clear where things are coming from.
FIXME: The icons for datablocks may not always be correct. It uses the
innermost struct's icon instead of the datablock's icon - e.g. Bone
vs Object/Armature. But, that may make more sense for users?
The idea is that we may be able to just take this code and put it into a
new popover panel that gets displayed when called from the UI. This should
at least work well for a first pass test of what we want this UI to look like.
In theory, this should mean that we can get rid of the "Update Dependencies"
button. In practice, there may still be cases where it's still needed
(as somehow, it did end up being needed in the past, even though the RNA
calls should in theory be doing everything needed already).
There are multiple other ways to do it. Leaving this here just made it
easy (and dangerous) to accidentally remove the driver, and was causing
other problems with other layouts.
* Remove "Show Debug Info" option. Everyone has it turned on all the time,
since it's just useful to have
* Make the "Remove Driver" button less prominent. It doesn't happen that much,
so it shouldn't take up as much room
* Make "expressions" textbox wider (i.e. taking up the whole column width)
by separating the label and textbox on separate lines.
* Rename "Add Variable" button to make it clearer to users what "variables"
may be (i.e. they serve as a way to specify Inputs, just like adding a
"Source Data" node in a nodetree)
* Regroup buttons
To bring the UI more in line with the proposed design in T54653 for the "Add Drivers"
popup panel (NOTE: this is separate from the "Drivers Editor", in previous commit!),
this commit adds a new panel - "Driven Property" to the Drivers Editor UI.
This basically duplicates the "Active F-Curve" panel (with less options)
to make it easier to see at a glance which property the Drivers Editor is
showing you.
The legacy algorithm only considers two adjacent points when computing
the bezier handles, which cannot produce satisfactory results. Animators
are often forced to manually adjust all curves.
The new approach instead solves a system of equations to trace a cubic spline
with continuous second derivative through the whole segment of auto points,
delimited at ends by keyframes with handles set by other requirements.
This algorithm also adjusts Vector handles that face ordinary bezier keyframes
to achieve zero acceleration at the Vector keyframe, instead of simply pointing
it at the adjacent point.
Original idea and implementation by Benoit Bolsee <benoit.bolsee@online.be>;
code mostly rewritten to improve code clarity and extensibility.
Reviewers: aligorith
Differential Revision: https://developer.blender.org/D2884
Now all consistent and using term "properties region" instead of "properties panel". Ideally we had a more generic operator for all those.
Fixes T49006.
Drivers can use this to refer to the data which the driver is applied to,
useful for objects, bones, to avoid having to create a variable pointing to its self.
This commit aims to streamline the driver variables layout a bit
* Each variable type now has an icon. (The loc diff and rot diff ones are placeholders,
which could deserve something better/dedicated if we continue to use this)
* Instead of taking up an entire row, the variable type dropdown now only shows
an icon, and is located before the variable name field.
Feedback wanted: Is this more/less confusing than it was?
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!
This brings the UI here more in line with the Constraints and Modifiers UI's.
TODO:
* The tooltips/descriptions on the operators now need fixing, as we can no longer
use custom tooltips when defining these buttons.
* The operators need to be fixed to only operate on the active data
This change means that when going from having no FCurves active to having
an active FCurve, the properties panels will not get stuck with only showing
the "View" tab, which is not that useful a lot of the time.
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 working is the Graph Editor it can be very important to be able to work with fractions
(sub integers), especially when working with Drivers. Currently the "Cursor Y" is hooked up
to "cursor_position_y" which allows fractions but "Cursor X" is directly hooked up to
"frame_current" which is an integer.
This commit adds initial support for this feature.
* When in Drivers mode, the x-part of the cursor is mapped to a new "cursor_position_x"
value which can have fractional values. Animation mode however remains mapped to frame_current
* This commit only adds the UI/property/drawing tweaks needed to support this.
Many operators still need to be modified to consider this value instead of the
current frame, for this to be more useful.
- Add blentranslation `BLT_*` module.
- moved & split `BLF_translation.h` into (`BLT_translation.h`, `BLT_lang.h`).
- moved `BLF_*_unifont` functions from `blf_translation.c` to new source file `blf_font_i18n.c`.
