Files

T

ewdernaandClaude Opus 5 cd6a94f4f4 PHY: 座標を親からの相対に統一し、回転中心パラメータを廃止

クラスター単位の移動・回転を親ノード1つの書き換えで済ませるため、
各ノードは親から見た変換 (x, y, rotation) を持つことにし、絶対座標は
保持しないことにした。回転軸は常に自分自身のローカル原点に固定し、
KLE の rotation_x / rotation_y に相当するパラメータは持たない。

あわせてスナップの基準系をローカル座標系と明記し、親の変換を受けない
w, h を Transform から分離した。KLE出力時の行のまとまりは未解決の問い
として未確認事項に立てた。

Journal: journal/2026-09-18-phy-coordinate-model.md

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MdLT5x5ka5y6CaWLeE3EKb

2026-09-18 08:44:22 +09:00

4.8 KiB

Raw Blame History

PHY座標モデル: 相対座標 + 回転中心パラメータなし

結論

各ノードは親から見た変換 (x, y, rotation) を持つ。絶対座標は保持しない
回転中心のパラメータは持たない。回転軸は常に自分自身のローカル原点
Key も Cluster も同じ変換を持つ。per-key回転のためにクラスターを作る必要はない
スナップ(0.25U / 15度)はローカル座標系での話
w, h は Transform から分離する(親の変換を受けないため)

案の比較

座標系

案	利点	欠点
絶対座標	KLEとの往復が素直。保存値がそのまま最終位置	クラスターのpositionと二重管理になる。階層が実質的に選択範囲の記録にしかならない
相対座標(採用)	クラスターの移動・回転が親1ノードの書き換えで済む	畳む処理が要る。KLE再インポート時に逆変換で端数が出る
相対+絶対を併記	読み出しに変換が不要	二重管理の問題がそのまま残る

回転中心

案	利点	欠点
ノードごとに回転中心を持つ(KLE方式)	任意のピボットを保存できる	グループ回転で全キーが同じrx/ryを共有する必要がある。移動のたびに全キー更新
自分の原点に固定(採用)	パラメータが消え、式が Translate·Rotate だけになる	共通ピボットを残したい場合はクラスターを作る必要がある

根拠

絶対座標を採らない理由

キーが絶対座標を持つ状態でクラスターにも position があると、同じ情報が2箇所に存在する。クラスターを回すときにクラスターの角度を書き換えるのか配下の全キーを再計算するのかが定まらず、片方だけ更新されたファイルが生まれる。元の保存形式でクラスターの position の意味が書かれていなかったのは、この行き場のなさが未解決のままだったためと思われる。

また絶対座標を正本にすると、入れ子構造は「選択範囲の記録」以上の意味を持たない。それならフラット配列 + clusterId の方が構造として正直で、階層クラスターの要求と噛み合わない。

畳んで絶対座標にする処理は KLE出力・PCB出力のためにどのみち必要。絶対座標を正本にしてもクラスター操作のために逆方向が要るので、結局両方向を書くことになる。

per-key回転とクラスター数

平面上の剛体配置の自由度は、位置2 + 向き1 = 3。ノードが (x, y, rotation) を持つならちょうど3自由度なので、どんな配置でも全キーを同じ親の直下に並べて表現できる。キーごとに角度が違ってもクラスターは増えない。

当初 Alice を per-key回転の例として挙げたが、Alice は左右のアルファ部がそれぞれ一体で傾いた 2クラスターであり、per-key回転の例ではない(ユーザーによる訂正)。代わりに GRIN系の指摘があったが、実際のジオメトリを確認していないため保留。上の自由度の議論は形状に依存しないので、結論は変わらない。

ピボットは編集操作の状態であってデータではない

ピボットは「θを変えたとき何が動かないか」を決めているだけで、結果として得られる配置は (x, y, rotation) で表現できる。扇状配置のような共通ピボットは、エディタ側の操作として結果の数値を焼き込めばよい。後から開き具合を編集し直したい場合だけ、その扇をクラスターにする(クラスター原点 = ピボット)。ピボットを永続データとして持つと、KLE の rotation_x / rotation_y と同じものになる。

row/col への影響

放射状に並べるとrowの概念が崩れるのではないかという懸念があったが、 PHYレイヤーはrow/colを扱わないため問題にならない。 matrix情報は任意の付加情報で、正本はIDX/ELC側にある。幾何がmatrixに制約されることはない。 KLEでrowが崩壊するのは物理配置から論理的な行を推定しているためで、その推定をやめることがレイヤー分離の目的そのもの。

捨てた案

相対座標を正本にしつつ絶対座標をキャッシュとして併記する。二重管理の問題が再発する

未決のまま残したもの

KLE出力時に行ごとにまとめたいという要求。方法未検討のため未確認事項として残した
Key.profile を実体で持つか参照IDで持つか。今回の決定の範囲外なので元のまま Profile 実体を残した

4.8 KiB Raw Blame History