Improve handling of runtime defined python RNA properties. Mainly:
* Add `get_transform` and `set_transform` new callbacks.
These allow to edit the value, while still using the default
(IDProperty-based) storage system.
* Read-only properties should now be defined using a new `options` flag,
`READ_ONLY`.
* `get`/`set` should only be used when storing data outside of the
default system now.
* Having a `get` without a `set` defined forces property to be
read-only (same behavior as before).
* Having a `set` without a `get` is now an error.
* Just like with existing `get/set` callbacks, `get_/set_transform`
callbacks must always generate values matching the constraints defined
by their `bpy.props` property definition (same type, within required
range, same dimensions/sizes for the `Vector` properties, etc.).
* To simplify handling of non-statically sized strings, the relevant
RNA API has been modified, to use `std::string` instead of
(allocated) char arrays.
Relevant unittests and benchmarking have been added or updated as part
of this project.
Note: From initial benchmarking, 'transform' versions of get/set are
several times faster than 'real' get/set.
Implements #141042.
Pull Request: https://projects.blender.org/blender/blender/pulls/141303
This add systematic tests for bool/int/float 'Vector' bpy props for:
* Index access
* Slice access
* 1d, 2d and 3d arrays
* default storage and custom storage (get/set)
NOTE: Non-vector prop types also need some systematic testing, they do
not appear to have any currently?
Pull Request: https://projects.blender.org/blender/blender/pulls/144998
The `a + array_len > in.len` check was off-by-1 whenever accessing a
non-array property without raw access. This was because `array_len` was
actually the array length of the property, which is `0` for non-array
properties.
Given an array which was too short, this would cause the slower loop to
overrun the end of the array by one item. When getting items this would
cause a crash on a debug build with `Fatal Python error:
_PyMem_DebugRawFree: bad trailing pad byte`.
So use `item_len` instead, wichi is always set to `1` for non-array
properties.
Also do not assume that an `array_len` of `0` means that the property is
an array. While this may be true currently, it is cleaner and safer to
use the dedicated RNA API to check that.
This PR also adds some basic checks for expected failure of `foreach_set`
/`foreach_get` API when the provided array is too small.
Co-authored-by: Bastien Montagne <bastien@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/115967
The foreach_get/foreach_set methods of bpy_prop_array get/set the entire
contents of the array, but they were checking that the length of the
input sequence was equal to the length of the current array dimension
rather than the total length of all dimensions of the array.
This would read/write memory after the end of the passed in sequence
when the property was a multidimensional array. Performing
`foreach_get` with a Python list with length matching the length of the
current dimension of a multidimensional array would crash a debug build
due to the trailing pad bytes of the temporarily allocated array being
overwritten.
This patch fixes `pyprop_array_foreach_getset` by changing the function
used to get the expected sequence size, to the RNA function that gets
the total length of the array across all its dimensions.
The tests have be updated to additionally test multidimensional array
properties.
Pull Request: https://projects.blender.org/blender/blender/pulls/116457
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
Now only dynamic function parameters that use ParameterDynAlloc support
dynamically sized parameters arrays.
Add tests for both dynamic arrays that don't support resizing
(Image.pixels) and dynamic sized arguments using
(VertexGroup.add(index=[..])).
Regression in [0] which extended support for dynamic sized function
arguments.
[0]: dfb8c5974e
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
- Multi-dimensional boolean, int and float vector types are supported.
- A sequence of int's for the "size" is used to declare dimensions.
- Nested sequences are required for default arguments.
Now it's possible to define matrix properties, for e.g:
bpy.props.FloatVectorProperty(size=(4, 4), subtype='MATRIX')
This allows fast access to various arrays in the Python API.
Most notably, `image.pixels` can be accessed much more efficiently now.
**Benchmark**
Below are the results of a benchmark that compares different ways to
set/get all pixel values. I do the tests on 2048x2048 rgba images.
The benchmark tests the following dimensions:
- Byte vs. float per color channel
- Python list vs. numpy array containing floats
- `foreach_set` (new) vs. `image.pixels = ...` (old)
```
Pixel amount: 2048 * 2048 = 4.194.304
Byte buffer size: 16.8 mb
Float buffer size: 67.1 mb
Set pixel colors:
byte - new - list: 271 ms
byte - new - buffer: 29 ms
byte - old - list: 350 ms
byte - old - buffer: 2900 ms
float - new - list: 249 ms
float - new - buffer: 8 ms
float - old - list: 330 ms
float - old - buffer: 2880 ms
Get pixel colors:
byte - list: 128 ms
byte - buffer: 9 ms
float - list: 125 ms
float - buffer: 8 ms
```
**Observations**
The best set and get speed can be achieved with buffers and a float image,
at the cost of higher memory consumption. Furthermore, using buffers when
using `pixels = ...` is incredibly slow, because it is not optimized.
Optimizing this is possible, but might not be trivial (there were multiple
attempts afaik).
Float images are faster due to overhead introduced by the api for byte images.
If I profiled it correctly, a lot of time is spend in the `[0, 1] -> {0, ..., 255}`
conversion. The functions doing that conversion is `unit_float_to_uchar_clamp`.
While I have an idea on how it can be optimized, I do not know if it can be done
without changing its functionality slightly. Performance wise the best solution
would be to not do this conversion at all and accept byte input from the api
user directly, but that seems to be a more involved task as well.
Differential Revision: https://developer.blender.org/D7053
Reviewers: JacquesLucke, mont29
