【Unite Tokyo 2019】3Dアバターファイルフォーマット「VRM」詳説

3Dアバターファイルフォーマット 「VRM」詳説 株式会社バーチャルキャスト / VirtualCast Inc. 岩城 進之介 / Shinnosuke Iwaki @MobileHackerz (MIRO)

自己紹介 岩城 進之介 （ハンドル：MIRO / @MobileHackerz） • 現株式会社バーチャルキャスト CTO • これまでドワンゴでイベント演出・ AR・VRの開発全般を担当 • 個人では「携帯動画変換君」という フリーウェアの作者として（一部 で）知られています

「VRM」とは何か

「VRM」とは 「人型のキャラクターやアバター」において 細かいモデルデータの差違を吸収・統一し アプリケーション側の取り扱いを簡単にする プラットフォーム非依存・横断型の 3Dアバターファイルフォーマットです

3Dキャラクター 作成ツール バーチャルキャスト VRアバター 配信ツール VRゲーム （ゲーム実況） VRMファイル（3Dアバター） VR空間 集会サービス VRライブイベント 各社・各プラットフォームをまたがって 同じ「自分」（アバター）で参加できる

人型の「自分のアバター3Dモデル」を さまざまなアプリケーションで ランタイム（実行時）に 読み込むことができるようになります

ファイル自体の改変・再配布規定 だけでなく、VRアバター時代に適応した 「ライセンス」のファイル埋め込みに対応

そのモデルデータ（アバター）を使用して 「人格を演じる」ことについての許諾規定 という新時代の概念を提案しています

ほかにもVRで一人称表現を行う際 「どの部分を消す必要があるか」などの 情報もモデルデータに埋め込み可能

「VRM」の思想・未来像

アバターとアイデンティティ • 「Twitterでいつも見ているあの人」 ぱっとイメージが結びつくのは その人の顔から？ それとも その人のアイコンから？ ネット上の「自分」としての 「アバター（アイコン）」

VR世界はだれがつくる？ • フィクションの中の「VR世界」 では「単一の事業体」が「巨大 なVR空間」を構築しているとい う世界観が多い • 現実のWebはそうなっているだ ろうか？ • 「単一の事業体」が単一の世界 観でつくる「VR世界」が本当に 我々の望むものだろうか？

VRでの「自分の姿」は自意識に影響する

各個人が自分の「VRアバター」を持つ未来 • 特にVRでは、自分が「どのような姿になるか」は個人の意識に 繋がっていく。 • そんななか、現在は各社VRサービスやVRゲームごとに「別の」 アバターをまとわなければならない状況にある このままでは プラットフォームごとに 「別の」自分が産まれてしまう

「自分」のまま あらゆるVR世界を 行き来したい

このままでは その未来は やってこない！

VR時代には プラットフォーム横断型の VRアバターという 新概念が必要

とはいえ 「VRアバター」だけでは まだ概念が未来すぎる ので… （ですよね？）

「VRM」の方針と設計

【課題の再定義】 ポータブルで ランタイムに読み込み可能な （アバターとして使える） 3Dモデルデータを 取り扱う 適切なフォーマットがない

VRMが生まれた背景 • 人型モデルを扱いたい！…のだが… • モデルデータによって（モデラーの癖によって）モデルデータの構造 がバラバラという現状 • 表情は… • BlendShape • マテリアルの入れ替え • UVオフセット • 目線は… • 眼球ボーン • UVオフセット • 座標系、スケール、Aスタンス・Tスタンス、ボーンのローカル回転…

VRMの基本構成 • glTF 2.0 • Khronos Groupが定義しているオープンな3Dシーン記述フォーマット • 不要なデータを含めない制約（glTFはなんでもできすぎる！） • 人型モデルに必要な（かつglTFに定義されてない）情報の拡張 • トゥーンシェーダなどのマテリアル拡張 • アバターキャラクタとして使うために便利な簡易揺れモノ定義 • アバターデータとして流通させるためのライセンス定義

VRMの方針 これは「クリエイター」や 「エンジニア」だけではなく 最終的には「一般消費者」が 取り扱うファイルになる →「わかりやすさ」 「取り回しのしやすさ」を重視

一般消費者に対するわかりやすさ • ファイルが1つで完結すること • 「そのファイルを持っていれば大丈夫」でなければならない • そのファイルが対応アプリケーションで「使える」ことがわか ること • ファイルに独自の拡張子と名前がついていて、広い互換性があること • ファイルを取り扱う際に「設定」や「調整」が不要なこと • ボーン構成や座標系 • スケールや向きが違うとつらい • 見栄え（レンダリング）や揺れものなど

クリエイターに対するわかりやすさ • 複雑化するモデルデータの利用規約に対し、ファイルフォーマット の規定として雛形を定義 • 独自規約は「URLを記載する」形にすることで一定のハードルを設定 • フォーマット規定としての制約（Tスタンス・ボーンのローカル回転 除去）はエクスポートツール側で自動的に処理 • 「VRM化するために」あらたに設定・定義しなければならない事項 についてはなるべく簡便に、項目数を減らす • • • • BlendShapeによる表情パターン設定UI MToonなどの標準シェーダ 揺れものの定義UIと設定量 母音のみの口パク設定

エンジニアに対するわかりやすさ • 1にも2にも「使いやすい標準実装を提供する」 • 仕様だけ提供しても使われない。あくまでも「使いやすい標準 実装」が伴っていることが重要 • ランタイムローディングなど、エンジニアが「やりたい」と思 う処理は非常に簡単に書けるようにする • ロードしたモデルデータの取り扱い（表情など）も統一したAPI で処理できるように

「なんでもできる」は何もできない • 「なんでもできる」ものは「何をしていいのかわからない」 • 自由度を高めすぎると使われない • 適度な制約で目的を設定する

データとアプリケーションの分離 • データとアプリケーションが分離すると、データとアプリケー ションそれぞれ独立した発達がはじまる • さまざまなアプリケーションが生まれる土壌となる • 「アバター」のデータについては、アプリケーションやサービ スから「人格」が分離することにあたる • 人格がプラットフォームに縛られない世界 • 複数キャラクターのコラボレーション • アプリケーション間・プラットフォーム間の移動

クリエイターの「意思を伝える」 • 現状VRMのライセンス設定は「クリエイターの意思を伝える」 ことを想定した設計（＝性善説にもとづく設計） • いままではこの「意思を伝える」ことも難しかった • VRMは「最終出力フォーマット」であるという前提 • .PSDではなく .JPG相当、編集用ファイルではなく出力用ファイル • 「最終出力」としては見た目も揃えたい • レンダリング結果をアプリケーション間で近しいものにしたい • シェーダを規定する必要性 • レンダリングの最終結果をコントロールしようとすればするほどポー タビリティが下がってしまう → バランスを考慮

VRMで今できること

Humanoidの3Dモデルを簡便に取り扱える • Unity上でVRMを取り扱うライブラリ(UniVRM)がMITライセンス で提供されている • Unityでモデルデータをランタイムロードできる • 同期読み込みだけでなく、非同期読み込みも非常に簡単にできる • 読み込むとUnityのHumanoid Avatarが設定される →Unityで簡単に制御できる

アプリケーションで取り扱いやすい構造 に正規化されている • ローカルの回転・スケールなどが正規化されている • HumanPoseに依存しなくともアプリケーションで姿勢を取り扱える • 座標軸・正面方向が揃っている

VRで利用する人型アバターとして便利な 設定・APIが整備されている • 一人称視点 • 揺れモノ • 表情定義 • モーフなのかUVスクロールなのか • 標準表情の定義

マシンリーダブルなライセンス定義 • 改変・配布に関してはCreative Commonsライセンスに沿った定 義から選択式で設定可能 • 「アバターの人格に関するライセンス」というものを設定可能 • アバターの利用条件を基本的にマシンリーダブルな形でファイ ル内に持つことで、アプリケーション側での統一的な対応が可 能

トゥーン表現が標準定義されている • 標準で指定可能なマテリアル定義 • PBR • Unlit • MToon • 「標準のトゥーンシェーダ」が定義されているのでその定義に 従って設定してあれば他アプリケーションでも近しいレンダリ ング結果が期待できる

VRM標準トゥーンシェーダ MToonについて

MToon とは ● アニメ的表現を目的とした VRM 標準のトゥーンシェーダ ● スライダパラメータによって陰影を簡易に設定できる ● ベース色と 1 影色の混合で表現 ○ 混合の程度は光源情報などによって計算される

設定する前に：ライトを白色に変更 ディレクショナルライトを白色に設定する ● Color: #FFFFFF ● Intensity: 1 ● 色のバイアスがかかった状態で編集するのを避けるため ● 新規作成シーンの Directional Light は黄色みがかっている

設定してみる：ベースカラーだけ 1/4 目的：周りの光源に依らず ベースカラーだけを出力 ● いわゆる Unlit

設定してみる：ベースカラーだけ 2/4 ● 下記 2 項目の色を白色 (#FFFFFF) に設定 ○ Basic → Color → Lit & Alpha ○ Basic → Color → Shade

設定してみる：ベースカラーだけ 3/4 ● 下記 2 項目に同一のテクスチャを設定 ○ Basic → Color → Lit & Alpha ○ Basic → Color → Shade

設定してみる：ベースカラーだけ 4/4 結果：周りの光源に依らずベースカラーをそのまま出力 赤 (#FF0000) 光源 通常光源 光源なし (GIのみ)

設定してみる：輪郭線をつける 1/6 目的：輪郭線を描画 ● いわゆるジオメトリ反転拡大を用いた輪郭線

設定してみる：輪郭線をつける 2/6 ● Outline → Width → Mode を WorldCoordinates に変更 ● Outline → Width → Width で輪郭線幅を変更 ● Outline → Color → Mode を FixedColor / MixedLighting に変更 ● Outline → Color → Color で輪郭線色を変更

設定してみる：輪郭線をつける 3/6 輪郭線なし 輪郭線あり (FixedColor) 輪郭線あり (MixedLighting)

設定してみる：輪郭線をつける 4/6 FixedColor と MixedLighting の違い ● FixedColor は設定した輪郭線色をそのまま出力 ● MixedLighting は本体の色と Mix される FixedColor MixedLighting

設定してみる：輪郭線をつける 5/6 問題：目や口の輪郭線が太い 解決：輪郭線の幅を制御する テクスチャを作成・設定 ● Outline → Width → Width ● 白色：そのままの幅 ● 黒色：輪郭線を出さない 太すぎる輪郭線の例 輪郭線幅のテクスチャ 設定箇所

設定してみる：輪郭線をつける 6/6 問題：目や口の輪郭線が太い 目や口の輪郭線が太い 解決：輪郭線の幅を制御する テクスチャを作成・設定 目や口の輪郭線を細く

設定してみる：陰影をつける 1/8 目的：周辺ライティングにあわせて 陰影が表現できる ● まずは Directional Light 1 灯で調整 ○ 「初期設定」の項目を要再確認 ○ MToon は Point Light や複数光源に対応済みだが ライト設定はセンスの塊なのでまずはシンプルに 周りの暗い光源環境に合っていない様子

設定してみる：陰影をつける 2/8 １影色を設定する ● Color → Shade Color ● １影色の V (明るさ) ○ 100 でも良い ○ ベース色の V 以下にする ● テクスチャによる指定の場合 ○ ベース色とは異なる Tex を使用 ○ 1 Material でも部位によって異なる 多彩な１影色を指定可能

設定してみる：陰影をつける 3/8 ベース色と１影色が同じ １影色に違う色を設定

設定してみる：陰影をつける 4/8 問題：光の入射角度に対して 顔の陰影がキツい 解決：Shading Shift を用いて 陰影境界値をズラす ● Lighting → Shading Shift

設定してみる：陰影をつける 5/8 問題：光の入射角度に対して 顔の陰影がキツい Shading Shift 0.0 解決：Shading Shift を用いて 陰影境界値をズラす Shading Shift -0.633

設定してみる：陰影をつける 6/8 問題：肌の陰影境界はクッキリ 解決：Shading Toony を用いて して欲しくない 陰影境界を滑らかにする

設定してみる：陰影をつける 7/8 問題：肌の陰影境界はクッキリ 解決：Shading Toony を用いて して欲しくない 陰影境界を滑らかにする Shading Toony 0.9 Shading Toony 0.1

設定してみる：陰影をつける 8/8 逆光 順光 真横からの光

設定してみる：リムライトをつける 1/4 問題：ハイライト成分が不足 解決：リムライトを付与

設定してみる：リムライトをつける 2/4 目的：ハイライト成分を付与 ● MToon では MatCap または SphereMap などで 知られるテクスチャマッピングを使用 ○ モデルの法線方向に応じてマッピングされる MatCap テクスチャを適用 MatCap テクスチャ

設定してみる：リムライトをつける 3/4 目的：ハイライト成分を付与 ● MToon では MatCap または SphereMap などで 知られるテクスチャマッピングを使用 ○ モデルの法線方向に応じてマッピングされる MatCap テクスチャを適用 MatCap テクスチャ

設定してみる：リムライトをつける 4/4 問題：ハイライト成分が不足 ハイライトなし 解決：リムライトを付与 ハイライトあり

設定してみる：結果 ベースカラーのみ 輪郭線付与 陰影付与 ハイライト付与

陰影制御のパラメータ Shading Shift ● 陰影境界をズラす度合い Shading Toony ● 陰影境界のクッキリ度合い

陰影制御のパラメータ Shadow Receive Multiplier ● 落ち影を付与する度合い Lit & Shade Mixing Multiplier ● 陰になりやすくなる度合い LightColor Attenuation ● 光源色の彩度の反映度合い GI Intensity ● 環境光の影響度合い

MToonとUTS2の比較 UTS2 MToon

MToonとUTS2の比較（ライティング） UTS2 MToon

MToonの表現（ユーザ事例） https://twitter.com/asutoroUmario/status/1148890993669763073

• https://twitter.com/asutoroUmario/status/1148890993669763073

VRMの課題

多く上がる声① • 「安心して（何も考えずに）使える」域に至っていない • • • • • なんかうまく変換できない 変換にUnityが必要なのはつらい Unityでしか使えないのつらい アプリで読み込んだけどうまく動かない ポリゴン数・マテリアル数の制限があったりしてアプリによって使え たり使えなかったりする（ファイル互換性問題）

多く上がる声② • ライセンスの「意思の伝達」から「保護」へ • ライセンスを定義しても守られない • コピーされる・パクられるのが不安 • 「保護」を求める声 • ライセンスの定義がよくわからない • 表現力の向上 • こういう表現はできないのか、ああいう表現はできないのか • ○○が使いたい • 揺れもの（特にスカート） • VRMコンソーシアムが何をやっているのかわからない

仕様の課題・実装の課題・運用の課題 • VRMという仕様自体がもつ課題と、UniVRMというライブラリ実 装が持つ課題、実装人員含めた運用体制の課題 • 「作りながら考えている・考えながら作っている」状況のため、いま はそれぞれごっちゃになってしまっている • 仕様をきちんと「仕様」にまとめるマンパワーも足りていない • ほかのプラットフォームへ実装するマンパワーはもっと足りていない • ほかに「VRMという仕様を使ったアプリケーション」がきちん と揃うことで解決可能な課題もある • これは参加してくれる人を増やす＆自分たちで作るしかない！

VRM 1.0に向けて

技術要件の再整理、標準対応① • Typoの解消 • glTF extention定義 • マテリアルの整理 • glTFと統合できるところはする • Unlit/PBRと同様に「トゥーン」マテリアルの定義を試みる • 「Unityのマテリアルの単純ダンプ」という形は廃止する • 表情の再整理 • フェイストラッキングに向けた情報の整理 • フェイストラッキングとアニメ的なEmotionのマッピング • 目パチ・口パクと表情のバッティング問題

技術要件の再整理、標準対応② • テクスチャ圧縮 • WebP • Universal Texture for glTF (KTX2) • モーフターゲットの差分対応 • LoDモデルを定義可能な拡張 • 自動処理の可不可フラグ • VRMSpringBoneの拡張 • コライダの種類拡張 • カプセルコライダ • 内側コライダ（反転コライダ）

技術要件の再整理、標準対応③ • 簡易クロスシミュレーション（スカート対応） • 実装上のパフォーマンスが課題 • 一部座標系の混乱がある部分の修正 • SpringBoneColliderのOffset • Constraintの導入

ライセンス条件の整備 • 「人格」についての詳細な規定 • 人がキャラクターを演じる場合 • ゲームの登場人物として制御する場合 • ポーズをつける、機械的なモーションをあてる場合 • そのほかの判断に迷うユースケースはあるか？ • CCと人格ライセンスの不整合解消 • ライセンスの記録形態をglTF自体のメタデータ記録に寄せる • 個別のマテリアルごとにライセンスを定義できたほうがよい？ 考え方、設定方法などが複雑になりすぎると正しく使われない 正しく使われないと機械的な判断ができない クリエイター・利用者双方の利益となるバランスに留意する

さらなる広がりに向けての検討 • アクセサリなどのアタッチターゲット（アンカー） • カスタム可能テクスチャ情報 • Tシャツの柄だけ変更する、とか • 動きの「スタイル」メタ情報 • 標準モーションのスタイルを決められると便利か • アニメーションフォーマットの定義 • IK/FK/リターゲットの概念を当初から想定したものが必要 • ダンスモーションなどの流通が期待できる やりたいことはいっぱいあるが 複雑になりすぎないように注意する！

アプリケーション側での 課題解決 （株式会社バーチャルキャストで開発中の技術）

VRM動的処理・配信サーバ 「VRM Modifier Server」 メッシュ・マテリアル 最適化 VRM model (Original) Data Storage ポリゴンリダクション 電子透かしの埋め込み データスクランブル VRM Modifier Server エンドユーザにデータ配信

VRM Modifier Serverによるリダクション オリジナルVRM：約41000ポリゴン ダウンロード時動的サーバ変換 設定値：10000ポリゴン

人型（VRM）であることをヒント情報にする VRMヒントなしリダクション 10000ポリゴン VRMヒントありリダクション 10000ポリゴン

Scrambled VRM・データ透かし

まもなく逐次稼働開始！

現在の状況まとめ アプリケーションの課題 VRMを利用した基盤サービスの整備 使いやすいアプリケーションの開発 運用の課題 がんばる 実装の課題 UniVRMとVRM仕様の分離 変換ツールなどの整備 Unity以外の実装を増やす（募集中！） 仕様の課題 VRM仕様の整理と拡張 ライセンスの整理

VRMアバターを持って VR世界へ飛び込もう！