【Unite Tokyo 2019】3Dアバターファイルフォーマット「VRM」詳説
?
7 likes?4,977 views
Unite Tokyo 2019 Day2 18:30～ ROOM C 「3Dアバターファイルフォーマット「VRM」詳説」講演資料
【Unite Tokyo 2019】3Dアバターファイルフォーマット「VRM」詳説
- 1. 3Dアバターファイルフォーマット 「VRM」詳説 株式会社バーチャルキャスト / VirtualCast Inc. 岩城 進之介 / Shinnosuke Iwaki @MobileHackerz (MIRO)
- 2. 自己紹介 ? 現株式会社バーチャルキャスト CTO ? これまでドワンゴでイベント演出? AR?VRの開発全般を担当 ? 個人では「携帯動画変換君」という フリーウェアの作者として（一部 で）知られています 岩城 進之介 （ハンドル：MIRO / @MobileHackerz）
- 3. 「痴搁惭」とは何か
- 10. 「痴搁惭」の思想?未来像
- 12. VR世界はだれがつくる？ ? フィクションの中の「VR世界」 では「単一の事業体」が「巨大 なVR空間」を構築しているとい う世界観が多い ? 現実のWebはそうなっているだ ろうか？ ? 「単一の事業体」が単一の世界 観でつくる「VR世界」が本当に 我々の望むものだろうか？
- 19. 「痴搁惭」の方针と设计
- 21. VRMが生まれた背景 ? 人型モデルを扱いたい！…のだが… ? モデルデータによって（モデラーの癖によって）モデルデータの構造 がバラバラという現状 ? 表情は… ? BlendShape ? マテリアルの入れ替え ? UVオフセット ? 目線は… ? 眼球ボーン ? UVオフセット ? 座標系、スケール、Aスタンス?Tスタンス、ボーンのローカル回転…
- 22. VRMの基本構成 ? glTF 2.0 ? Khronos Groupが定義しているオープンな3Dシーン記述フォーマット ? 不要なデータを含めない制約（glTFはなんでもできすぎる！） ? 人型モデルに必要な（かつglTFに定義されてない）情報の拡張 ? トゥーンシェーダなどのマテリアル拡張 ? アバターキャラクタとして使うために便利な簡易揺れモノ定義 ? アバターデータとして流通させるためのライセンス定義
- 24. 一般消費者に対するわかりやすさ ? ファイルが1つで完結すること ? 「そのファイルを持っていれば大丈夫」でなければならない ? そのファイルが対応アプリケーションで「使える」ことがわか ること ? ファイルに独自の拡張子と名前がついていて、広い互換性があること ? ファイルを取り扱う際に「設定」や「調整」が不要なこと ? ボーン構成や座標系 ? スケールや向きが違うとつらい ? 見栄え（レンダリング）や揺れものなど
- 25. クリエイターに対するわかりやすさ ? 複雑化するモデルデータの利用規約に対し、ファイルフォーマット の規定として雛形を定義 ? 独自規約は「URLを記載する」形にすることで一定のハードルを設定 ? フォーマット規定としての制約（Tスタンス?ボーンのローカル回転 除去）はエクスポートツール側で自動的に処理 ? 「VRM化するために」あらたに設定?定義しなければならない事項 についてはなるべく簡便に、項目数を減らす ? BlendShapeによる表情パターン設定UI ? MToonなどの標準シェーダ ? 揺れものの定義UIと設定量 ? 母音のみの口パク設定
- 26. エンジニアに対するわかりやすさ ? 1にも2にも「使いやすい標準実装を提供する」 ? 仕様だけ提供しても使われない。あくまでも「使いやすい標準 実装」が伴っていることが重要 ? ランタイムローディングなど、エンジニアが「やりたい」と思 う処理は非常に簡単に書けるようにする ? ロードしたモデルデータの取り扱い（表情など）も統一したAPI で処理できるように
- 27. 「なんでもできる」は何もできない ? 「なんでもできる」ものは「何をしていいのかわからない」 ? 自由度を高めすぎると使われない ? 适度な制约で目的を设定する
- 28. データとアプリケーションの分離 ? データとアプリケーションが分離すると、データとアプリケー ションそれぞれ独立した発達がはじまる ? さまざまなアプリケーションが生まれる土壌となる ? 「アバター」のデータについては、アプリケーションやサービ スから「人格」が分離することにあたる ? 人格がプラットフォームに縛られない世界 ? 複数キャラクターのコラボレーション ? アプリケーション間?プラットフォーム間の移動
- 29. クリエイターの「意思を伝える」 ? 現状VRMのライセンス設定は「クリエイターの意思を伝える」 ことを想定した設計（＝性善説にもとづく設計） ? いままではこの「意思を伝える」ことも難しかった ? VRMは「最終出力フォーマット」であるという前提 ? .PSDではなく .JPG相当、編集用ファイルではなく出力用ファイル ? 「最終出力」としては見た目も揃えたい ? レンダリング結果をアプリケーション間で近しいものにしたい ? シェーダを規定する必要性 ? レンダリングの最終結果をコントロールしようとすればするほどポー タビリティが下がってしまう → バランスを考慮
- 30. 痴搁惭で今できること
- 31. Humanoidの3Dモデルを簡便に取り扱える ? Unity上でVRMを取り扱うライブラリ(UniVRM)がMITライセンス で提供されている ? Unityでモデルデータをランタイムロードできる ? 同期読み込みだけでなく、非同期読み込みも非常に簡単にできる ? 読み込むとUnityのHumanoid Avatarが設定される →Unityで簡単に制御できる
- 32. アプリケーションで取り扱いやすい構造 に正規化されている ? ローカルの回転?スケールなどが正規化されている ? HumanPoseに依存しなくともアプリケーションで姿勢を取り扱える ? 座标轴?正面方向が揃っている
- 33. VRで利用する人型アバターとして便利な 設定?APIが整備されている ? 一人称視点 ? 揺れモノ ? 表情定義 ? モーフなのかUVスクロールなのか ? 標準表情の定義
- 34. マシンリーダブルなライセンス定義 ? 改変?配布に関してはCreative Commonsライセンスに沿った定 義から選択式で設定可能 ? 「アバターの人格に関するライセンス」というものを設定可能 ? アバターの利用条件を基本的にマシンリーダブルな形でファイ ル内に持つことで、アプリケーション側での統一的な対応が可 能
- 35. トゥーン表現が標準定義されている ? 標準で指定可能なマテリアル定義 ? PBR ? Unlit ? MToon ? 「標準のトゥーンシェーダ」が定義されているのでその定義に 従って設定してあれば他アプリケーションでも近しいレンダリ ング結果が期待できる
- 37. MToon とは ● アニメ的表現を目的とした VRM 標準のトゥーンシェーダ ● スライダパラメータによって陰影を簡易に設定できる ● ベース色と 1 影色の混合で表現 ○ 混合の程度は光源情報などによって計算される
- 38. 設定する前に：ライトを白色に変更 ディレクショナルライトを白色に設定する ● Color: #FFFFFF ● Intensity: 1 ● 色のバイアスがかかった状態で編集するのを避けるため ● 新規作成シーンの Directional Light は黄色みがかっている
- 40. 設定してみる：ベースカラーだけ 2/4 ● 下記 2 項目の色を白色 (#FFFFFF) に設定 ○ Basic → Color → Lit & Alpha ○ Basic → Color → Shade
- 41. 設定してみる：ベースカラーだけ 3/4 ● 下記 2 項目に同一のテクスチャを設定 ○ Basic → Color → Lit & Alpha ○ Basic → Color → Shade
- 42. 設定してみる：ベースカラーだけ 4/4 結果：周りの光源に依らずベースカラーをそのまま出力 通常光源赤 (#FF0000) 光源 光源なし (GIのみ)
- 44. 設定してみる：輪郭線をつける 2/6 ● Outline → Width → Mode を WorldCoordinates に変更 ● Outline → Width → Width で輪郭線幅を変更 ● Outline → Color → Mode を FixedColor / MixedLighting に変更 ● Outline → Color → Color で輪郭線色を変更
- 45. 設定してみる：輪郭線をつける 3/6 輪郭線なし 輪郭線あり (FixedColor) 輪郭線あり (MixedLighting)
- 46. 設定してみる：輪郭線をつける 4/6 FixedColor と MixedLighting の違い ● FixedColor は設定した輪郭線色をそのまま出力 ● MixedLighting は本体の色と Mix される FixedColor MixedLighting
- 47. 設定してみる：輪郭線をつける 5/6 問題：目や口の輪郭線が太い 太すぎる輪郭線の例 解決：輪郭線の幅を制御する テクスチャを作成?設定 ● Outline → Width → Width ● 白色：そのままの幅 ● 黒色：輪郭線を出さない 輪郭線幅のテクスチャ 設定箇所
- 49. 設定してみる：陰影をつける 1/8 目的：周辺ライティングにあわせて 陰影が表現できる ● まずは Directional Light 1 灯で調整 ○ 「初期設定」の項目を要再確認 ○ MToon は Point Light や複数光源に対応済みだが ライト設定はセンスの塊なのでまずはシンプルに 周りの暗い光源環境に合っていない様子
- 50. 設定してみる：陰影をつける 2/8 １影色を設定する ● Color → Shade Color ● １影色の V (明るさ) ○ 100 でも良い ○ ベース色の V 以下にする ● テクスチャによる指定の場合 ○ ベース色とは異なる Tex を使用 ○ 1 Material でも部位によって異なる 多彩な１影色を指定可能
- 52. 設定してみる：陰影をつける 4/8 問題：光の入射角度に対して 顔の陰影がキツい 解決：Shading Shift を用いて 陰影境界値をズラす ● Lighting → Shading Shift
- 53. 設定してみる：陰影をつける 5/8 問題：光の入射角度に対して 顔の陰影がキツい 解決：Shading Shift を用いて 陰影境界値をズラす Shading Shift 0.0 Shading Shift -0.633
- 54. 設定してみる：陰影をつける 6/8 問題：肌の陰影境界はクッキリ して欲しくない 解決：Shading Toony を用いて 陰影境界を滑らかにする
- 55. 設定してみる：陰影をつける 7/8 問題：肌の陰影境界はクッキリ して欲しくない 解決：Shading Toony を用いて 陰影境界を滑らかにする Shading Toony 0.9 Shading Toony 0.1
- 56. 設定してみる：陰影をつける 8/8 逆光 順光 真横からの光
- 58. 設定してみる：リムライトをつける 2/4 目的：ハイライト成分を付与 ● MToon では MatCap または SphereMap などで 知られるテクスチャマッピングを使用 ○ モデルの法線方向に応じてマッピングされる MatCap テクスチャMatCap テクスチャを適用
- 59. 設定してみる：リムライトをつける 3/4 目的：ハイライト成分を付与 ● MToon では MatCap または SphereMap などで 知られるテクスチャマッピングを使用 ○ モデルの法線方向に応じてマッピングされる MatCap テクスチャMatCap テクスチャを適用
- 62. 陰影制御のパラメータ Shading Shift ● 陰影境界をズラす度合い Shading Toony ● 陰影境界のクッキリ度合い
- 63. 陰影制御のパラメータ Shadow Receive Multiplier ● 落ち影を付与する度合い LightColor Attenuation ● 光源色の彩度の反映度合い Lit & Shade Mixing Multiplier ● 陰になりやすくなる度合い GI Intensity ● 環境光の影響度合い
- 67. 痴搁惭の课题
- 68. 多く上がる声① ? 「安心して（何も考えずに）使える」域に至っていない ? なんかうまく変換できない ? 変換にUnityが必要なのはつらい ? Unityでしか使えないのつらい ? アプリで読み込んだけどうまく動かない ? ポリゴン数?マテリアル数の制限があったりしてアプリによって使え たり使えなかったりする（ファイル互換性問題）
- 69. 多く上がる声② ? ライセンスの「意思の伝達」から「保護」へ ? ライセンスを定義しても守られない ? コピーされる?パクられるのが不安 ? 「保護」を求める声 ? ライセンスの定義がよくわからない ? 表現力の向上 ? こういう表現はできないのか、ああいう表現はできないのか ? ○○が使いたい ? 揺れもの（特にスカート） ? VRMコンソーシアムが何をやっているのかわからない
- 70. 仕様の課題?実装の課題?運用の課題 ? VRMという仕様自体がもつ課題と、UniVRMというライブラリ実 装が持つ課題、実装人員含めた運用体制の課題 ? 「作りながら考えている?考えながら作っている」状況のため、いま はそれぞれごっちゃになってしまっている ? 仕様をきちんと「仕様」にまとめるマンパワーも足りていない ? ほかのプラットフォームへ実装するマンパワーはもっと足りていない ? ほかに「VRMという仕様を使ったアプリケーション」がきちん と揃うことで解決可能な課題もある ? これは参加してくれる人を増やす＆自分たちで作るしかない！
- 71. VRM 1.0に向けて
- 72. 技術要件の再整理、標準対応① ? Typoの解消 ? glTF extention定義 ? マテリアルの整理 ? glTFと統合できるところはする ? Unlit/PBRと同様に「トゥーン」マテリアルの定義を試みる ? 「Unityのマテリアルの単純ダンプ」という形は廃止する ? 表情の再整理 ? フェイストラッキングに向けた情報の整理 ? フェイストラッキングとアニメ的なEmotionのマッピング ? 目パチ?口パクと表情のバッティング問題
- 73. 技術要件の再整理、標準対応② ? テクスチャ圧縮 ? WebP ? Universal Texture for glTF (KTX2) ? モーフターゲットの差分対応 ? LoDモデルを定義可能な拡張 ? 自動処理の可不可フラグ ? VRMSpringBoneの拡張 ? コライダの種類拡張 ? カプセルコライダ ? 内側コライダ（反転コライダ）
- 74. 技術要件の再整理、標準対応③ ? 簡易クロスシミュレーション（スカート対応） ? 実装上のパフォーマンスが課題 ? 一部座標系の混乱がある部分の修正 ? SpringBoneColliderのOffset ? Constraintの導入
- 75. ライセンス条件の整備 ? 「人格」についての詳細な規定 ? 人がキャラクターを演じる場合 ? ゲームの登場人物として制御する場合 ? ポーズをつける、機械的なモーションをあてる場合 ? そのほかの判断に迷うユースケースはあるか？ ? CCと人格ライセンスの不整合解消 ? ライセンスの記録形態をglTF自体のメタデータ記録に寄せる ? 個別のマテリアルごとにライセンスを定義できたほうがよい？ 考え方、設定方法などが複雑になりすぎると正しく使われない 正しく使われないと機械的な判断ができない クリエイター?利用者双方の利益となるバランスに留意する
- 76. さらなる広がりに向けての検討 ? アクセサリなどのアタッチターゲット（アンカー） ? カスタム可能テクスチャ情報 ? Tシャツの柄だけ変更する、とか ? 動きの「スタイル」メタ情報 ? 標準モーションのスタイルを決められると便利か ? アニメーションフォーマットの定義 ? IK/FK/リターゲットの概念を当初から想定したものが必要 ? ダンスモーションなどの流通が期待できる やりたいことはいっぱいあるが 複雑になりすぎないように注意する！
- 78. VRM動的処理?配信サーバ 「VRM Modifier Server」 VRM model (Original) Data Storage VRM Modifier Server メッシュ?マテリアル 最適化 ポリゴンリダクション 電子透かしの埋め込み データスクランブル エンドユーザにデータ配信
- 79. VRM Modifier Serverによるリダクション オリジナルVRM：約41000ポリゴン ダウンロード時動的サーバ変換 設定値：10000ポリゴン
- 82. まもなく逐次稼働开始！