CameraListアドオン開発 メモ

あくまでメモ

自分用のアドオン開発用Twitterアカウントで呟いていた内容をまとめ

8/9

アドオン追加時に作成されるカスタムプロパティについて考察

（プルダウン選択式のプログラムについて）

8/10

アドオン追加時に作成されるカスタムプロパティについて考察

（プルダウン選択式のプログラムについて）

8/11

3DViewの視点移動・切り替えについて考察

①カメラのマトリックス（行列）、レンズ（mm）の情報を取得 ↓ 変数に代入・保管 ②ビューをするビューポートを取得 ↓ 取得したビューポート上のマトリックスを①のデータで上書き

メリット カメラを選択する必要ないので、編集モードでVertexなどを選択した状態でView Cameraができる
デメリット アニメーションには対応していない あくまで、取得段階のカメラの位置からマトリックスを導き出す　

ビューポートを取得するもhttp://context.space_data をUI上で入力すれば自動的にcontextはビューポート上実行されるので、現段階でビューポートかどうかを確認するためのチェッカー機能は不要

 開発上問題になるのはPythonコンソール上で指定するのが難しい
（画面分割によってエリアのIDが変更になるみたい）

 アドオン上はcontextでアクティブなエリアを取得できるため問題なし
（コマンドラインで実行を行うとエラーが発生するとおもう）

8/16

3DViewの視点移動・切り替えについて考察

カメラ上の中心点をビューポートの中心点に変更するときのことをいろいろと考えてたけど返って複雑に考えている気がするのでいったん脳内を空にする

カメラの進行方向に円を考えれば中心点が導き出せるところまでは脳みそ動いた。

さて、円の大きさはどうする？

 そもそも中心点が定まらなければ円を描画することは不可能なわけで、一番最初のケースは
「ワールド上の原点＝視野の中心点」だったからカメラの位置情報を単純に倍した円を描画すればよかったんだけど

 こんなことしなくても
「カメラ登録」時にカメラビューから視野情報を取得することはできるんだけど、そうするとアニメーションがついたカメラには適応できない

 あと、カメラ単体の座標を使用すると他オブジェクトとペアレントされてると計算が絶対狂うから注意だな

8/17

3DViewの視点移動・切り替えについて考察

8/21

3DViewの視点移動・切り替えについて考察

 もっと単純に考えればいいい
Blender側のAPIで距離は設定できる

8/21～

Numpyを使って極座標変換で中心点の座標を求める仕組みを作ってます。

詳しい方ならすぐに実装できそうな機能ですが、少々苦戦してます。

（Numpyわからんし、三角関数を学生に戻ったつもりで勉強しなおしています）