feat: VRMの非破壊編集に対応する

[kaikoga]

欲しいもの

ndmf をVRChat以外のアバター形式に対応させる (Discussions: bdunderscore/ndmf#39 ) に伴い、 VRM0 / VRM1のアバターを非破壊編集で作れるように管理したいと考えています。

Modular Avatarを用いてVRM0 / VRM1を作る際、現状ではManual Bake Avatar後に手動でVRMセットアップが必要であり、毎回手作業で行うのは大変なので、Modular AvatarがVRMのコンポーネントを扱えるようにしたいです。

as-is:

• Manual Bake Avatarする
• 手動でVRMのコンポーネントをセットアップする ← ここが破壊的編集
• Export to VRM0 / VRM1 する

to-be:

• VRMのコンポーネントをセットアップしたプレハブを用意する
• Manual Bake Avatarする
• そのまま Export to VRM0 / VRM1 する

現在はVRCSDKとUniVRMは共存できませんが、近いうちに共存できるようになるため、VRM対応のModular Avatarのforkではなく、本体へのVRM対応の組み込みを目指したいです。

努力目標

• UniVRMが動作するいずれかのバージョンのUnityに対応する
  • Unity 2021で動くと嬉しいけど、必須ではない
• VRCSDKとUniVRMが共存できない場合に備え、UPMに対応する（VPMパッケージはそのまま使えるはず）
• VRM0系 / VRM1系の両方に対応する
  • どちらかを削って楽になるタイプの作業ではないと思うし、作業者は自分になると思うので・・・

[kaikoga]

タスク

kaikoga#7 にある内容を本体に対してやる（このPR自体はPoCであり、また随時破壊されるので直接マージはしない）

• 必要な場所で#if UNITY_2021_2_OR_NEWER する
• "com.vrchat.avatars" に対して Version Define MA_VRCSDK3_AVATARS を追加する
• アバター本体への参照として VRCAvatarDescriptor を使っているところを可能な限り外す
• VRCSDKがないと動かないコンポーネントを MA_VRCSDK3_AVATARS で無効化する
• VRCSDKのコンポーネントへの参照を MA_VRCSDK3_AVATARS に押し込める

[kaikoga]

議論の余地があること

VRCSDKのデータ型をシリアライズしてるコンポーネントの扱い

• 例： MA Menu Installer みたいなやつ
• VRCSDKがない環境でプレハブを読み込むとシリアライズされたデータが破壊されるけど良い？

[bdunderscore]

Menu InstallerはそもそもVRCの使用に強く依存するものなのでコンポーネント単位の無効化でいいのではと思ったり

[bdunderscore]

（Missing扱いにするということ）

[kaikoga]

データの破壊についてはプレハブをVRCSDKのある環境とVRCSDKのない環境でやり取りする場合にしか問題にはならないので、そんなことをする人はいないよねという確認でした。

Missingにしたくない理由についてはほかで説明します。

[kaikoga]

議論の余地があること

VRCSDKがないと動かないコンポーネントの表示

• 例： MA PhysBone Blocker とか
• VRCSDKなしでもManual bake avatarが押せるようにする Ver. ndmf + MA1.8.0 + AAO1.5.1 kaikoga/modular-avatar#7 でやってるような感じで良いと思っています
  • 編集できるのであれば、編集を禁止するまででもないと思う

[bdunderscore]

PhysBone BlockerがあればPhysBoneもおそらくあるので、VRCSDKがなければどのみちMissingコンポーネントが発生すると予想・・・ならばPhysBone BlockerもMissingでいいのでは？

[kaikoga]

Missingにする代わりに何もしないコンポーネントに変換することで、いくつかの利点があると考えています。

• Missingなコンポーネントが刺さっているPrefabのVariantを作ることはできないため、Missingなコンポーネントが刺さっている販売衣装プレハブをベースに改変する際はUnpack Prefabが必要になりますが、これが不要になります。
• ダミーのコンポーネントからシリアライズされたデータを抽出することが可能となり、（実装するかはさておき）PhysBoneから他の揺れものコンポーネントへの自動変換を実装する道が開けます。

一方で、ダミーのコンポーネントに変換するデメリットは、以下が考えられそうです。

• ダミーのコンポーネントを記述する必要があるので、ソースコードのメンテナンス性が低下する。

これについては、ダミーのコンポーネントを #if MA_VRCSDK3_AVATARS の #else 側に定義することで、実際には見た目上も作業上もそこまで大変ではないです。

ということで、Missingにしたいという強い思いがあるのでなければ、ダミーのコンポーネントに変換したい気持ちがあります。

[bdunderscore]

それなら、読み込み→セーブでデータが破綻しない仕様が望ましいですね・・・（VRCSDKの型を使うものでは難しい

[kaikoga]

敢えてMissingにすることでデータの破壊を防ぐ（Missingが刺さっているプレハブは保存できないため）はMissingのメリットと言えますね。

別解として、「Missingなコンポーネントが刺さっているPrefabからMissingを抜いたVariantを作る」ことはシーン置きを経由することで一応可能なので、それを自動化するツールを（MA / ndmfとは無関係に）用意してそれを使ってもらうという案が浮かびました。
そのためだけにツールが要るのか、という感じはありますが。

[bdunderscore]

Merge Animatorについて

Merge Animatorの基本的な動作は、UnityのAnimatorを基準とするプラットホームならVRC以外にも適用されるのか？
現在は統合されるレイヤーをVRCSDKのenumで指定するため、VRCSDK以外の環境でもデータが破壊されない移行が必要そうですね。

[kaikoga]

VRMではUnityのAnimationを使わないので、VRMではMerge Animatorは無効化する想定です。
（VRM Animationという規格はありますが、UnityのAnimation相当のものを扱うことはできず、またアバターに組み込んで使うことを想定したものではありません。）

そして、UnityのAnimatorやAnimationを使うVRC以外のプラットフォームの対応が現時点で計画されていないことを考えると、Merge Animatorが何をすれば良いかを現時点では定義できない気がします。

現時点ではMerge AnimatorはVRC専用として、UnityのAnimatorを使うプラットフォームの対応を入れる際に改めてどうすべきか考えるのが良いと思います。

[kaikoga]

とりあえず、VRMに依存しない部分については進められそうなので、Issueを立てました。 #478
（VRMに依存する実装については引き続き方針を考える）

[kaikoga]

ModularにMergeしたいVRMの要素を調査中・・・

VRMMetaObject(VRM0) / VRM10Object (VRM1)

VRMにはメタデータを付与できる。メタデータを修正するためにはメタデータを格納するScriptableObjectを修正する必要があるが、これにサムネイル（VRM0 / VRM1）や表情・ビューポイント（VRM1）の情報も含むため、メタデータだけ変更したい際にScriptableObject丸ごと複製する必要があって大変である。

• 名前やバージョン、製作者名のみを上書きしたいケースがある
• ライセンスや許諾範囲のフィールドがある。商用可のアバター素体に商用不可の衣装を着せることにより、全体として商用不可のアバターを作成し得るが、これは許諾範囲の合成として表現できるか？
  • メタデータはあまり運用されてないので、そこまで必要性が高いわけではない
  • MA本体でやるほどでもないというのはあるかもしれない

SpringBone (VRM0)

• 揺れものはsecondary（という名前の）オブジェクトにVRMSpringBoneコンポーネントが刺さる形で定義するが、別にVRMSpringBoneが複数存在しても良いしsecondaryが複数存在してもいいので、そのまま合成するだけでVRMとして合法なセットアップになる
• コライダーも一緒（VRMSpringBoneColliderGroup）

SpringBone (VRM1)

• 揺れものはアーマチュアにVRM10SpringBoneJointを刺したものへの参照をVrm10Instanceに設定する形で定義する。揺れものの設定が多少あるけどSpringという名前の構造体にまとまってるのでSpring単位でVrm10Instance.SpringBone.Springs配列に追加すればOK
• コライダーはアーマチュアに刺したVRM10SpringBoneColliderGroupコンポーネントの配列が直接Vrm10Instance.SpringBone.ColliderGroupsに入る以外は一緒（やることも一緒）

Constraints (VRM1)

衣装プレハブにConstraintを設定した場合、Constraintが持つSkinnedMeshRendererのパス（オブジェクト参照）の書き換えが必要な気がする

BlendShape (VRM0) / Expression (VRM1)

VRMの表情関連は素体プレハブにしか置ける場所がないので、BlendShape / Expressionが持つSkinnedMeshRendererのパス（文字列参照）の書き換えはMAレイヤーでは発生しないはず（AAOでは発生する）

[bdunderscore]

SpringBoneに関してはExclude設定も必要そうですね・・・（PB Blockerと同様）

[kaikoga]

実際のところ、

• VRM0 ではRoot Boneを登録する方式、かつExcludeができないので、理想的な結合はできない
  • 無理やりマージすると親子関係のPhysBoneが指定されている状態になるが、これはVRM0の仕様上不正かもしれない？
• VRM1 ではInclude方式、かつ個別のボーンにVRM10SpringBoneJointコンポーネントを追加して指定する方式なので、普通にアーマチュアをマージするだけでPhysBoneのExcludeを設定した相当の挙動になる
  • 動作確認をしたわけではない
  • UniVRMではカスタムインスペクタから一括登録できる機能を用意することで設定の面倒さを緩和している模様
  • アーマチュアをマージした結果１つのボーンにVRM10SpringBoneJointが複数刺さった状態になると問題がありそうだが、MAの範囲では起きない？

仕様: vrm-c/vrm-specification#88

ので、PB Blocker相当コンポーネントの出番はいずれにせよなさそうに見ています。