This replaces header include guards with `#pragma once`.
A couple of include guards are not removed yet (e.g. `__RNA_TYPES_H__`),
because they are used in other places.
This patch has been generated by P1561 followed by `make format`.
Differential Revision: https://developer.blender.org/D8466
There is a parameter typo in Python API document about bpy.props.StringProperty.
This patch fixes this.
Also this patch should apply to 2.90 branch as well.
Reviewed By: Grische, mont29
Differential Revision: https://developer.blender.org/D8430
As creator.c is used for the 'main' function,
avoid obscure declarations being placed so prominently.
- Move Blender as a Python module declarations into it's own section.
- Move USD declaration to an 'extern' just before it's called.
The abbreviation 'init' is brief, unambiguous and already used
in thousands of places, also initialize is often accidentally
written with British spelling.
Showing the Python error without any explanation is often
not enough information and doesn't hint that the error was in the
user input.
The error report from a invalid expression such as '..1' used to be:
('invalid syntax', ('<string>', 1, 1, '..1'))
Now reads:
Error evaluating number, see Info editor for details: invalid syntax
Address issue raised by T78913.
The result of syntax errors read poorly in reports,
resulting in cryptic and unhelpful information.
Change PyC_ExceptionBuffer_Simple only to extract the initial text,
making syntax errors when entering invalid numeric expressions into
buttons easier to follow.
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
