The issue here is that in the new dependency graph drivers are
individual nodes which depends on what they are driving. This
means that changes to RNA path or property index should ensure
those nodes are updated. Easiest way to do so is to tag relations
for update.
There were at least three copies of those:
- OB_RECALC* family of flags, which are rudiment of an old
dependency graph system.
- PSYS_RECALC* which were used by old dependency graph system
as a separate set since the graph itself did not handle
particle systems.
- DEG_TAG_* which was used to tag IDs.
Now there is a single set, which defines what can be tagged
and queried for an update. It also has some aggregate flags
to make queries simpler.
Lets once and for all solve the madness of those flags, stick
to a single set, which will not overlap with anything or require
any extra conversion.
Technically, shouldn't be measurable user difference, but some
of the agregate flags for few dependency graph components did
change.
Fixes T58632: Particle don't update rotation settings
* Text editor word wrap, line numbers & syntax toggles now use consistent icons
that don’t change when you enable or disable them.
* Replaced icon toggle buttons in the snapping popover with normal checkboxes
and descriptive text labels. This makes it clearer which item is the main
radio button, is more consistent with other popovers, and allows us to use
more descriptive text.
* Added correct icons for grease pencil add menu.
* Added bespoke icons for grease pencil modifiers.
* Added icon for particle instance modifier.
* Added icon for fake user on & off states.
* Added correct icons for enabling/disabling modifiers in the dopesheet &
f-curve editor.
* Made it so the restrict viewport & restrict render toggles for modifier
update correctly when enabled or disabled, by flipping the order in the
icon sheet. This also required changing the outliner to match.
* Removed the few old remaining icons in the old style and made sure to replace
the last places where they were used.
* Updated many icons to be clearer & more consistent.
* Used correct icons for Tracking.
* Flip Copy/Paste icons so they are correct.
* Add correct icon for softbody modifier.
* Replace speaker icons for enabling F-Curves with checkboxes.
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
We are already running out of available flags in main, generic int, and
everytime I work on static override I find new special cases that will
need new specific propflag, so...
* 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
You need the whole chain of pointers... This was breaking static
overrides of any rig basically.
Note that this kills performances again (adding several hundreds of
thousands more stuff on a blendrig...), need a better way to handle RNA
override walking.
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
Cyclic extrapolation is implemented as an f-curve modifier, so this
technically violates abstraction separation and is something of a hack.
However without such behavior achieving smooth looping with cyclic
extrapolation is extremely cumbersome.
The new behavior is applied when the first modifier is Cyclic
extrapolation in Repeat or Repeat with Offset mode without
using influence, repeat count or range restrictions.
This change in behavior means that curve handles have to be updated
when the modifier is added, removed or its options change. Due to the
way code is structured, it seems it requires a helper link to the
containing curve from the modifier object.
Reviewers: aligorith
Differential Revision: https://developer.blender.org/D2783
The problem here was that the "frame_start" and "frame_end" RNA properties of
the Stepped FModifier were shadowing/overriding "frame_start" and "frame_end"
properties of the base FModifier. As a result, when the range() callback
for the In/Out parameters (defined as part of the base FModifier) checked
it's start/end properties, they were always still zero, meaning that the
acceptable range for the In/Out parameters was 0 -> 0 = 0.
Note:
If you've got old files with this problem, you'll need to manually click on
the frame_start/end properties to flush out the old values. It's probably
not worth the effort of applying a version patch for this (given that this
modifier is not one of the most often used ones AFAIK).
This gives us 9 flags available again for properties (we had none anymore),
and also makes things slightly cleaner.
To simplify (and make more clear the differences between mere properties
and function parameters), also added RNA_def_parameter_flags function (and
its clear counterpart), to be used instead of RNA_def_property_flag for
function parameters.
This patch is also a big cleanup (some RNA function definitions were
still using 'prop' PropertyRNA pointer, etc.).
And yes, am aware this will be annoying for all branches, but we really need
to get new flags available for properties (will need at least one for override, etc.).
Reviewers: sergey, Severin
Subscribers: dfelinto, brecht
Differential Revision: https://developer.blender.org/D2400
This commit allows RNA properties to return additional info on their editable state which may then be displayed in tooltips. To show how it works, it also adds some info for the editable check of proxies. For generally un-editable properties or properties of a linked data-block, RNA returns default strings.
| {F362785} | {F362786} | {F362787} |
Reviewed by brecht, thanks!
Differential Revision: https://developer.blender.org/D2243
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.
Currently "long keyframes" are only useful for indicating where stationary
holds occur. If however you try to create a "moving hold" (where the values
are slightly different, but in terms of overall effect, it's still a hold)
then it could get tricky to keep track of where these occur.
Now it's possible to tag such keyframes (using the keyframe types - RKEY)
as being part of a moving hold. These will not only be drawn differently
from normal keyframes, but they will also result in a "long keyframe"
being drawn between each pair of them, just like if they had been completely
stationary instead.
Currently the theming/styling of these is a bit rough. They reuse the existing
theme colours for long keyframes.
The "W" channel will get a yellowish colour (i.e. a blend between the X/R and
Y/G axis colours), while the XYZ will behave as they do for other transforms.
* Knock out "Python" FModifier entry - It really hasn't been coded yet!
* Add icon for "Match Indices" driver eyedropper mode. It should help provide
a bit more of a hint of what it does, but it also doesn't look quite as nice now.
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!
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
The new "default keyframe type" dropdown on the timeline header
(and also the "Keyframe Type" operator/properties in other places)
now has procedurally generated icons which reflect what that keyframe
type will look like when rendered in the Dope Sheet.
This was achieved using the ancient "VICON" (vector icon) stuff
that's lurking around in the dark parts of UI code. From memory,
the only other things that use (or used to use) this stuff included
some of the triangle icons for some dropdown buttons, or something
like that.
Notes:
* Theme colour changes are reflected immediately by these icons.
This is possible because they are all drawn procedurally
* These icons scale with the DPI setting. I manually guessed the size of
these icons. They can be adjusted further if needed.
* I've documented the steps for adding voodoo icons like this on the wiki
(http://wiki.blender.org/index.php/Dev:2.7/Source/Checklists/Vector_Icon)
* It's true that the rendering of these keyframes doesn't quite fit the rest
of the icons in the UI. However, since we're just leveraging the standard
keyframe drawing methods (to avoid discreptancies between the two), we'll
leave it as such for now. Maybe later we can consider blending in a bit of
the glossy keyframe icons in the Icon Sheet?
