feat: VRChat以外のアバター形式に対応する

[kaikoga]

欲しいもの

ndmfからVRCSDKへの依存を取り除く作業を行いたいと考えています。
具体的には、以下の種類のアバターを非破壊編集できるようにしたいです。

• VRM0 / VRM1 (UniVRM)
• AssetBundleをビルドする系の、VRChat以外のVRSNS用アバターフォーマット（あればここに書く）

このうち、VRM0 / VRM1対応については Modular Avatar ( Discussions: bdunderscore/modular-avatar#467 ) と Avatar Optimizer ( Discussions: anatawa12/AvatarOptimizer#522 ) の一部の既存コンポーネントへの対応、更にVRM特有の問題を解消する追加のndmfライブラリを開発をする上で、ndmf側の対応が必要です。

努力目標

UniVRMの最低動作環境であるUnity 2021と、ndmfが現在サポートしているUnity 2019の、いずれか低い方のバージョンで動くこと。
それ未満のUnityバージョンは需要次第

[kaikoga]

タスク

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

• "com.vrchat.avatars" に対して Version Define NDMF_VRCSDK3_AVATARS を追加する
• VRCSDKのPublic APIフックを外す
• VRCAvatarDescriptor を使っているところを外す
  • AvatarRootの判定 ref: feat: Expose some avatar root APIs #34

また、ndmfがVRCSDK経由で依存しているDLLを読み込むためのUPMパッケージが必要ですが、これは既にあります https://github.com/kaikoga/ndmf-deps

[kaikoga]

議論の余地があること

Unityの動作保証バージョン

VRCSDKは近いうちにUnity 2022に上がる見込みですがが、ndmfが追従を急ぐ必要はないように思います。

• ndmf自体が最新のUnityの機能に依存したいみたいなことは起きないと考えています。
  • 最新のUnityの機能に対応した実装が入ることはあると思います。この場合、条件コンパイルを行うことになります。
  • 例えば UnityEditor.Experimental.SceneManagement みたいなやつです
• 例えば「Unity 2021でも使えるndmfのfork」の発生を避けるべきだと考えます。

[kaikoga]

議論の余地があること

ndmfにおけるアバターの表現をどうする？

ndmf（およびndmfを利用するライブラリ）が「アバター自体」をプログラム中で表現する場合、VRCAvatarDescriptorが使われていることが多い。
VRCSDKへの依存を外すためには、他の型でアバター自体を表現する必要がある。
アバター自体への参照はプラットフォーム依存のある頻出処理なので、ndmfで吸収して、共通のやり方を提供することが望ましい。

• アバターはVRCAvatarDescriptorで指し示す
  • pros: ndmf利用ライブラリのデファクト
  • cons: VRCSDKに依存する
• アバターはTransformで指し示す
  • pros: ndmfの現状
  • pros: ソースコード上でアバターなのかボーンなのかがわかりにくい
• plain C# wrapper classとしてAvatarRoot型を定義する
  • pros: ソースコード上でアバターであることがわかりやすくなる
  • cons: コンポーネントではなくなるため、コンポーネントであることを期待する既存のコードが動かなくなる

Transformで指し示すか、AvatarRoot型を定義するのが良いと思います。
（Transformで進めても大きな問題はないと思いますが、念の為確認させてください）

[bdunderscore]

これについては「BuildContext＝アバターを指すもの」と考えてるけど、NDMFやMAの内部実装に関してはBuildContextを生やす前から実装して切り替えてないものが多いです。BuildContextには環境に依存しないものと共に、各プラットフォームに合わせたVRCAvatarDescriptorに変わるものへのアクセスを公開すればいいのではないかと思います。

[kaikoga]

自分も最初はBuildContextで取り回すのが良いのでは、と思ったものの、MAのFirstPersonVisibleEditorでVisibleHeadAccessoryProcessorを使っているところの処理に迷って一度は断念しています。

これについては new BuildContext(parsedRootObject, null) で置き換えるか、Validatorを分離すれば大丈夫なように見ています。インスペクタ拡張から呼び出すユースケースを考えると、いくつかの初期化処理は省略できるような気もしますが、最適化の話であって処理的に不都合はなさそうです。

ということで、「BuildContext＝アバターを指すもの」という方針を取ることに異論はありません。

[kaikoga]

議論の余地があること

AvatarRootの判定

現在、複数のクラスにAvatarRootの判定に関するメソッドが生えている（MiscHelpers、Extensions）が、ここのロジックにプラットフォームへの依存が含まれるため、RuntimeUtilに集約したいです。
（一歩進めて、同一の機能を提供する他のメソッドは [Obsolete] か internal としたいです）

[kaikoga]

[Obsolete] 化は将来的なメジャーバージョンアップを前提とするため、RuntimeUtilへの集約まででいったん止めてあります。

[bdunderscore]

今後のメンテを考えて、プラットホームに依存しないコンポーネントや機能のユニットテストをVRCSDKなしでCIで回したいと考えています。今後絶対にうっかり壊してしまう自信があるのでマージの必須条件と言ってもいいレベルですね。

CIの設定は管理者権限が必要そうなのでこちらでしますが、ユニットテストを編成するのは任せたいところです。

[kaikoga]

ありがとうございます。
作業方針について大筋の合意が取れたと思うので、Issue化した上で残りの実装を進めたいと思います。

Issue: #49