Add-ons let you extend Blender's functionality using Python. Most of the time you can get add-ons as part of the Extensions system.


If the Add-on does not activate when enabled, check the Console window for any errors that may have occurred.


新しいアドオンを含む個人用ディレクトリを作成し、 Preferences(プリファレンス)File Paths(ファイルパス) セクションで、ファイルパスを構成することもできます。個人用スクリプトディレクトリを作成するには:

  1. 選択した場所(例. my_scripts)に空のディレクトリを作成します。

  2. my_scripts 配下に addons サブディレクトリを追加します(Blenderが認識するためにはこの名前である必要があります)。

  3. Preferences(プリファレンス)File Paths(ファイルパス) を開きます。

  4. スクリプトディレクトリ(例. my_scripts)を指すように Scripts(スクリプト) ファイルパスを設定します。

  5. プリファレンスを保存し、Blenderを再起動すると、新しいアドオンの場所を認識します。

これで、サードパーティのスクリプトをインストールするときに Target Path(ターゲットパス) を選択して、アドオンをインストールできます。Blenderは、Preferences(プリファレンス) で選択されたディレクトリの下に新しくインストールされたアドオンをコピーします。

Internet Access

If the add-on needs to use internet, it should check for the (read-only) property This option is controlled by Preferences, which can be overriding via command-line (--offline-mode / --online-mode).

For better error messages, you can check also for, to determine whether users can turn Allow Online Access on the preferences, or not.

Blender itself doesn't block internet access based on this setting. It is up to the add-ons to respect it.

Bundle Dependencies

For add-ons to be bundled as extensions, they must be self-contained. That means they must come with all its dependencies. In particular 3rd party Python modules.

There are a few options for this:

Bundle with Python Wheels.

This is the recommended way to bundle dependencies.

Bundle other add-ons together.

This is recommended if an add-on depends on another add-on.

Make sure that both the individual and the combined add-on check for already registered types (Operators, Panels, ...). This avoids duplication of operators and panels on the interface if the add-ons are installed as a bundle and individually.

Bundle with Vendorize

This can be used as a way to bundle a pure Python dependencies as a sub-module.

This has the advantage of avoiding version conflicts although it requires some work to setup each package.

Legacy vs Extension Add-ons

With the introduction of Extensions in Blender 4.2, the old way of creating add-ons is considered deprecated. While the changes are rather small they impact existing add-ons.

In order to allow a smooth transition process, the so-called legacy add-ons will continue to be supported by Blender. They can be installed via Install legacy Add-on button in the User Preferences.

All add-on maintainers are urged to convert the add-ons they want to share, so they are future proof and can support features like updating from the extensions platform.

Converting a Legacy Add-on into an Extension

  1. Create a manifest file.

  2. Remove the bl_info information (this is now in the manifest).

  3. Replace all references to the module name to __package__.

  4. Make all module imports to use relative import.

  5. Use wheels to pack your external Python dependencies.

  6. Remember to test it thoroughly.


For testing it is import to install the extension from disk and check if everything is working well. This will get you as close to the final experience as possible.

Extensions and Namespace

The legacy add-ons would use their module name to access the preferences. This could lead to a name clash when extensions with the same name (from different repositories) would be installed. To prevent this conflict, the repository name is now part of the namespace.

For example, now instead of kitsu the module name would be bl_ext.{repository_module_name}.kitsu instead.

This has a few implications for preferences and module imports.

User Preferences and __package__

Add-ons can define their own preferences which use the package name as an identifier. This can be accessed using __package__.

This was already supported in the legacy add-ons, but not reinforced. As such this can break backward compatibility.


class KitsuPreferences(bpy.types.AddonPreferences):
    bl_idname = "kitsu"
    # ... snip ...

# Access with:
addon_prefs = bpy.context.preferences.addons["kitsu"]


class KitsuPreferences(bpy.types.AddonPreferences):
    bl_idname = __package__
    # ... snip ...

# Access with:
addon_prefs = bpy.context.preferences.addons[__package__]

An add-on that defines sub-packages (sub-directories with their own file) that needs to use this identifier will have to import the top-level package using a relative import.

from .. import __package__ as base_package

Then base_package can be used instead of __package__. The .. imports relative to the packages parent, sub-sub-packages must use ... and so on.


  • The value of __package__ will vary between systems so it should never be replaced with a literal string.

  • Extensions must not manipulate the value of __package__ as this may cause unexpected behavior or errors.

Relative Imports


from kitsu import utils


from . import utils

Importing packages within the add-on module need to use relative paths. This is a standard Python feature and only applicable for add-ons that have multiple folders.

This was already supported in the legacy add-ons, but not reinforced. As such this can break backward compatibility.