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
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.
