Every code path through the `fcurve_eval_keyframes_interpolate()` function
has a valid `return` statement, but in debug mode GCC still doesn't like it.
Previously there were two functions for FCurve extrapolation, one for
before the first keyframe, and the other for after the last. After the
previous cleanup made the variable names consistent, it was clear that
the code was almost identical. The biggest difference was in the sign of
many of the calculations, which was cancelled out by swapping `B-A` to
`A-B`. This showed that the computations are actually the same, and the
only remaining difference was which neighbouring handle to use in case
of Bézier curves.
No functional changes.
# Conflicts:
# source/blender/blenkernel/intern/fcurve.c
Variables have been renamed so that they refer to the endpoint and its
neighbor (rather than `bezt`, `prevbezt`, or `lastbezt`), and
unnecessary variables have been removed. By returning early the code
flow is also easier to understand.
No functional changes.
The `fcurve_eval_keyframes` consists of three parts:
- Before the first keyframe
- After the last keyframe
- Between the keyframes
This commit splits the first two parts into separate functions. This is
the first of a series of refactors, which will be committed into smaller
parts so that each is easier to follow & validate.
No functional changes.
All the driver-specific code in `fcurve.c` has been moved into a new file
`fcurve_driver.c`. The corresponding declarations have been moved from
`BKE_fcurve.h` to `BKE_fcurve_driver.h`.
All the `#include "BKE_fcurve.h"` statements have been investigated and
replaced with `BKE_fcurve_driver.h` where necessary.
No functional changes.
Note this only changes cases where the variable was declared inside
the for loop. To handle it outside as well is a different challenge.
Differential Revision: https://developer.blender.org/D7320
The `BKE_animsys.h` and `anim_sys.c` files already had a an "AnimData
API" section. The code in that section has now been split off, and
placed into `BKE_anim_data.h` and `anim_data.c`.
All files that used to include `BKE_animsys.h` have been adjusted to
only include the animation headers they need (sometimes none).
No functional changes.
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
This reverts commit 7728bfd4c4.
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.
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.
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.
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
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
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.
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
