blender-addon-development

1# Add-on (Extension) Development
2 
3The execution model is in `blender-core`. Start from `assets/addon_template/` (validated, built, and registered in CI): `blender_manifest.toml`, `__init__.py`, `operators.py`, `ui.py`.
4 
5## Procedure
61. Copy the template, then set `id` (lowercase_underscores, permanent), `name`, `tagline` (no trailing period, ≤ 64 chars), `maintainer`, `version` (semver), `license` (SPDX, GPL-3.0-or-later for code using bpy), and `blender_version_min = "4.2.0"` or higher if you use newer APIs (e.g. `"5.2.0"` for the GN `properties.inputs` API).
72. Write classes with the prefix convention `MYTOOL_OT_x` (operator), `_PT_` (panel), `_MT_` (menu), `_PG_` (property group), `_AP_` (preferences), `_UL_` (UI list). `bl_idname` for operators is `my_tool.verb_noun`.
83. Validate and build:
9   ```
10   blender --command extension validate ./my_tool
11   blender --command extension build --source-dir ./my_tool --output-dir ./dist
12   blender --command extension install-file -r user_default -e ./dist/my_tool-1.0.0.zip
13   ```
144. Test headless: register the package in-process, call operators with `temp_override`, and assert on data (see `tests/test_addon.py` in this repo).
15 
16## Rules (extension-era, 5.x)
17- **Relative imports only** (`from . import ops`). The package name is decided by Blender, so preferences use `bl_idname = __package__`.
18- No `bl_info` (it's ignored for extensions). Everything goes in the manifest.
19…