docs: add a design sketch for a platform API

[bdunderscore]

No description provided.

[bdunderscore]

@kaikoga

[kaikoga]

読みました。この内容に基づいて Platform API の実装を開始できそうに見えています。

取り急ぎ：

• シーン上に存在するアバターの一覧を表示し、ビルドプロセスを開始する UI を表示するような NDMF のウィンドウが新設されるということですか？
• CommonAvatarInfo の形が定まるまでしばらくかかりそうに思いましたが、おそらく VRCAvatarDescriptor の定義に基づいた抽象的表現になると想像しています。（他に基準となれるアバター定義は存在しないと思います）
• VRM 対応の文脈で：
  • この定義だと、 VRM0 と VRM1 は別プラットフォーム扱いになりそうです。
  • VRM 用の BuildUI を実装できそうです。
  • VRM0/1 がどれだけ CommonAvatarInfo を利用できるかは未知数です。具体的な例を挙げると、 VRChat とはリップシンクの定義が大きく異なり（aiueoの５つしかない）、またライセンス関連の余分なフィールドを持っています。 CommonAvatarInfo が VRCAvatarDescriptor の定義に基づく場合、 CommonAvatarInfo を通した完全に自動化されたアバター定義の変換は期待できない可能性があります。ビルド時の同期と手動の破壊的な同期の両方が必要かもしれません。

[bdunderscore]

シーン上に存在するアバターの一覧を表示し、ビルドプロセスを開始する UI を表示するような NDMF のウィンドウが新設されるということですか？

その予定です。

CommonAvatarInfo の形が定まるまでしばらくかかりそうに思いましたが、おそらく VRCAvatarDescriptor の定義に基づいた抽象的表現になると想像しています。（他に基準となれるアバター定義は存在しないと思います）

大体そんな感じ（ビューポイント位置、viseme設定などを予定しています）

CommonAvatarInfo が VRCAvatarDescriptor の定義に基づく場合、 CommonAvatarInfo を通した完全に自動化されたアバター定義の変換は期待できない可能性があります。ビルド時の同期と手動の破壊的な同期の両方が必要かもしれません。

どのプラットフォームでもいえることですが、そのプラットフォーム独自の必須項目もあると思います。しかし、共通できるものはズレないように共通化していきたい、というスタンスです。独自設定は独自コンポーネントで保持できればと思います。

（その点アバタールートがいろいろとごちゃごちゃになりそうなのは何とかしたいけどね・・・）