Add MA Merge VRM0+1 FirstPerson

[kaikoga]

Discussion: https://github.com/bdunderscore/modular-avatar/discussions/467 Merge base PR first: UniVRM components support #569

This PR introduces MA Merge VRM0+1 FirstPerson component, which adds FirstPerson settings to VRMFirstPerson for VRM0 / VRM10Object for VRM1, respectively. This component supports both VRM0 and VRM1 because the data structure is very similar. This component does nothing when the target avatar is not VRM0 or VRM1.

I think there is nothing specific to this component that requires localization. Perhaps there could be some warning like "This component is ignored; supports VRM0 or VRM1 avatar only", but many other components that targets VRCSDK only have similar issue.

I have not yet added documents. Merging this PR reveals UniVRM support to end users, so documentation would block the next release once this PR is merged. I don't know yet where to add documents. (It would be under docs~/, but I worry that throwing VRM specific components into the Component reference section makes little sense to VRC users, when the entire components list is even more growing).

[bdunderscore]

There should probably be a separate docs section for VRM components. We could set up something where VRM components are in a beta state, requiring a special define until they're in a usable state.

Probably I won't be able to merge this until 1.10.

[kaikoga]

requiring a special define

Fair point. Should every #if MA_VRMx be #if MA_VRMx && MA_VRM_BETA (because if we would want to hide runtime components for users without opt-in, then the components would be wrapped in #if MA_VRM_BETA and become missing) then?

[kaikoga]

Another point of view: does VRM support deserve dedicated asmdefs, which would probably require major code reorganization?

[kaikoga]

Memo before rebase; maybe better name: VRM0+1 First Person Renderers ?

[bdunderscore]

@kaikoga お待たせしました。このコンポーネントについてですが、 Visible Head Accessoryとかぶるところが多いようですが、何かと汎用的な定義にできないでしょうか？つまり、どのプラットホームでも一人視点の可視性を設定できるコンポーネント・・・

[kaikoga]

@bdunderscore お返事遅くなりすみません。

#601 #602 のコメント内容を踏まえると、 MA としてはクロスプラットフォームな定義が可能なコンポーネントはなるべくそのようにしたいとお見受けしました。

#601 #602 の内容をクロスプラットフォームにすることで VRM 対応としてはできることが減ってしまい、また汎用的な定義を発明するには時間がかかると思うので、今浮いている PR は #569 （と bdunderscore/ndmf#71 ）まで取り込んだ上で、以下のようにするのが良いと考えております。

• 個別の VRM 専用コンポーネントについては MA 本体への PR としてはいったん取り下げて、外部 ndmf プラグインとして提供する
• 別途、 Visible Head Accessory を VRM に対応する

こちらいかがでしょうか？

[bdunderscore]

VRM専用コンポーネントをMAに最終的に入れるかは別として、いったん別パッケージで仕様を固めておくのはありだと思います（実際、Resonite対応するとなると同じことを考えています） 特に、今回みたいにリリースが遅れたりする場合はＶＲＭの開発も止まっちゃうわけなので・・・

実際、今からＭＡを作り直すのなら、ＶＲＣ向けのプラットホーム限定コンポーネントは別パッケージにすると思います。

とりあえず NDMF 1.6.0 はプラットホームＡＰＩとビルドを実行するＵＩを追加する予定なので、それを土台に別の拡張を用意するのはありです。

[kaikoga]

コメント・レビューありがとうございます。

「一旦 MA 外部に VRM の生の仕様に近い拡張を作った上で、それと並行して #601 なども踏まえてクロスプラットフォームに設定できる何らかの概念を考える（可能ならコンバートを提供する）」が結果的に VRM コンポーネントを NDMF で扱えるようになるまでが一番早いと思うので、そうしようと思います。

#601 と #602 は外部の ndmf プラグインで引き取ることにして PR を close させていただきます。

特に、 VRM のメタデータを非破壊に編集するのであれば https://docs.kaikoga.net/ativ/ndmf/ativ_overwrite_vrm_meta みたいなのが必要だと思いますが、これが MA 本体に入るとは思えないので・・・