Age | Commit message (Collapse) | Author |
|
While it might be handy to have type-less functionality which is
similar to how C++ math is implemented it can not be easily achieved
with just preprocessor in a way which does not have side-effects on
wrong usage.
There macros where often used on a non-trivial expression, and there
was at least one usage where it was causing an actual side effect/bug
on Windows (see change around square_f(sh[index++]) in studiolight.c).
For such cases it is handy to have a function which is guaranteed to
have zero side-effects. The motivation behind actually removing the
macros is that there is already a way to do similar calculation. Also,
not having such macros is a way to guarantee that its usage is not
changed in a way which have side-effects and that it's not used as an
inspiration for cases where it should not be used.
Differential Revision: https://developer.blender.org/D7051
|
|
Objects."
This reverts commit 7728bfd4c45c634ba6b62e149176425ec5779945.
Although this brings back an inconsistency in the behaviour of
constraints on objects and bones, people were relying on the old
behaviour, and the new behaviour broke their files.
It is still desired to remove this inconsistency, but it will happen
more gradually.
|
|
|
|
No functional changes.
|
|
This turns error condition checks into precondition checks, grouping the
non-error functionality together towards the bottom of the function and
error-handling functionality towards the top.
No functional changes.
|
|
No functional changes.
|
|
The dependency graph has to know whether a driver must be re-evaluated
every frame due to a dependency on the current frame number. For python
drivers it was using a heuristic based on searching for certain sub-
strings in the expression, notably including '('.
When the expression is actually evaluated using Python, this can't be
easily improved; however if the Simple Expression evaluator is used,
this check can be done precisely by accessing the parsed data.
Differential Revision: https://developer.blender.org/D6624
|
|
The last handle wasn't corrected, also, there is no reason
to flip the handles while sorting (checking the same handles many times)
move this into it's own loop.
|
|
When introducing "drag-all-selected" support all over Blender, we
figured this wouldn't work well with the Graph Editor
selection/transform behavior.
Hence, William and I worked on the following changes, although we used
this chance to improve the behavior in general too.
For more info see T70634.
* Handles now always move with the key, regardless if they are selected
or not.
* Selecting the key doesn't select the handles anymore, their selection
is separate.
* Multiple keys and handles can now be dragged.
* Dragging a handle moves all selected handles **on the same side**.
* Tweak-dragging any handle can never affect any keyframe location,
only handles.
* G/R/S should behave as before.
* Changing the handle type with a key selected always applies the change
to both handles.
* Box selection with Ctrl+Drag now allows deselecting handles (used to
act on entire triple only).
* Box selection //Include Handles// option now only acts on visible
handles, wasn't the case with Only Selected Keyframes Handles enabled.
* Box selection //Include Handles// is now enabled by default in all
bundled keymaps.
The changes have been tested for some days by the animators here in the
Blender Animation Studio. Some changes are based on their feedback.
Also, this improves/adds comments for related code.
Differential Revision: https://developer.blender.org/D6235
Reviewed by: Sybren Stüvel, William Reynish
|
|
In 2011 special handling was introduced, apparently for no other
reason than to address a complaint in T25707 that World and Local
space are equivalent for objects without parent. This causes issues
and confusion, as mentioned in rB599c8a2c8e4.
This special meaning of Local Space is not documented in the manual,
and is not known to experienced riggers, so removing it should not
be a problem.
Differential Revision: https://developer.blender.org/D6095
|
|
In order to correctly drive corrective shape keys from a freely
rotating organic joint it is very often found necessary to
decompose the rotation into separate bending and twisting
motions. This type of decomposition cannot be reproduced by
any Euler order or a single quaternion.
Instead this is done by using a helper bone with a Damped Track
constraint aimed at the tail of the control to pick up the bending,
and its helper child with Copy Transforms to separate the twist.
Requiring two additional bones to drive a shape key or a correction
bone seems inconvenient, so this implements the necessary math as new
options in the recently introduced Rotation Mode dropdown of the
Transform Channel driver variable type. The data is also accessible
as a Transformation constraint input.
The output is in the form of Quaternion-derived 'pseudo-angles',
which for `Swing and Y Twist` would represent the following:
* W: true bend angle, independent of bend direction.
* Y: true twist angle.
* X, Z: pseudo-angles representing the proportion of bending around X/Z.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D5651
|
|
For reasons similar to drivers, it should be possible to set an
explicit Euler rotation order in constraints that use Euler angles.
The Transform constraint in a way approaches drivers in its use,
in that it effectively alters channels using values of other
channels after applying a fixed form mathematical expression.
For this reason, instead of just specifying the euler order for
its inputs, it uses the same enum as driver variables. However
Quaternion components are converted to a weighted pseudo-angle
representation as the rest of the constraint UI expects angles.
|
|
After adding the Euler order option, it's an easy addition to
the enum. The list of channels had of course to be expanded too.
|
|
The meaning of the euler angles completely depends on the rotation
order. Currently the rotation order is taken from the target of the
driver variable, which somewhat makes sense if it uses euler, but if
it's quaternion, then the order is always set to XYZ.
Add a new option for the rotation channels of the Transform Channel
driver variables that defaults to the old behavior, but allows setting
an explicit rotation order.
|
|
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
|
|
Some statements were split across multiple lines because of their
trailing comments.
In most cases it's clearer to put the comments above.
|
|
T68035 by @luzpaz
|
|
Differential Revision: https://developer.blender.org/D3744
|
|
|
|
Introduce a new function and use it everywhere, including
automatic curve deletion checks to guarantee consistency.
|
|
Unlike location and rotation, there is a meaningful definition of
overall/average scaling via the total change in the volume. This
adds an option to retrieve that via a single driver variable,
instead of having to use three and an expression.
Using the determinant to compute the volume scaling also allows
detecting flipping due to negative scale - this is impossible
to do via the three variable approach.
The volume_scale functions are added purely for code readability:
'volume scale factor' is easier to understand than determinant.
Differential Revision: https://developer.blender.org/D4803
|
|
|
|
|
|
|
|
Previously, when a fcurve modifier used storage,
many heap allocations were done.
This caused major slowdowns as described in T63656.
Furthermore, the storage usage was a special case only
used by the Cycles modifier. This refactor makes
storage usage the "normal" case.
That reduces the overall complexity.
The storage is stack allocated now.
The framerate on the provided test scene went up from ~5 fps to ~16 fps.
Reviewers: angavrilov
Differential Revision: https://developer.blender.org/D4701
|
|
Apply clang format as proposed in T53211.
For details on usage and instructions for migrating branches
without conflicts, see:
https://wiki.blender.org/wiki/Tools/ClangFormat
|
|
While \file doesn't need an argument, it can't have another doxy
command after it.
|
|
Move \ingroup onto same line to be more compact and
make it clear the file is in the group.
|
|
Needed for clan-format not to wrap onto one line.
|
|
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.
|
|
Part of D4277 by @sobakasu
|
|
This is necessary when adding a new keyframe to a fcurve
that also has a driver.
Reviewers: brecht, campbellbarton
Differential Revision: https://developer.blender.org/D4278
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When enabled, inserting keyframes into F-Curves with simple cyclic
extrapolation (the same conditions as required for cycle-aware auto
handle smoothing to activate) will take the cycle into account:
- Keyframes that are being inserted outside of the cycle bounds
are remapped to be inside the cycle. Thus it is not necessary
to be within the main iteration of the cycle when tweaking.
This becomes especially useful in the final animation tweaking
phase when the channel keys may be staggered for overlap, so
the actual master period is different for different channels.
- Modifying one of the end points of a cycle also changes the
other end point when appropriate, to preserve smooth transition.
This feature applies to both manual keyframe insertion using
'I', and auto-keyframing.
Differential Revision: https://developer.blender.org/D3140
|
|
Reviewers: brecht, campbellbarton
Differential Revision: https://developer.blender.org/D3802
|
|
- Order array length after the array.
- Put return argument last.
|
|
Simple isn't a good prefix for library names since
lots of unrelated modules could be called 'simple'.
Include 'py' in module name since this is a subset of Python,
one of the main motivations for this is to be Python like/compatible.
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|