※念のために書いておきますと、キャラクター配布者を批判する目的は一切ありません。
※重要なのは「問題の解決」と「VRアバターソリューションの提示」です。
※そのために必要な事を考察した文章であり、批判をする事のメリットがありません。

■更新状況
6/6 初稿 本文は執筆中の文章であり随時追記する。
6/9 各方面にご迷惑をおかけして申し訳ありません。
再度、わかりやすくまとめなおして再投稿します。
決して「パーツをタダでよこせ」という話ではないです。
6/10 配慮に欠く記事を投稿してしまい申し訳ありません。
記事を削除するのではなく、取り消し線という形で撤回させていただきます。

■本文を書く理由
VRアバターを誰でも持てるようにして、VRソーシャルをより楽しいものにしたい。

■概要

VRアバターとは「unityで動くキャラクターの3Dデータ」と定義する。
→定義が限定的すぎました、これはコンセプトと併せて再度説明します(訂正)

VRアバターを配布するにあたって…
規約の細分化 / 不正利用 / 国内国外の文化の違い / キャラクターの著作権 / データの最適化や互換性…など、様々な問題があります。
それらに対して対策などもありますが、根本的解決が困難なので度々問題視されています。

これらの問題の根本的原因は「キャラクターの3Dデータを配布してしまう」事にあります。
「キャラクター」を配布してしまうからこそ、(3Dデータの利用規約とは別の)キャラクターの著作権問題に派生し、キャラクターに情があるので制作者別に「〇〇はよくて〇〇はダメ」といった規約の細分化が生まれてしまい、利用範囲についてもデータ利用者の道徳に呼び掛けるのは限度があるので不正利用は０にならない。といった現状です。
つまり「キャラクターを配布する事」と「問題が発生する事」は因果関係になります。

また、規約の解釈が利用者によって異なったり、（使ってほしいけど嫌な使われ方はされたくない）といった配布者側の事情で規約を厳格に書ききれないといった問題もあります。

以上の問題を解決するには「キャラクターを配布せず」「VRアバターを配布する」必要があります。
具体的に言うと「キャラクターではなく個別のパーツとして配布する」という事です。
例えば、髪の毛や服やアクセサリーはキャラクター性の存在しない汎用的な3Dデータとして配布し、それらをデータ利用者がダウンロードした後に組み合わせて、パーツの集合体がキャラクターになれば…
配布しているデータはあくまでキャラクター性のない3Dデータであって、データ利用者が最終的にキャラクターとして組み立ててるという状況になります。
これが「キャラクターを配らずに、VRアバターを配る方法」になります。

■３行にまとめると
・キャラクターを配布するのはやめよう、プレーンなパーツを配布しよう
・パーツを配布するには互換性が必要なのでドキュメントを作ろう
・それらが気兼ねなく利用できるようにMITライセンスにしよう→CCの方が適切

■実装案
みんながきっと「カスタ〇メイドからMITライセンスのfbx吐き出せないかな」って思ってる。

現実的に考えると
１．アバター仕様のドキュメント
２．Blenderのパーツファイル
３．アバター作成時に便利なBlenderプラグイン

この１～３を誰でも自由に使えるCC(クリエイティブコモンズ)で提供するのが、費用対効果的によいのではと思います。
３のイメージは cats-blender-plugin みたいなものを２のデータでできる事。
そのうちunityのアバターメイキングSDKに発展すれば理想…

■データに求められる要件
※暫定的なイメージを具体化しただけであり、決定仕様ではありません(追記)
※ある程度具体性がないとイメージできないと思い書きましたが、結果として誤解を招いてしまい申し訳ありません。
０．人気のモデルやオーソドックスなモデルになんとな～く合わせて作ったら暗黙の文化として定着したみたいな闇の話はやめよう。

１．全てのパーツがCCライセンスである事　(CCに同意できないデータは公式に認めない)パーツ別に詳細なライセンスが付随すると、使用したパーツ全ての規約を継承したアバターになってしまいます。
それは、データの利用者のみならず、VRソーシャルに参加する第三者プレイヤーにとっても不便な事となります。

VRアバターのスクリーンショットがSNSに公開されたり、インターネットの動画配信や、メディアに掲載される事は十分想定できます。
そういった形で第三者のプレイヤーも関わる問題であるので、VRアバターが様々な規約を継承しているのは非常に望ましくありません。

２．商業利用可能(CCライセンス)である事
商業性がある事により、スタンダードになりやすくなる。
非商業利用を謳ったところで、問題が複雑化しデータ利用者が不便になるだけである。

３．互換性 / 拡張性 / 最適化 の総合力的に見てベターなアバター仕様を作成し、ドキュメントとして共有する事
拡張性について、unityやBlenderを使う事を想定すれば各自のデータ利用者が適宜行うべきであり、アバター仕様として盛り込むのは望ましくない。
モバイルまでを見こした最適化と互換性が重要であり、豪華主義ではなく魅力的なアバターになる必要十分の仕様である事が望ましい。

４．ボーン構造
ボーン構造はunityのhumanoid rigとする。
humanoidに該当しない形状のアバターはアバター仕様として吸収しない。（複雑性が上がる為）

５．モーフ名
元データの順番と名称を汎用的なSDKを基準に決定する。
そうする事でfbx出力時点での利便性を少しでも高める。
暫定的に言えばOVRLipSynkの15音素は結構ガチガチな研究に基づいて言ってるし、普遍性も高いと思う。
まぁ実用的には15音素もいらないと思うけど、あったらあったでいいしグローバル的にいっといたほうが広まりそうだし。
いつかはレガシーとなるが、VRMに変換して吸収する。

６．マテリアルとUV領域
マテリアルは原則１つとし、UV領域は2048pxとする。
厳しいがモバイルをある程度見据えた仕様である。
UV領域が足りない場合は拡張パーツとして吸収する。
あとどうせ、あれこれ拡張されるに決まっているのでベースとなるはこのぐらいの仕様がいいと思う。

７．不要ボーンの削除
プラグインで実行

８．オブジェクトの結合
プラグインで実行
少なくとも頭の領域と体の領域は分ける。
VRMでは頭のオブジェクトを視点のカメラからhideするオプションがある為。

９．拡張パーツ
アバター仕様内に吸収しきれなかった、パーツ制作者独自仕様のパーツ。
拡張パーツである場合は拡張パーツである事の明記と、その利用方法をテンプレート化しておけば、データ利用者が混乱しないで済む。

■最適化について
基本的に「分かれている程負担になる」「まとまってる程処理が早い」がCGの基本。
ここら辺についてはドローコールの回数云々なんかの話でよくある。
一見するとポリゴン数に気をとられがちだが、UV領域を狭くできるのならばポリゴン数を増やした方がよい場合の方が多い(ケースバイケースである)

なので、マテリアル数(テクスチャ枚数)を最小でとりつつ、吸収できない分は拡張パーツ扱いとして、利用者が何も考えてなくてもほどほどに最適化されたVRアバターが出てくるのが望ましい。
今後も高解像度化やモバイル化がすすむことを前提に考える。

■VRアバターに求められる要素
Youtubeの配信中に「VRアバターに求める要素」をアンケートした所…
全５択の内「唯一性」が１位の50％で「デザイン性」が２位の30％でした。
まとめると「唯一性があり、自分の気に入ったデザインのアバター」が最も求められている事になります。

そういった点から考えても、パーツを組み合わせる事で唯一性とデザイン性を両立したアバターが作り出されるのは理想だと言えます。
また、あくまで元のデータが「パーツ」である事によって、パッケージされたキャラクターとは違い余計なイメージのないフラットなデータとして利用できるのもメリットです。

■VRアバターとキャラクター3Dモデルの人格問題
VRソーシャルに長時間滞在すると、3Dモデルにプレイヤーの人格が紐づけられます。
3Dモデルを見た時に3Dモデルのキャラクターではなく、プレイヤーの人格のイメージが先行します。
この点が俯瞰視点の創作物であるゲーム/動画/画像用のモデルと大きく異なります。

そういった意味でも、同じ姿だとVRソーシャルにおいて不都合が起こりやすく、少なくとも選択肢の１つとしてカスタム性のある互換データを利用するというのはあると嬉しい事だと思います。
パッケージ済みのキャラクターは所謂工業製品のデザイナーズブランドのような認識です。

■VRChatで3Dモデルの不正利用が増えた原因

■拡張子
unityで使えるfbx や VRMが候補になりえます。

■欲しいコメント
・仕様のあれこれ
・プログラマーさんの目線で困った話(ボーン構造.モーフ名称等)