Fixed use of lists using multiple arguments - `list` only
support a single argument.
Noticed working with fake-bpy-module - providing multiple
arguments to `list` resulted in typing error (e.g. "Too many type
arguments provided for "list"; expected 1 but received 2").
Pull Request: https://projects.blender.org/blender/blender/pulls/134663
Reading & restoring RNA "writable" state wasn't working reliably when
Python was called from multiple threads.
- Resolve by acquiring the GIL before calling `pyrna_write_*` functions.
- Assert `pyrna_write_*` has the GIL to prevent this happening again.
- Move duplicate checks from bpy_props.cc into utility functions.
`bpy.utils.unregister_class(bpy.types.Menu)` would remove `bl_rna`
type information from the menu (also Panels & other built-int types).
Prevent unregistering built-in types since this will only cause problems.
Even though from an internal standpoint one could also just use INT
layers (if I understand correctly they are both handled as long?), we
can just support getting/setting bool layers in
the bmesh layer API as well (otherwise, it looks impossible to access
boolean attributes in bmesh).
Pull Request: https://projects.blender.org/blender/blender/pulls/134344
Use `self` parameter to retrieve the actual 'owner' Main.
Previous code was using G_MAIN, which _should_ be fine in current usage
context, but would for sure break if these functions were to be used
from e.g. a temp Main.
Pull Request: https://projects.blender.org/blender/blender/pulls/134440
Cleaner and more future-proof. Also refactored slightly the code to make
it more readable.
And removed the 'experimental' warning in docs, this should have been
removed a long time ago.
Some versions of PySide give errors when imported together with
bpy.app.translations, because the latter uses a tp_name that does not
exist. The only other tp_name we have with a dot in it (bgl.Buffer)
does exist.
Pull Request: https://projects.blender.org/blender/blender/pulls/134033
Caused by 59dc67974a
The behavior of `RNA_path_from_ID_to_property` /
`RNA_path_from_ID_to_property_index` is that it only gets the "prefix"
of the struct -- the one we are looking for, the one that is missing
here -- if we feed it the `newptr` since it calls
`RNA_path_from_ID_to_struct(ptr)` to get that prefix.
If we feed it the **ID** pointer it will be empty (makes sense it would
basically be "path from ID to ID"...we need it to be "path from ID to
constraint").
Pull Request: https://projects.blender.org/blender/blender/pulls/133977
This makes the code simpler, aligns it with the builtin translations in
messages.cc, and should improve performance as well. My motivation
for the change is to allow returning StringRef/StringRefNull from the
translation functions instead of char pointers.
To test the change I used the Sun Position addon which includes
translations and toggled different languages in the preferences.
Pull Request: https://projects.blender.org/blender/blender/pulls/133827
Previously, the global storage of these types either used a GHash or a
blender::Map. VectorSet is preferrable to GHash because it's type safe,
clearer, and faster. It's preferrable to Map because the key doesn't
have to be duplicated and because iteration is faster.
This PR moves these registered types to VectorSet, just like the
node, node socket, and node tree types. Note that none of these types
use RAII for allocation, so freeing is still done manually.
Testing was manually interacting with each of these systems, including
with addons that register their own types.
Pull Request: https://projects.blender.org/blender/blender/pulls/133778
Similar to `bpy.data.user_map`, it returns a mapping of IDs to all the
filepaths they use.
Fairly basic still, may need to be refined with more options to
control which filepaths are included etc.
Mainly intended to make handling of a production blendfile dependencies
more easy.
Also adds some basic testing of the new feature.
Pull Request: https://projects.blender.org/blender/blender/pulls/127252
When calling bpy.utils.expose_bundled_modules(), these modules are
added to sys.path.
This provides a solution/workaround to two problems:
* Using bpy together with packages like usd-core is problematic. Besides
crashing due to C++ symbol conflicts, it's just impossible to import
different versions of the same module, or to have distinct environment
variables for both. (#127132)
* Blender add-ons using these VFX modules do not currently work with
the bpy module.
This adds about 15MB to the bpy package.
Pull Request: https://projects.blender.org/blender/blender/pulls/133082
The newly added "tangent_pair" calculation functions meant the names
didn't read well in some cases, use this style of naming for clarity:
- BM_face_calc_tangent_from_*
- BM_face_calc_tangent_pair_from_*
Support differentiating between portable & system installations,
useful to properly locate relative paths which would not work
on system installations.
Ref !133143
Clarify the meaning `bpy.app.version_file`, by being more explicit in the
description of `bpy.app.version` and their differences.
### Old:
`bpy.app.version`
: The Blender version as a tuple of 3 numbers. eg. (2, 83, 1)
`bpy.app.version_file`
: The Blender version, as a tuple, last used to save a .blend file, compatible with ``bpy.data.version``. This value should be used for handling compatibility changes between Blender versions
### New:
`bpy.app.version`
: The Blender version as a tuple of 3 numbers (major, minor, micro). eg. (4, 3, 1)
`bpy.app.version_file`
: The Blender File version, as a tuple of 3 numbers (major, minor, file sub-version), that will be used to save a .blend file. The last item in this tuple indicates the file sub-version, which is different from the release micro version (the last item of the `bpy.app.version` tuple). The file sub-version can be incremented multiple times while a Blender version is under development. This value is, and should be, used for handling compatibility changes between Blender versions
Pull Request: https://projects.blender.org/blender/blender/pulls/133142
* In case a subset of IDs is given, it was not checked that all items
are ID data.
* In case of error while processing the subset, there could be some
python data 'leak' (the `user_map` would not be unreferenced).
* Improve performances in case there are many duplicates in given subset
iterable of IDs, by not processing the duplicates.
Discovered in !127252 review.
When using clangd or running clang-tidy on headers there are
currently many errors. These are noisy in IDEs, make auto fixes
impossible, and break features like code completion, refactoring
and navigation.
This makes source/blender headers work by themselves, which is
generally the goal anyway. But #includes and forward declarations
were often incomplete.
* Add #includes and forward declarations
* Add IWYU pragma: export in a few places
* Remove some unused #includes (but there are many more)
* Tweak ShaderCreateInfo macros to work better with clangd
Some types of headers still have errors, these could be fixed or
worked around with more investigation. Mostly preprocessor
template headers like NOD_static_types.h.
Note that that disabling WITH_UNITY_BUILD is required for clangd to
work properly, otherwise compile_commands.json does not contain
the information for the relevant source files.
For more details see the developer docs:
https://developer.blender.org/docs/handbook/tooling/clangd/
Pull Request: https://projects.blender.org/blender/blender/pulls/132608
PR #129315 refactored polylines. The shaders now attaches the vertex
attributes as SSBOs. Adding a workaround for polyline shaders to
extract the correct vertex formats when called via Python.
Pull Request: https://projects.blender.org/blender/blender/pulls/132689
Confusing error messages are printed when requesting a clipped builtin
shader via Python that does not exist.
This PR will remove the confusion of the messaging:
- Replaced BLI_assert_unreachable with an assert as it is reachable
code.
- Adding clipped configuration for POLYLINE_UNIFORM_COLOR
Pull Request: https://projects.blender.org/blender/blender/pulls/132686
Rendering a scene with py-drivers would crash after dropping an
extension onto Blender's window then canceling before the update
completed.
This was caused by context.temp_override pushing arguments into the
context but failing to pop them in the case of an error - which would
happen when the popup was closed while the update ran.
ContextTempOverride objects were not freeing the reference to their
arguments when the context managers __exit__ didn't run.
This would happen if __enter__ failed with an unsupported configuration
or if object was created and not used.
Resolve by making ContextTempOverride a container type with GC support.
This also allows the ContextTempOverride to be reused since it's
arguments are now cleared when it's deallocated instead of __exit__.
This caused build errors on the docs builder, I can't seem to reproduce
locally, so revert for now and have another look at some point in the
future.
Sadly as these changes usually go, this took 5c515e26bb and
2f0fc7fc9f with it as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/132559
