Розширення

Add-ons дозволяють вам розширити функціональність Blender використовуючи Python. Більшість часу ви можете отримати розширення як частину Extensions системи.

Порада

Якщо Розширення не активується при увімкненні, то перевірте вікно консолі Console window на будь-які помилки, що могли трапитися.

Доступ до Мережі

Якщо розширенню треба використовувати інтернет, треба перевірити (тільки читання) властивість``bpy.app.online_access``. Ця опція контролюється у Вподобаннях, що можна перезаписати за допомогою командного рядка (--offline-mode / --online-mode).

Для кращих повідомлень помилок, ви також можете переглянути bpy.app.online_access_override, щоб визначити чи користувач може увімкнути Дозволити Доступ До Мережі в налаштуваннях чи ні.

Примітка

Розширення які слідують за цим налаштуванням, будуть робити з’єднання до інтернету тільки коли увімкнено. Однак, Blender не може зупинити розширення сторонніх розробників від порушення цього правила.

Спакувати Залежності

Для звичайних розширень, щоб спакувати їх в повноцінне розширення, вони повинні бути автономними. Це означає, що вони мають йти з усіма своїми залежностями. В конкретному Python модулі від сторонніх розробників.

Для цього є пару опцій:

Спакувати з Python Wheels.

Це рекомендований шлях для пакування залежностей.

Спакувати інші розширення разом.

Це є рекомендовано якщо, звичайне розширення залежить від іншого звичайного розширення.

Переконайтесь, що обидва індивідуальне та поєднане розширення перевіряє вже зареєстровані типи (Оператори, Панелі, …). Це запобігає дублікації для операторів та панелей в інтерфейсі, якщо розширення встановлено як пакунок чи індивідуально.

Спакувати з Vendorize

Це може бути використано як шлях, щоб спакувати Python залежності як під-модулі.

Це має перевагу для оминання конфліктів версій, також воно потребує деякої роботи щоб встановити кожний пакунок.

Локальне Сховище

Розширення не повинні припускати свою власну директорію до якої користувач має записувати файли, тому, що це може бути не випадок для «Системних» сховищ. Записування файлів до директорії розширення також має свої мінуси, коли буде оновлення розширення, всі файли видаляться.

Розширення яким потрібна своя власна директорія, повинні використовувати функцію утиліти яка для цього призначена:

extension_directory = bpy.utils.extension_path_user(__package__, path="", create=True)

Якщо ви бажаєте створити під-директорії, це можна зробити з аргументом path.

Ця директорія буде зберігатися між оновленнями, але буде вилучена якщо розширення буде деінстальовано.

Застарілі проти Розширення Звичайних Розширень

З представленням Розширень в Blender 4.2, старий шлях створення звичайних розширень рахується застарілим. Коли зазвичай зміни дуже маленькі, але вони впливають на наявні звичайні розширення.

Щоб дозволити плавний процес переходу, так звані застарілі розширення будуть підтримуватись Blender. Вони можуть бути встановлені за допомогою Install legacy Add-on кнопки в Налаштуваннях Користувача.

Всім підтримувачам розширення потрібно конвертувати розширення якими вони хочуть поділитися, щоб вони стали незалежними від майбутніх змін, та могли підтримувати такі функції як оновлення з платформи.

Конвертування Застарілого Розширення в Повноцінне Розширення

  1. Створити файл маніфесту.

  2. Вилучити bl_info інформацію (це тепер в маніфесті).

  3. Замінити всі посилання до назви модуля до __package__.

  4. Зробити так, щоб всі імпорти модулю використовували відносний імпорт.

  5. Використовувати wheels , щоб спакувати всі додаткові Python залежності.

  6. Не забудьте протестувати їх ретельно.

Примітка

Для тестування це важливо встановити розширення з диску та перевірити чи все працює добре. Це, як можливо, перенесе вас ближче до реального досвіду.

Розширення та Простір Назви

Застарілі розширення будуть використовувати свої назви, щоб мати доступ до налаштувань. Це може призвести до протиріччя назв, коли розширення з однаковою назвою (з іншого сховища) буде встановлено. Щоб запобігти цьому конфлікту, назва репозиторію тепер є частиною простору назви.

Наприклад, зараз замість kitsu назва модулю буде натомість``bl_ext.{repository_module_name}.kitsu``.

Це має мало наслідків для налаштувань та імпортів модулю.

Налаштування Користувача та __package__

Розширення можуть визначати свої власні налаштування, які використовують назву пакунку як ідентифікатор. Сюди можна отримати доступ використовуючи __package__.

Це вже підтримувалось в застарілих розширеннях, але не піднято. Так як це може зламати зворотну сумісність.

Раніше:

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__]
Під-пакунки

Звичайне розширення яке визначає під-пакунки (під-директорії з їх власним __init__.py файлом), що мають використовувати ідентифікатор, треба імпортувати пакунок найвищого рівня використовуючи відносний імпорт.

from .. import __package__ as base_package

Потім base_package може бути використаний, натомість від __package__. Імпорти ..``відносні до пакунків предка, під-пакунки мають використовувати ``... і так далі.

Примітка

  • Значення __package__ буде відрізнятись між системами, тому воно ніколи не повинно бути замінено буквальним рядком.

  • Розширення не повинні маніпулювати значенням __package__ , так як це може призвести до неочікуваних поведінок або помилок.

Відносні Імпорти

раніше:

from kitsu import utils

зараз:

from . import utils

Імпортування пакунків з модуля звичайного розширення має використовувати відносний шлях. Це є стандартною функцією Python та тільки застосовується для звичайних розширень які мають багато директорій.

Це вже підтримувалось в застарілих розширеннях, але не піднято. Так як це може зламати зворотну сумісність.