This helps prevent long text from wrapping but still looks nice in my opinion.
In the future we might try to hide the base name part of the class but I think this would require a fix in sphinx.
This PR adds new RNA properties that deprecate and replace any `sequence` property.
The old prooperties are still there and fully functional, but the description is changed
to indicate that these will be removed in the future and that the new properties should
be used instead.
| Deprecated property | Replacement property |
| --------------------------------- | ----------------------------------- |
| `context.active_sequence_strip` | `context.active_strip` |
| `context.selected_editable_sequences` | `context.selected_editable_strips` |
| `context.selected_sequences` | `context.selected_strips` |
| `context.sequences` | `context.strips` |
| `SequenceEditor.sequences` | `SequenceEditor.strips` |
| `SequenceEditor.sequences_all` | `SequenceEditor.strips_all` |
| `MetaStrip.sequences` | `MetaStrip.strips` |
Previously, rna paths for animation data on strips started with `sequence_editor.sequences`.
This PRadds versioning for the rna paths to make sure to use
the new naming scheme. This does mean that in previous versions of blender,
the animations don't show but the data is not lost (even if the file is saved in the older version).
Also do some cleanup of existing python scripts inside the source to use the
new properties.
Part of #132963.
Pull Request: https://projects.blender.org/blender/blender/pulls/133156
`super()` is using the MRO to find the first `__init__()` function, if the blender-defined type is not the first inherited type, it may never be called that way.
See #133183
ID Property methods were missing from the API docs,
error in [0] which added docs for this type.
[0]: 10e3e3b4a0
Co-authored-by: nutti <nutti.metro@gmail.com>
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
While in theory it would be good to have calls to super classes'
`__del__()` destructors in subclasses, matching the ones to
`__init__()`, several limitations of current CPython implementation do
not make it a practical requirement.
So remove `__del__` from examples, and add a note summarizing the
current problems with using it (aka `tp_finalize` in C++ code).
Also see !132476 for some discussion about that topic.
According to the Python API release notes, this is required now along
with super().__init__() which was already done.
Also fixes mistake in example in API docs.
Pull Request: https://projects.blender.org/blender/blender/pulls/132476
Updated the example to include new hook functions
material_import_poll and on_material_import as well
as the new import_texture and export_texture
utilities which were introduced in #131559.
Also reformatted the existing documentation to include
subheaders and internal links, as the previous paragraph
format became difficult to follow.
Pull Request: https://projects.blender.org/blender/blender/pulls/132259
The goal of this test is to try to import some critical py scripts with the
system python of the building machine.
The main target is to ensure that these py scripts remain usable by all
buildbot machines, as some of them are using fairly outdated python
versions.
Current status:
* Scripts in `build_files` and `docs` are checked.
* Some python scripts in `build_files` were 'reverted' to be compatible
with older required python version currently (3.6).
* A few scripts are excluded from the test, mostly because they use Blender's
`bpy` module, which means they are only intended to be ran with Blender's
python anyway.
* The test is only enabled for Linux buildbots currently, as they use the
oldest Python by far.
Notes:
* Some more scripts are likely to be moved around in the future.
* Whether these tests need to be enabled on windows or macos platforms remains
an open question.
Pull Request: https://projects.blender.org/blender/blender/pulls/130746
When importing an USD, the Blender object names do not necessarily match
Prim names:
```
#usda 1.0
def Xform "xform1"
{
def Mesh "MyObject" # Will be imported as "MyObject"
}
def Xform "xform2"
{
def Mesh "MyObject" # Will be imported as "MyObject.001"
}
def Xform "xform2"
{
def Mesh "MyObject" # Will be imported as "MyObject.002"
}
```
This makes it difficult in the [USD Import Hooks]
(https://docs.blender.org/api/current/bpy.types.USDHook.html) to link a
Blender object back to its source Prim for additional processing. A
typical use cases for games is to generate UVs, create and apply a
material on the fly when importing a collision shape that does not have
a visual representation (hence no materials) based on some Prim
attributes, but that the artist needs to differenciate in Blender's
viewport.
The Import context exposes a new method `get_prim_map()` that returns a
`dict` of `prim path` / `list of Blender ID`.
For example, given the following USD scene,
```
/
|--XformThenCube [def Xform]
| `--Cube [def Cube]
|--XformThenXformCube [def Xform]
| `--XformIntermediate [def Xform]
| `--Cube [def Mesh]
|--Cube [def Cube]
`--Material [def Material]
`--Principled_BSDF [def Shader]
```
the `get_prim_map()` method will return a map as:
```python
@static_method
def on_import(import_context):
pprint(import_context.get_prim_map())
```
```json
{
"/Cube": [bpy.data.objects["Cube.002"], bpy.data.meshes["Cube.002"]],
"/XformThenCube": [bpy.data.objects["XformThenCube"]],
"/XformThenCube/Cube": [bpy.data.objects["Cube"], bpy.data.meshes["Cube"]],
"/XformThenXformCube": [bpy.data.objects["XformThenXformCube"]],
"/XformThenXformCube/XformIntermediate": [bpy.data.objects["XformIntermediate"]],
"/XformThenXformCube/XformIntermediate/Cube": [bpy.data.objects["Cube.001"], bpy.data.meshes["Cube.001"]],
"/Material": [bpy.data.materials["Material"]],
}
```
Co-authored-by: Odréanne Breton <odreanne.breton@ubisoft.com>
Co-authored-by: Sttevan Carnali Joga <sttevan.carnali-joga@ubisoft.com>
Co-authored-by: Charles Flèche <charles.fleche@ubisoft.com>
Essentially, any operator modifying Blender data should enable this
`UNDO` option, else bad things (corruption, crashes...) are likely to
happen.
* Added a new Operator example to explain this topic.
* Updated some existing Operator examples that were not correct anymore.
* Added a new small section in the gotchas page linking to it.
* Added also short reminder about this in the `UNDO` 'tooltip'
description itself.
Related to #77557.
This PR:
* Splits the `Gotchas` page into several sub-sections. This was getting too big and hard to navigate.
* Adds some information regarding Python instances life-time of objects wrapping Blender internal data.
* Adds some information about usage of constructors and destructors for sub-classes of Blender-defined types.
Pull Request: https://projects.blender.org/blender/blender/pulls/129814
