Implementation of lerp without a function requires repeating one of
the arguments, which is not ideal. To avoid that, add a new function
to the driver namespace. In addition, provide a function for clamping
between 0 and 1 to support easy clamped lerp, and a smoothstep function
from GLSL that is somewhat related.
The function implementations are added to a new bl_math module.
As an aside, add the round function and two-argument log to the
pylike expression subset.
Differential Revision: https://developer.blender.org/D8205
Custom driver functions need access to the dependency graph that is
triggering the evaluation of the driver. This patch passes the
dependency graph pointer through all the animation-related calls.
Instead of passing the evaluation time to functions, the code now passes
an `AnimationEvalContext` pointer:
```
typedef struct AnimationEvalContext {
struct Depsgraph *const depsgraph;
const float eval_time;
} AnimationEvalContext;
```
These structs are read-only, meaning that the code cannot change the
evaluation time. Note that the `depsgraph` pointer itself is const, but
it points to a non-const depsgraph.
FCurves and Drivers can be evaluated at a different time than the
current scene time, for example when evaluating NLA strips. This means
that, even though the current time is stored in the dependency graph, we
need an explicit evaluation time.
There are two functions that allow creation of `AnimationEvalContext`
objects:
- `BKE_animsys_eval_context_construct(Depsgraph *depsgraph, float
eval_time)`, which creates a new context object from scratch, and
- `BKE_animsys_eval_context_construct_at(AnimationEvalContext
*anim_eval_context, float eval_time)`, which can be used to create a
`AnimationEvalContext` with the same depsgraph, but at a different
time. This makes it possible to later add fields without changing any
of the code that just want to change the eval time.
This also provides a fix for T75553, although it does require a change
to the custom driver function. The driver should call
`custom_function(depsgraph)`, and the function should use that depsgraph
instead of information from `bpy.context`.
Reviewed By: brecht, sergey
Differential Revision: https://developer.blender.org/D8047
This was disabled during 2.8x for smooth porting of 2.7x scripts,
Now '@' is used for matrix multiplication,
support '*' to multiple vector elements.
See T56276.
Time will tell whether we need to expose more RNA override flags here.
Implements/Fix T78534.
Differential Revision: https://developer.blender.org/D8250
This must match the specified number in enum items, and is supported for both
static and dynamic enums. Previously dynamic enums did not support a default
value at all.
When "Relative Remap" option was added, the intention was only to remap
paths that were already relative. However it remapped all paths.
This was reported as T62612 and fixed recently,
however some Python script authors depended on the old behavior.
For users, it's reasonable to use the existing operators to make paths
absolute/relative. For scripts however it's useful to be able to write
out individual data-blocks with the ability to make all paths relative.
Now `bpy.data.libraries.write()` takes a path_remap argument which can
be `NONE/RELATIVE/RELATIVE_ALL/ABSOLUTE` allowing the script author to
choose how paths are handled when writing out data-blocks.
Addresses T77768.
This is related to T76659.
This just renames data type names to `CD_PROP_STRING`, `CD_PROP_FLOAT`
and `CD_PROP_INT32`. It makes them a bit more specific and removes
unnecessary abbreviations.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D7980
This caused an additional argument when exiting object modes
and many other low level functions which don't need to access context.
This simplifies fixing T77073.
The documentation for the `frame_change_pre` and `frame_change_post`
handlers was really sparse, and suggested that `frame_change_pre` is
called before the frame changes. This is not the case; it's called after
the frame has changed, but before the dependency graph has been updated
for it.
No functional changes, just updated documentation.
Differential Revision: https://developer.blender.org/D7905
Reviewed by: sergey
This remove the complexity of queriying the locations at runtime and
allows for more performance and upfront binding specifications.
The benefit of doing everything at creation time is that we can assign binding
points in a predictable order which is going to be somewhat the same for
every similar shader.
This also rewrite GPU_vertformat_from_shader to not use shaderface.
This is to keep the shaderface simple. If it becomes necessary to not query
the shader after creation (i.e: vulkan?) we could just create the vert
format in advance at compilation for PyGPU shaders.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D7879
The file subversion is no longer used in the Python API or user interface,
and is now internal to Blender.
User interface, Python API and file I/O metadata now use more consistent
formatting for version numbers. Official releases use "2.83.0", "2.83.1",
and releases under development use "2.90.0 Alpha", "2.90.0 Beta".
Some Python add-ons may need to lower the Blender version in bl_info to
(2, 83, 0) or (2, 90, 0) if they used a subversion number higher than 0.
https://wiki.blender.org/wiki/Reference/Release_Notes/2.83/Python_API#Compatibility
This change is in preparation of LTS releases, and also brings us more
in line with semantic versioning.
Fixes T76058.
Differential Revision: https://developer.blender.org/D7748
Surrounding includes with an 'extern "C"' block is not necessary anymore.
Also that made it harder to add any C++ code to some headers, or include headers
that have "optional" C++ code like `MEM_guardedalloc.h`.
I tested compilation on linux and windows (and got help from @LazyDodo).
If this still breaks compilation due to some linker error, the header containing
the symbol in question is probably missing an 'extern "C"' block.
Differential Revision: https://developer.blender.org/D7653
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.
This goes along with the existing changes to ignore PYTHONPATH by default.
--python-use-system-env now controls both.
Differential Revision: https://developer.blender.org/D6962
This solution involves adding a uniform to each fragment shader that is
used by gizmo drawing and use the framebuffer state to set this uniform
accordingly.
This solution can also be carried to external shaders (addons).
A single line of code would then be enough to fix the issue.
The only trickery here is the dummy define:
`#define srgb_to_framebuffer_space(a)`
This is in order to avoid breaking other DRW shaders that use the same
fragment shader code but do not need the tranformation.
Related to T74139
Reviewed By: brecht, campbellbarton
Differential Revision: https://developer.blender.org/D7261
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
