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