The bone collection unit tests in Python were failing, but this failure
was not propagated to `ctest` and thus went unnoticed.
Both issues are now fixed.
There is currently a bug with autopep8 and Python 3.12, resulting in
the contents of f-strings getting modified when they shouldn't.
As a workaround, "make format" now uses the Python binary bundled with
the precompiled libraries on Linux by default. This matches existing
behavior on macOS and Windows.
Pull Request: https://projects.blender.org/blender/blender/pulls/116993
This PR cleans up shader builder CMake files and fixes vulkan includes
that could not be found on all platforms.
* Reduce code duplication
* Use private var for MANIFEST on windows
* Add system includes when compiling
Pull Request: https://projects.blender.org/blender/blender/pulls/115889
When anisotropic filtering is enabled on a sampler its value must be
between 1 and 16. In blender it is possible to set a value lower than 1.
0 actually means that anisotropic filtering is disabled in Blender.
This would trigger a validation error in Vulkan.
Pull Request: https://projects.blender.org/blender/blender/pulls/117018
Starting with Blender 4.0, Blender refuses to load a userpref.blend file
that had been generated on a macoOS machine, exiting immediately with an
unsupported GPU error. This is because when the userdef was written on
the macOS machine (assuming a recent version), it has gpu_backend set to
GPU_BACKEND_METAL (which is rejected). The same is true in reverse.
Prior to commit cdb8a8929c there was a runtime fallback such
that the setting for Metal backend would be ignored on non-Metal
platforms.
This adds a check in blo_do_versions_userdef() for if gpu_backend is set
to an unsupported backend; if so, it is set to a default supported value
for the current platform (Metal on macOS, OpenGL otherwise). This
replaces the current versioning check, as this isn't strictly related to
versioning. The new logic handles the narrower versioning case (a macOS
user upgrading to 4.0+ with a userprefs selecting OpenGL) as well.
This should be future-proof for other GPU backends, as it only overrides
in the case of an unsupported value. The logic could be generalized in
the future, perhaps.
Co-authored-by: Andrew Oates <andrew@andrewoates.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/116861
Oversight in [0] which assumed the cage meshes vertices were aligned
with the edit-mesh vertices which isn't always the case.
Check the cage mesh only has deformations applied before using it.
[0]: 29a338811c
While the shortcuts would be shown for menus & panels,
there was no way to edit them from the context menu.
This was reported as a bug since moving "Undo History" from an operator
to a menu meant it was no longer possible to assign a shortcut from
the context menu.
Resolves: #97431.
Replaces this search by representing the 3 edge lengths of each triangle
as 3d points and searching with a KD-tree.
On a mesh with ~20k Tris the old method runs in 40s while the new method
takes 0.23s with a difference of <0.001%.
Ref !113720
When drawing tooltips that include images the blend mode must be left
with GPU_BLEND_NONE, otherwise can interfere with later drawing. Also
slight refactor in that buttons with a custom tooltip function get a
"ui_tooltip_data_from-*" function like the other types.
Pull Request: https://projects.blender.org/blender/blender/pulls/117001
Bool attributes are treated as contiguous arrays of `bool` rather than
using a bitmask.
Using a bitmask also disables raw array access, and with raw array
access, the property is faster to access through the Python API with
bpy_rna.cc#foreach_getset.
Pull Request: https://projects.blender.org/blender/blender/pulls/116997
Fixes an issue where CPU specific render settings (e.g. path guiding)
would be hidden when GPU Compute has been selected for rendering,
but a GPU hasn't been selected in preferences.
Pull Request: https://projects.blender.org/blender/blender/pulls/116123
In this case the object transform can use more motion steps, but the
geometry needs to have its motion steps fixed since the velocity
attribute completely overrides them.
As suggested by Campbell, this changes structure, variable, and
callback names to use "confirm" terminology rather than "warning"
for code related to custom confirmations.
Pull Request: https://projects.blender.org/blender/blender/pulls/116992
Change to map the USD "varying" interpolation type to Blender's
"Corner" domain type when importing mesh attributes. This fixes
value count mismatch errors when importing USD attributes with
varying interpolation.
Note that, for meshes, "varying" and "faceVarying" interpolation
are essentially the same in practice.
Pull Request: https://projects.blender.org/blender/blender/pulls/116955
RNA raw types were missing for the int8_t, uchar (uint8_t),
ushort (uint16_t), int64_t and uint64_t DNA types types.
This adds the missing RNA raw types for all DNA types that can have
raw access.
Functional Changes
Properties with one of the new unsigned raw types will raise a Python
OverflowError in foreach_getset when attempting to read a negative
integer from bpy_prop_collection.foreach_set(). This is similar to the
existing behaviour of providing a Python int which is too large to
represent as a C long. The existing foreach_getset code will print
the OverflowError and then raise a TypeError instead.
CPython's signed integer parsing functions accept numeric types that are
not the Python int instances by calling their __index__() method.
CPython's unsigned integer parsing functions, however, only accept
Python int instances. To make foreach_getset accept the same
numeric types for unsigned raw types as it already accepts for signed
raw types, the unsigned integer parsing functions in py_capi_utils.h
have been updated to also call the __index__() method when given an
argument which is not a Python int instance.
Because the new unsigned integer parsing in foreach_getset is using
the PyC_ family of functions, which perform their own overflow checks,
the existing signed integer parsing has also been updated to use the
PyC_ family of functions for signed integer parsing. Previously,
OverflowError would only have been raised when the parsed integer was
too large to fit in a C long. With this patch, OverflowError will be
raised whenever the parsed integer is too large to fit in the property's
raw type. Integer properties already have well-defined maximum and
minimum values which should fit within the property's raw type, and enum
properties have a fixed number of values they can take depending on
their items. The bigger change here, is that setting bool properties
which use PROP_RAW_BOOLEAN will now only accept 0/False and
1/True.
Now that PROP_RAW_CHAR parsing is using PyC_Long_AsU8,
signed char buffers ("b" format) have been updated to no longer be
considered compatible with PROP_RAW_CHAR, matching the behaviour of
the other unsigned types only being considered compatible with unsigned
buffer formats.
The int64_t and uint64_t types can currently only be used by bool
properties (see IS_DNATYPE_BOOLEAN_COMPAT and the other macros in
RNA_define.hh), but bool properties only have raw access when they do
not use a bitmask and it doesn't make much sense to use an entire 64
bits just for a single bool property, so PROP_RAW_INT64 and
PROP_RAW_UINT64 are expected to be unused.
Performance Changes
Providing raw types allows for faster access through
rna_access.cc#rna_raw_access, especially when a buffer compatible with
the property's raw type is passed through from
bpy_rna.cc#foreach_getset.
Before this patch, the bpy.types.Keyframe.handle_left_type property
did not have raw access, so foreach_getset would fall back to
PROP_RAW_INT being the compatible type and then use the slower loop in
rna_raw_access.
With this patch, the bpy.types.Keyframe.handle_left_type property has
raw access with the PROP_RAW_UINT8 type. Using a buffer compatible
with this raw type can use the faster memcpy loop in
rna_raw_access. Using a Python list will iterate the list into an
array whose type matches PROP_RAW_UINT8, which will also use the
faster memcpy loop in #rna_raw_access.
Pull Request: https://projects.blender.org/blender/blender/pulls/115761
RNA raw types were missing for the int8_t, uchar (uint8_t),
ushort (uint16_t), int64_t and uint64_t DNA types types.
This adds the missing RNA raw types for all DNA types that can have
raw access.
Functional Changes
Properties with one of the new unsigned raw types will raise a Python
OverflowError in foreach_getset when attempting to read a negative
integer from bpy_prop_collection.foreach_set(). This is similar to the
existing behaviour of providing a Python int which is too large to
represent as a C long. The existing foreach_getset code will print
the OverflowError and then raise a TypeError instead.
CPython's signed integer parsing functions accept numeric types that are
not the Python int instances by calling their __index__() method.
CPython's unsigned integer parsing functions, however, only accept
Python int instances. To make foreach_getset accept the same
numeric types for unsigned raw types as it already accepts for signed
raw types, the unsigned integer parsing functions in py_capi_utils.h
have been updated to also call the __index__() method when given an
argument which is not a Python int instance.
Because the new unsigned integer parsing in foreach_getset is using
the PyC_ family of functions, which perform their own overflow checks,
the existing signed integer parsing has also been updated to use the
PyC_ family of functions for signed integer parsing. Previously,
OverflowError would only have been raised when the parsed integer was
too large to fit in a C long. With this patch, OverflowError will be
raised whenever the parsed integer is too large to fit in the property's
raw type. Integer properties already have well-defined maximum and
minimum values which should fit within the property's raw type, and enum
properties have a fixed number of values they can take depending on
their items. The bigger change here, is that setting bool properties
which use PROP_RAW_BOOLEAN will now only accept 0/False and
1/True.
Now that PROP_RAW_CHAR parsing is using PyC_Long_AsU8,
signed char buffers ("b" format) have been updated to no longer be
considered compatible with PROP_RAW_CHAR, matching the behaviour of
the other unsigned types only being considered compatible with unsigned
buffer formats.
The int64_t and uint64_t types can currently only be used by bool
properties (see IS_DNATYPE_BOOLEAN_COMPAT and the other macros in
RNA_define.hh), but bool properties only have raw access when they do
not use a bitmask and it doesn't make much sense to use an entire 64
bits just for a single bool property, so PROP_RAW_INT64 and
PROP_RAW_UINT64 are expected to be unused.
Performance Changes
Providing raw types allows for faster access through
rna_access.cc#rna_raw_access, especially when a buffer compatible with
the property's raw type is passed through from
bpy_rna.cc#foreach_getset.
Before this patch, the bpy.types.Keyframe.handle_left_type property
did not have raw access, so foreach_getset would fall back to
PROP_RAW_INT being the compatible type and then use the slower loop in
rna_raw_access.
With this patch, the bpy.types.Keyframe.handle_left_type property has
raw access with the PROP_RAW_UINT8 type. Using a buffer compatible
with this raw type can use the faster memcpy loop in
rna_raw_access. Using a Python list will iterate the list into an
array whose type matches PROP_RAW_UINT8, which will also use the
faster memcpy loop in #rna_raw_access.
Pull Request: https://projects.blender.org/blender/blender/pulls/115761
