zionad2017 skills ChatGPT

zionad2017

blender5

2022zionad

blender5

deepdeep

<https://chatgpt.com/plugins/plugins_6ac28411f4d48191bf896016ab68bbd3?utm_source=chatgpt.com>

<https://chatgpt.com/plugins/plugins_6ac28411f4d48191bf896016ab68bbd3?utm_source=chatgpt.com>

---
name: blender5-addon
version: 1.1.0
description: Blender 5.x以降専用アドオンの要件定義、設計、生成、修正、安定化を行う汎用ワークフロー。共通UI配置と安定化ルールを固定します。
---

# Blender 5.x以降専用アドオン作成支援

## 01. 最重要：Blender 5.x以降専用
- 対象は Blender 5.0以降だけ。
- Blender 4.x、3.x以前への互換実装を勝手に追加しない。
- `bl_info["blender"]` は原則 `(5, 0, 0)` 以上。
- Blender 4.x向けの古いAPI/UI実装を混在させない。
- ユーザーが「5以降専用」と指定した場合、この条件を最優先する。

## 02. 作成前の要件整理
コードを書く前に、必要に応じて以下を整理する。
- アドオン表示名
- アドオンファイル名
- Nパネル表示名
- 内部ID
- Prefix
- Collection名
- Object名
- Material名
- 初期値
- UI項目
- Create
- 更新
- Detach
- リンク
- 初期値書き出し
- Remove
- 自動Nパネル
- Material Preview

重要な仕様を勝手に省略・削除しない。

## 03. USER CONFIGをコード上部へ集約
コード上部に以下をまとめる。
1. `bl_info`
2. 日付・バージョン
3. import
4. USER CONFIG
5. ADDON_TITLE / 内部ID
6. PREFIX_VAL / PREFIX
7. 初期設定
8. PropertyGroup
9. 生成・更新関数
10. Operators
11. Panels
12. register/unregister

### Prefix変更耐性【固定ルール】
Prefixは一か所を変更すれば全体に反映される構造にする。

- `PREFIX_VAL` を基準値として使用する。
- 実際のBlender内部ID、Object名、Collection名、Material名等を必要に応じてPrefixから生成する。
- Prefix文字列をコード各所へハードコードしない。
- ユーザーが `PREFIX_VAL` を手動変更しても、既存の生成・更新・削除・Detach判定が破綻しない設計にする。
- Prefixの大文字・小文字変換を必要な箇所で統一する。
- Prefixを変更した際に、アドオンが自分の生成物を識別できなくなる構造を避ける。
- 名前だけに依存せず、必要に応じてカスタムプロパティ等も識別情報として利用する。

## 04. 初期設定
初期設定はコード上部に項目別に配置する。
最低限：
- Collection名
- Object名
- Material名
- 位置XYZ
- 回転XYZ
- スケールXYZ
- サイズ/半径/厚さ
- 色
- 透明度
- Roughness
- Metallic
- 表示/非表示
- 線幅
- テキストサイズ
- テキスト位置XYZ
- その他固有値

透明度は `0.0～1.0`。色関連値も適切な範囲に制限する。

## 05. UI値のリアルタイム反映
UIで変更した値は可能な限りリアルタイムで生成物へ反映する。
更新コールバックを使う場合は無限更新ループを防ぐ。
更新対象はアドオン管理下のオブジェクトだけに限定する。

## 06. Create
Createで生成したObject/Collection/Materialを安全に追跡する。
- 専用Collection
- Prefix
- カスタムプロパティ
等を組み合わせて識別する。
複数回Createした場合の重複も明示的に扱う。

## 07. Detach【固定ルール】
DetachしたObjectは、以後アドオン設定変更の影響を受けない。
- 色変更が伝播しない
- Material変更が伝播しない
- 形状変更が伝播しない
- 更新処理対象から外す
- Remove処理で誤削除しない
- 通常のBlender Objectとして使用可能にする

必要ならMaterialを独立化し、アドオン管理用の識別情報を解除する。

## 08. 有効化時の自動Nパネル＋Material Preview【固定ルール】
ユーザーがアドオンを有効化したとき、可能な範囲で：
1. 対象の3D Viewを探す
2. Nパネルを開く
3. 対象アドオンのタブを表示
4. ViewportをMaterial Previewへ切り替える

ただし、登録時点で適切なVIEW_3D contextが存在しない場合に無理なContext操作をしてエラーにしない。
必要なら安全な遅延処理・timer等を使用し、解除時にtimer/handlerを確実に解除する。

## 09. パネル順序【固定ルール】
Panelの並びは、下から見て次の順序を原則とする。

### 最下段
**Add-on Remove / アドオン削除**

### 下から2番目
**初期値書き出し / 初期設定コピー**

### 下から3番目
**リンクパネル**

重要：ユーザーが明示的に別順序を指定しない限り、この配置を変更しない。

つまり上から見た最終部分は原則：
- リンク
- 初期値書き出し
- Remove

となる。

Blender Panelの並びは `bl_order`、`bl_parent_id`、各Panelの構造等を考慮して、実際のBlender 5.x UIで意図した順序になるよう設計する。単にコードの記述順だけを根拠に「正しく並ぶ」と判断しない。

## 10. リンクパネル【固定ルール】
リンクパネルは原則「下から3番目」。
- タイトルとURLを一元管理
- 空URLを許容
- 空URLクリックでエラーにしない
- 外部ブラウザ起動は安全に行う
- リンク定義をコード各所へ分散しない

## 11. 初期値書き出しパネル【固定ルール】
下から2番目。
ボタンで現在の初期設定をBlender Text Editorへ書き出せるようにする。

出力はコピーしてPythonコードへ戻せる形式を優先する。
可能なら：
- `PREFIX_VAL = ...`
- Collection名
- Object名
- Material名
- 各数値
- 各色
等をコード形式で出力する。

「現在の設定値」と「コード上の初期値」のどちらを書き出すかはUI上で明確にする。

## 12. Removeパネル【固定ルール】
最下段。
Removeでは以下を安全に処理する。
- アドオン登録解除
- PropertyGroup解除
- Handler/Timer解除
- 必要なら管理対象Collection/Object削除
- Detach済みObjectは削除しない
- クラス二重解除を防止
- `unregister()`との二重実行を防止

Blenderのアドオン状態を壊すような無条件の全削除を行わない。

## 13. register / unregister
クラス一覧を一元管理。
登録順と解除順を整合させる。
Scene等に追加したPropertyは存在確認して安全に削除。
Timer/Handler/Msgbus等を追加した場合は解除時に片付ける。

## 14. 既存コードの修正
既存コードがある場合：
1. 既存機能を列挙
2. UI構造を確認
3. Operatorを確認
4. PropertyGroupを確認
5. Object/Collection/Material管理を確認
6. register/unregisterを確認
7. Blender 5.x非対応箇所を特定
8. 最小限の修正
9. 固定共通仕様を追加
10. 既存機能が維持されているか確認

表示されるが操作できない場合は、まずOperator、Property、Context、Panel、登録状態を重点確認する。

## 15. Blender 5.x検証チェック
コード提示前に最低限：
- `bl_info` が5.x以降
- Blender 4.x前提コードなし
- Property定義が妥当
- Operatorが登録される
- Panelが登録される
- ボタンがOperatorを正しく呼ぶ
- UI更新が循環しない
- Materialが正しく生成される
- Collection/Objectリンクが正しい
- Prefix変更で識別が壊れない
- Detach後に更新が伝播しない
- Nパネル自動表示処理が安全
- Material Preview切替が安全
- Panelの最下部3項目が固定順序
- Removeが二重解除にならない

## 16. 出力方針
- 「プロンプトを作って」→プロンプトを作る。勝手にコードを書かない。
- 「要件整理」→要件を整理する。
- 「アドオンを作って」→完成コードを作る。
- 「修正して」→既存機能を保持した修正版を作る。
- 修正時は、何を変えたかを明示する。
- 重要な仕様を削除した場合は必ず説明する。

## 17. 絶対禁止
- Blender 4.x互換を勝手に追加
- 既存機能の勝手な削除
- Prefixの分散定義
- Detach後への設定伝播
- Contextがない状態での無理なUI操作
- Removeの二重登録/二重解除
- パネル順序の勝手な変更
- 「表示できる」だけで操作可能と判断すること

## 目的
Blender 5.x以降だけを対象とし、ユーザーが繰り返し利用できる安定した汎用アドオン基盤を維持する。