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
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
There was one functional issue with the previous API which was its
use in `VolumeGrid<T>::grid_for_write(tree_token)`. The issue was
that the tree token had to be received before the grid is accessed.
However, this `grid_for_write` method might create a copy of the
`VolumeGridData` internally and if it does, the passed in `tree_token`
corresponds to the wrong tree.
The solution is to output the token as part of the method. This has two
additional benefits:
* The API is more safe, because one can't pass an r-value into the methods
anymore. This generally shouldn't be done, because the token should
live at least as long as the OpenVDB tree is used and shouldn't be freed
immediatly.
* The API is a bit simpler, because it's not necessary to call the
`VolumeGrid.tree_access_token()` method anymore.
Subdiv operator for GP3 implemented using the new curves and array APIs.
Compared to the old one, this implementation added a "keep_shape" property
so we could take advantage of the improved `smooth_curve_attribute()` function.
Pull Request: https://projects.blender.org/blender/blender/pulls/116740
This patch redesigns the Sun Beams node. The old implementation produces
unexpected results with an arbitrary alpha channel, due to the use of a
step count normalization instead of a weighted normalization. The
quality is also questionable due to the use of nearest neighbour
interpolation as well as a low resolution integration.
This patches redesign the node to be a simple line integration towards
the source, limited by the maximum ray length. The sampling resolution
covers the entire path of the integration and the image is sampled using
bilinear filtering, producing smoother results. No alpha is introduced.
Pull Request: https://projects.blender.org/blender/blender/pulls/116787
Add an option to output curves as NURBS instead of Bezier. The same
fitting algorithms are used. The only difference is that the drawing
result is a NURBS curve with Bezier knot mode, instead of a native
Blender Bezier curve.
Pull Request: https://projects.blender.org/blender/blender/pulls/116696
This doesn't seem to offer a lot of benefit but it is the
way it should be.
Other area could make use of this later and the
implementation could be supported at the gpu module level.
Crash is due to accessing higher index of 0 sized array. Fix this by
changing the size of vector.
Missing update seems to be due to wrong PBVH node flags and typo.
Pull Request: https://projects.blender.org/blender/blender/pulls/116935
Regression from porting "Smart UV Project" from Python to C
[0] which removed UV island alignment support.
Restore support by adding X/Y aligned rotation to UV pack. Vertical axis
alignment is the default for smart project matching previous behavior.
Resolves#116355.
[0]: 850234c1b1
The functions for creating bpy vector properties used fixed size
`default_value` arrays on the stack. The array was not large enough to
store all the default values for larger multidimensional properties,
which would write past the end of the array and start corrupting the
stack, leading to crashes.
The maximum total length of a bpy vector property is 32768 (32x32x32)
which is a little large of an array to be putting on the stack, so the
`default_value` array now uses `blender::Array` and allocates additional
memory if the number of `default_value` elements exceeds its inline
buffer size of 64.
To simplify allocating arrays of the correct size,
#bpy_prop_array_length_parse now fills in `array_len_info->len_total`
when parsing a sequence.
Pull Request: https://projects.blender.org/blender/blender/pulls/116811
This function had the exacyt same behavior as the 'UI' operators, make
local invoqued on a linked liboverride would make the data local, but
would not clear the liboverride data from it. User then needs to call
this operation again if they want to remove that liboverride data.
The new `clear_liboverride` parameter to `ID.make_local` forces always
clearing any liboverride data, and allows to make a linked liboverride
fully local with a single call.
This option is kept disabled by default, to ensure default behavior
remains unchanged.
This cleanup changes the `layer` parameter in `get_drawing_at` and `get_editable_drawing_at` to a reference.
This makes it clear that the layer is required for this function.
When loading an unknown node type from a newer Blender version, the node
storage data cannot be properly loaded. Re-saving the file will then
crash if saving with the same node type idname, since new Blender
versions cannot find the expected storage data.
Loading in older versions should replace unknown node types with a dummy
"Undefined" node that will get loaded as NodeTypeUndefined in newer
versions as well. Custom node types are exempted from this since they
store all data as generic ID properties and can always be fully
serialized.
This is a revised version of the initial attempt in #114803.
Doing the node type fix in the after-linking stage ensures that
versioning code can change outdated node types which might otherwise get
removed by this type check.
Pull Request: https://projects.blender.org/blender/blender/pulls/116908
This simplifies the code that creates the zone socket mappings at the cost of
slightly more memory per zone, which is not significant.
Previously, `IndexRange` was used where it now uses `Vector<int>`.
Pull Request: https://projects.blender.org/blender/blender/pulls/116939
Adds a header that defines the same constants as the C++ 20
<numbers> header.
Benefits:
- Decouple our C++ and C math APIs
- Avoid using macros everywhere, nicer syntax
- Less header parsing during compilation
- Can be replaced by `std::numbers` with C++ 20
Downsides:
- There are fewer numbers defined in the C++ standard header
- Maybe we should just wait until we can use C++ 20
Pull Request: https://projects.blender.org/blender/blender/pulls/116805
