The default was changed with an initial implementation of the feature.
With the feedback from animators, having a behavior which affects curves
outside of a changing range is not convenient for professional animators
working on high quality character animation. On the other hand, automatic
smoothing is better for casual animation of object motion.
This change adds an ability to change the default via User Preferences.
Differential Revision: https://developer.blender.org/D5875
Having a constant FCurve doesn't make sense for drivers; either linear
or Bezier should be used. Since the code is already creating a Bezier
curve, I just added the flag to not look at the user preferences in this
case.
Reviewed by: angavrilov
Differential Revision: https://developer.blender.org/D5921
The 'add mode' was a `short` between -1 and 2 inclusive, and magic numbers
sprinkled throughout the code. It's now an enum with descriptive names.
No functional changes.
The old layout of `PointerRNA` was confusing for historic reasons:
```
typedef struct PointerRNA {
struct {
void *data;
} id;
struct StructRNA *type;
void *data;
} PointerRNA;
```
This patch updates it to:
```
typedef struct PointerRNA {
struct ID *owner_id;
struct StructRNA *type;
void *data;
} PointerRNA;
```
Throughout the code base `id.data` was replaced with `owner_id`.
Furthermore, many explicit pointer type casts were added which
were implicit before. Some type casts to `ID *` were removed.
Reviewers: brecht, campbellbarton
Differential Revision: https://developer.blender.org/D5558
This reverts commits 54fd8176d7, 4c5becb6b1 and 8f578150e.
Those kind of commits must be reviewed and approved by project owners.
That one:
* Broke Collada building by not properly updating all calls to modified
function.
* Broke *whole* ID management by not properly updating library_query.c.
And in general, I am strongly against backward ID pointers, those are
*always* a serious PITA for ID management. Sometimes they cannot be
avoided, but in general other ways to get that kind of info should be
investigated first.
NodeTree structures of materials and some other data blocks are
effectively node group data block objects that are contained inside
the parent block. Thus, direct references to them are only valid
while blender is running, and are lost on save.
Fix Copy As New Driver to create a reference that goes through
the owner data block, by adding a new runtime field to bNodeTree.
It is a very common need to create drivers that set the value of
a property to the value of some other property, but it currently
requires multiple actions: Copy Data Path on the input property,
adding a driver to the output property, selecting the input ID
reference, and pasting the path.
This adds a new Copy As Driver context menu option, which creates
a complete driver in the clipboard that reads the current property,
so all that remains is to paste it to the output property. It is
also possible to paste just the new driver variable into an existing
driver to combine multiple inputs.
Reviewers: brecht, billreynish
Differential Revision: https://developer.blender.org/D5382
Was missing copy-on-write tag since lamp itself has no geometry or
transform.
Now tagging for animation, and taking care of special case in the
dependency graph.
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
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.
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
This won't ever be used for this operator, as the "edit" operator should
only ever be used for dealign with a single driver - the one under the
cursor.
Previously, newly created drivers were set to "Scripted Expression"
mode and had their 'expression' field set to the pre-driver value of the
property, so that adding a driver didn't cause the property to immediately
lose its old value (and potentially causing havok in the scene).
However, this had the unintended consequence of making the driver setup
workflow more cumbersome, as you first had to replace that value with
the name of the driver variable before your driver would work.
This commit works around this issue by trying to combine the best of both
worlds (quite literally): Now, the driver expression for drivers created
using Ctrl-D will be "var + <old value>".
Thus, in the simplest case, the driver will do something as soon as you fill
out the driver variable settings (e.g. just filling out the Target Object field
will do it), meaning you get your drivers working faster. Of course, it may now
be necessary to edit out the old-value, and/or it might be a bit more confusing
what/why it's there for newbies. However, the improved ease of setup, and/or
a more tangible example of how an expression may be constructed outweigh the
downsides IMO.
This commit implements a new behaviour for the "Add Driver" functionality
(invoked from the RMB menu on a property, or by pressing Ctrl-D).
Instead of spawning a context menu asking you to pick the way
you want to create a driver, it will now just create a driver on the
property under the mouse and then show the "Edit Drivers" popover so
that you can immediately start editing the properties of this driver.
This way, the whole process is more visual and feels less blocking /
constrained, with less upfront decisions needed immediately.
Notes:
* The new behaviour is equivalent to choosing the "Manually Create (Single)"
and then doing a "Edit Driver" on the property
* Renamed the old "ANIM_OT_driver_button_add" operator to
"ANIM_OT_driver_button_add_menu". It will probably go away
in the near future, but it's better to keep it around for a
while longer still until the new workflow settles down.
This commit adds a new menu entry - "Edit Driver" - the RMB menu that
will show a popover panel displaying the settings for the driver you
activated the menu item on. This shows the popover panel defined in
yesterday's commit (GRAPH_PT_drivers_popover).
It is possible to edit the driver settings from this panel now.
However, do be warned that the functionality presented is highly
WIP still. There are some unresolved issues, such as:
- The popover disappears too easily on any mouse movements/clicks
on anything, making the panel less useful right now than it should.
- The layout still needs refining. Currently the layout that's there
is a bit of a placeholder until we can play around with it a bit
more to see/feel what feels good/right or what is too much.
- The "Open Drivers Editor" on the bottom of the panel doesn't work.
There are some tricky context tricky things that need to happen here
to make that case work, since the operator button won't have the necessary
context info.
* 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
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
