In the latest version 2.8 of Blender developers have made many changes in API, so all the scripts and add-ons written for earlier Blender versions (2.7 and below) have stopped working. To run your add-ons in the new Blender 2.8, you need to port them – correct their code to work properly with the new Blender API.
To enable your add-on in Blender 2.80 you have to make the following changes in code:
To check is an attribute/property of any Blender object (mesh, node, modifier, etc.) read-only:
<object> .is_property_readonly (‘<property name>’)
<object> .bl_rna.properties [‘<property name>’]. is_readonly
For example, for the “is_editmode” mesh property (is the mesh in edit mode or not):
|
1 2 3 4 5 6 7 8 |
bpy.context.active_object.data.is_property_readonly('is_editmode') # True bpy.context.active_object.data.bl_rna.properties['is_editmode'].is_readonly # True |
To check in what version of Blender the blend file was saved:
|
1 |
bpy.data.version |
Or open the blend file in any text editor, for example in Notepad++. The Blender version will be listed in the first 15 characters.
Also, the version of the open blend file can be viewed in the Outliner window in the Data Blocks group:
A complete list of add-ons installed in Blender we can get using the addon_utils:
|
1 2 3 4 |
import addon_utils print(addon_utils.modules()[:]) # <module 'space_view3d_3d_navigation' from ... |
Having the add-ons list, we can get the version of the desired add-on by its name with the following code:
|
1 2 3 4 |
import addon_utils print([addon.bl_info.get('version', (-1,-1,-1)) for addon in addon_utils.modules() if addon.bl_info['name'] == 'ADD-ON_NAME'][0]) # (1,4,0) |
Where the ADD-ON_NAME is the name of the desired add-on.
If the add-on is missing a version indication, the default result will be returned.
|
1 |
# (-1,-1,-1) |
In general, the “loop” is usually a sequential selection of several points, edges or polygons of a mesh.
However, there is an element in the mesh structure, which is also called a “loop”. It is a combination of one vertex with one edge of the mesh. Let’s try to learn what these “loops” are for.
When starting Blender from the console it processes all parameters passed through the command line. However, some scripts and add-ons for proper work may require specifying their unique command line arguments. If you specify such additional parameters in the command line, Blender will also try to process them, which is likely to result in an error. Blender provides a special way to exclude such arguments from own processing.
How to pass command line arguments to a Blender python script or add-onRead More »
State switches so-called “radio buttons” are used in the case to limit the choice by one value from several available ones. There are a lot of such buttons in the Blender interface, for example, switching between RGB and BW rendering modes or setting the texture mapping mode. Such buttons can be created in the Blender add-ons interface too.
Let’s create our own radio button switcher.
Creating radio buttons in the Blender add-ons interfaceRead More »
Single add-on or script can contain several different operators, and not all of them may be registered in the API by the register() function. To verify that the required operator is registered in the Blender API, run the following command:
|
1 |
hasattr(bpy.types, bpy.ops._operator_bl_idname_.idname()) |
Where:
_operator_bl_idname_ – the text value of the bl_idname operator property.
For example for an operator:
|
1 2 3 4 5 6 |
class TestOperator(bpy.types.Operator): bl_idname = 'test.operator' bl_label = 'Test operator' def execute(self, context): pass |
the command will look like this:
|
1 |
hasattr(bpy.types, bpy.ops.test.operator.idname()) |
To start working every Blender add-on must be registered by setting up the checkbox before add-on name in the User Preferences window – Add-ons page.
To programmatically find out if the required add-on is registered, run the following command:
|
1 |
'add-on_name' in the file bpy.context.user_preferences.addons |
Where:
add-on_name – the name of the add-on file (without the .py extension) or the name of the add-on package, if it was installed from the package.
It is convenient to use the following system for debugging developing multi-file Blender add-ons. But it has one drawback: modules imported in __init__.py file becomes available only after the file running (after the execution of the register() function). This means that any access to the imported modules before they are registered will cause an error. This is not critical in most cases, but it will cause a problem if, for example, in one imported module is used inheritance from the class, described in the other imported module, because the classes descriptions are processed before the add-on registration.
To get more freedom working with imported modules, we can use another way to debug the add-on – do not run the add-on directly from the development directory, but install it in Blender and check its “live” work. However, manual add-on reinstallation requires a set of routine actions, which complicates such sort of debugging. This issue can be solved by reinstalling the add-on in automatic mode.
Debugging multifile Blender add-on by quick reinstallRead More »