NDMFに対応させる＆導入方法の変更

Rerigferl commented 1 year ago

現状何ができるのかさっぱりなので調査が必要

Azukimochi commented 1 year ago

とりあえず方針としていま考えてる範囲では

そして、他のMA依存ツールの方針に右に習えで1.X.0のマイナーバージョンアップで対応する予定でいます。

Rerigferl commented 11 months ago

EditorWindowを用いた手動生成がそろそろ邪魔になってきたので、

ウィンドウでのアニメーション生成はやめる
代わりにマーカー代わりのLightLimitChangerSettingsコンポーネントを付けたプレハブを置いて、コンポーネントの設定値をウィンドウの設定値に合わせる
ウィンドウは互換性の為に残すことにして、新規利用者にはできるかぎりプレハブを直接D&Dしてもらう方向に促す

って感じで大丈夫でしょうか

Azukimochi commented 11 months ago

これは賛成です。ついでにアニメーション保存パスの指定もやめて、実行時生成に割り切ってもいいかなと。同一保存パスでも実行時生成なら問題にならないのは現時点でも変わらないので

これはちょっと案が複数あって、大きく変える案としては2つ。共通して言えることはとりあえずGUIは設定変更方法として提供は継続するのと、互換性のために上部メニューから起動できることは変わらない

1.コンテキストメニュー導入＆GUI設定アバターへの導入：右クリックコンテキストメニューから行う。
設定変更：生えたPrefabのコンポーネントのボタンからGUIを立ち上げ個別に設定を行う
3.アバター外設置Prefab管理＆GUI設定アバターへの導入：アバター外にプリセットPrefabを設置し、設定対象のアバターリストにDrag＆Dropで設定することで実行時に適用するグループ管理方式（設定の部分個別化＆共通化）
設定変更：Prefab最上部のコンポーネントにGUI起動メニューを設置

ウインドウの規定値でというのは対象シェーダーの兼ね合いからアバター個別に設定できるものが望ましいと考えています。

互換性の部分は賛成です。プレハブD&D方式に関しては2.の提供方法の変更を参照

Rerigferl commented 11 months ago

（GUIがEditorWindowを指しているものとして話を進めるのですが）設定変更にGUIを介すのはやや微妙な気がしていて、

の２点が気がかりなので、GUIは本当にただ互換性の為にあるものにしてしまいたいなぁと

プレハブの起き方に関してはどっちも良さそうな気がしますが、何でもかんでも雑に複製してしまう人の存在だったり、互換性を考えると、１番のプレハブを各アバターに生やすタイプが良さそうかなって感じです

Azukimochi commented 11 months ago

（その認識でした🙏）

単純にユーザー体験が～　これ制作構想として複数アバターを手入れすることを考慮していなかった（追加機能で再生成を考えていなかった）ので、今となっては確かにそうだなぁと思ってます正直
おそらくMACの設計思想から外れてしまいそう　ここに関しては導入をワンクリック化orPrefabぽん置き化の必要性はありますね

個人的にはプレハブはやした上で2.のグループ管理で実行時にアバター内部にPrefab生成が複数アバターの一括管理できていいかなとは思うので何個かUI案試作して練りましょう

Azukimochi / LightLimitChangerForMA