CEDEC2022-xyx-3Dデータを持ち込めるcross-platformメタバースの技術的挑戦.pdf

Transcript

1. 3Dデータを持ち込める cross-platformメタバースの 技術的挑戦 xyx Engineering Manager | Architect
2. Cluster, Inc. All Rights Reserved. 2 xyx Engineering Manager兼Architect @ cluster 経歴 2015~: Google, Software Engineer 2019~: Cluster, Unity Engineer 2022~: Cluster, EM / Architect 誰？ @xanxys_
4. Cluster, Inc. All Rights Reserved. 4 セッション内容 1. メタバースの性質 2/3. データ配信・同期 4. 歴史・設計思想
5. 5 1. メタバースとは 1.a. サービス概要
6. Cluster, Inc. All Rights Reserved. 6 基本構造
7. Cluster, Inc. All Rights Reserved. 7 基本的な体験: ワールド + アバター
8. Cluster, Inc. All Rights Reserved. 8 より簡単にアバターを手に入れる 他社モバイルアプリ とのアバター連携 cluster in-app アバター作成機能
9. Cluster, Inc. All Rights Reserved. 9 より簡単にワールドを作る: World Craft cluster in-app ワールド作成機能
10. 10 1. メタバースとは 1.b. サービスの基本動作原理
11. Cluster, Inc. All Rights Reserved. 11 全体構造
12. Cluster, Inc. All Rights Reserved. 12 1クライアントに注目
13. Cluster, Inc. All Rights Reserved. 13 同期される物の種類 アバター ワールド 3Dモデルデータ 位置・姿勢 音声・コメント 3Dモデルデータ アイテム位置情報 アイテム・プレイヤー状態
14. Cluster, Inc. All Rights Reserved. 14 クライアント - Room Server 基本的にはpubsub 非同期 物理演算は分散 Item「所有権」 はたまに移動する e.g. 操作時・切断時
15. Cluster, Inc. All Rights Reserved. 15 データがどこからやってくるか UGC
16. Cluster, Inc. All Rights Reserved. 16 基本的動作原理 - まとめ ITM (World Craftアイテム) 位置・姿勢情報 音声 アバター ワールド モデルデータ リアルタイム 状態 VRM Unity Asset Bundle (Creator Kitワールド) アイテム位置 状態
17. Cluster, Inc. All Rights Reserved. 17 基本的動作原理 - まとめ ITM (World Craftアイテム) 位置・姿勢情報 アバター ワールド モデルデータ リアルタイム 状態 VRM Unity Asset Bundle (Creator Kitワールド) アイテム位置 状態 section 2 アバター3Dデータ配信 section 3 アバター状態同期 section 4: 歴史・設計思想
18. 18 2. アバター3Dデータ配信
19. Cluster, Inc. All Rights Reserved. 19 ここの話
20. Cluster, Inc. All Rights Reserved. 20 アバターのデータサイズ 2019年時点の制限 2022年時点: 「無制限」 (内部的validationはある) ハイエンドVR向けの最適化されてないデータ 一部パラメータが←の数倍程度 生の一体のメモリフットプリント 数10MB~200MB程度 drawcall / 物理演算(揺れ物)も多い
21. Cluster, Inc. All Rights Reserved. 21 VRMの圧縮 GPU依存の圧縮画像形式の利用 VRMの中の画像は標準的にはPNG 展開後は生bitmapなので大きい & PNG展開処理が重い → ASTC / BC7にサーバー側で変換して配信 データそのもののリダクション 自動アトラス化・ポリゴンリダクション
22. Cluster, Inc. All Rights Reserved. 22 画像圧縮形式 Texture2D.LoadRawTextureData() で直接ロード可能 PSNR (Peak Signal-to-Noise Ratio)で 圧縮による劣化を評価 cluster内のテクスチャのサンプリング評価 (N=1391) 40dB (肉眼ではほぼ判別不能) → ASTC 4x4, BC7を採用 1 byte / px
23. Cluster, Inc. All Rights Reserved. 23 データそのもののリダクション 複数の圧縮「プロファイル」を定義 以下のような属性からプロファイルが選択される • イベントにおけるユーザーのロール • カメラからの相対位置・向き • ユーザーの品質設定 • ハードウェアの違い
24. Cluster, Inc. All Rights Reserved. 24 プロファイルの内部構成 各プロファイルは多段のoptimizerからなる • デバッグが容易 • コードをほぼ書かずに最適化の試行錯誤が可能 • プロファイルを増やすのが容易 • 中間形式もVRMなので変換オーバーヘッドがある VRM
25. Cluster, Inc. All Rights Reserved. 25 optimizerの一覧 メッシュ・テクスチャデータ削減系 アトラス化・resize ポリゴン数削減 マテリアル統合 … 追加attribute削除系 ブレンドシェイプ削除 揺れ物削除 …
26. Cluster, Inc. All Rights Reserved. 26 メッシュ簡略化 メッシュ簡略化: ↓の論文を実装するだけ 高速化にコツがいる • 部分的にpriorityが更新されるpriority queue ファンシーな簡略化アルゴリズムより、 実データ・要望に合わせたコスト関数の設計が肝 Surface Simplification Using Quadric Error Metrics (1997) doi.org/10.1145/258734.258849 https://www.cs.cmu.edu/~./garland/Papers/quadrics.pdf
27. Cluster, Inc. All Rights Reserved. 27 実データの面白い事例 面白い事例
28. Cluster, Inc. All Rights Reserved. 28 UGCならでは事例: アバター改変文化 販売者 身体部分・服・アクセサリなどを別の作者が販売 (unitypackage形式で流通) 購入者 unity上での組み合わせ 人によってはblender/photoshopで編集 複数のボーン構造 & skinned meshが混在 大量のマテリアル
29. Cluster, Inc. All Rights Reserved. 29 UGCならでは事例: 巨大透明テクスチャ とあるアバター作成ツール 絵を描ける人向けのツール 長袖ワンピースの巨大メッシュ (プリセット) + テクスチャのアルファで「形状」を描く そのままメッシュ削減すると透明部分に ポリゴン数が使われてしまう → 透明部分のメッシュを削減の前に削除
30. Cluster, Inc. All Rights Reserved. 30 リリース後が本番 モニタリング・CS prodでの変換失敗の監視 ユーザーからの問い合わせ CI テストデータと Web-based 比較ツール
31. 31 3. アバター状態同期
32. Cluster, Inc. All Rights Reserved. 32 ここの話
33. Cluster, Inc. All Rights Reserved. 33 ネタばれ 送出側client rootのtransform + humanoidの全52 boneのrotation + 表情系データ (最大) 15 Hzで送出 受信側client データを全員分受信してそのまま表示 なんで？？？ このセクションは 現在の運用に集中 歴史と経緯は 次のセクションを お楽しみに
34. Cluster, Inc. All Rights Reserved. 34 データサイズ bone情報 • 身体 (22 bone) • 手の指 (30 bone) 愚直にquaternion(float32 x4)をいれると 16 byte x 52 = 832 byte … root transform (vector3, quaternion): float32 x 7 → 28 byte それほど大きくはない
35. Cluster, Inc. All Rights Reserved. 35 回転のコンパクトな表現: 次元削減 q = ((x, y, z), w) = (v, w) としたときに 回転表現は単位quaternion( |q| = 1) なので次元がひとつ減る w = sqrt(1 - |v|^2) もともとのwの符号が消滅してしまう (が、これのために1bit追加したくない) q, -qの表現する回転は同じ if w < 0: q = -q しておけば、(x, y, z)の3要素でquaternionを完全に復元できる
36. Cluster, Inc. All Rights Reserved. 36 回転のコンパクトな表現: 精度削減 あとは(x, y, z)がそれぞれ[-1,1]なので、int表現にすれば… 落とし穴: quaternionのx,y,zの精度と回転の精度の関係は場所によって異なる q = (x, 0, 0, 1付近) ∂θ / ∂x = 2 q = (x, 0, 0, 0付近) ∂θ / ∂x = +∞ xがちょっと変わるだけで角度が急速に変化 qが表す回転角度をθとすると…
37. Cluster, Inc. All Rights Reserved. 37 回転のコンパクトな表現: 精度削減 part2 解決策 wが0付近で精度が悪化するので、 quaternionを前処理して分布を調整する (いくつかあるが) Half-Angle Encodingという手法が シンプルさと処理の軽さのバランスが良い
38. Cluster, Inc. All Rights Reserved. 38 ここまでをまとめると quaternionひとつを、15 bit ~ 45 bitで表現 Q45 (45 bit)は通常のアバターを表現するうえでは「無劣化」として扱える 各表現の間はbit演算だけで変換可能 CPU負荷軽減 Q45: 293 byte Q15: 98 byte ※ float: 832 byte
39. Cluster, Inc. All Rights Reserved. 39 頻度の間引き encodingの切り替え + 頻度の間引き • 手と身体で品質を使い分け • 権限・相対位置に応じて品質制御 room serverがユーザーの位置情報を使って ↑の処理を行う 最終的には: worst-caseでも(下り)1Mb/s程度に
40. Cluster, Inc. All Rights Reserved. 40 未来 さらなる圧縮余地 • {モデルデータ, humanoid}に基づく関節ごとの可動域 • より高度な補間 + 時系列の圧縮 いずれも、ネットワーク帯域と • CPU負荷 • 複雑性 (処理そのもの + データ依存性) のトレードになる
41. 41 4. 歴史・設計思想
42. Cluster, Inc. All Rights Reserved. 42 サービス歴史 2017 正式公開 2018 イベントチケット・投げ銭機能 2019 イベント会場作成SDK (ClusterVRSDK) アーカイブ機能 (2020年に終了) 2020 スマホ対応・ワールド機能・ソーシャル 2021 Quest2対応・Avatar Maker 2022 World Craft・アバター制限解放 Unity 2021 LTS Unity 2019 Unity 5 Unity 2017 Unity 2018 VRイベント プラットフォーム 時代 バーチャルSNS (メタバース) 時代 VR会議サービス 時代
43. Cluster, Inc. All Rights Reserved. 43 サービスの変遷 2020 2021 2022
44. Cluster, Inc. All Rights Reserved. 44 設計思想 動き続ける 生活空間であり、インフラである 変化に適応 メタバースの最終系はまだ定まってない 市場・ハードウェアの変化どちらも激しい コンテンツを作るのはユーザー 事前にテストしきってコンテンツ側でバグ回避は不可能 信頼性・自由度のトレードオフ
45. Cluster, Inc. All Rights Reserved. 45 事例 事例: Room Server + 同期
46. Cluster, Inc. All Rights Reserved. 46 伏線回収 送出側client rootのtransform + humanoidの全52 boneのrotation + 表情系データ (最大) 15 Hzで送出 受信側client データを全員分受信してそのまま表示 なんで？？？ このセクションは 現在の運用に集中 歴史と経緯は 次のセクションを お楽しみに
47. Cluster, Inc. All Rights Reserved. 47 そもそも 自分自身の アバター表示されるまで データフロー ひとつのclient
48. Cluster, Inc. All Rights Reserved. 48 そもそも2 何らかの方法で インターネット経由で 他者のアバターが表示される clientがいっぱいある
49. Cluster, Inc. All Rights Reserved. 49 2019: VRイベントプラットフォーム時代 VRイベントプラットフォーム 「演者」: 数人しかいない・モーションクオリティ高 「一般参加者」: 数十人・モーションクオリティ低・喋らない PC前提・公式イベント主体 非対称な通信 client側CPUの余剰 全体で数個の空間しかない
50. Cluster, Inc. All Rights Reserved. 50 2019年の構造 送信側と同じ処理を 受信側で繰り返す
51. Cluster, Inc. All Rights Reserved. 51 2020~2021: バーチャルSNS時代 バーチャルSNS & Mobile対応 空間個数は可変 一つの空間は小さい より対等な通信 client CPUが相対的に弱い
52. Cluster, Inc. All Rights Reserved. 52 2020~2021年の構造
53. Cluster, Inc. All Rights Reserved. 53 2020~2021年の構造: アバター以外も入れると 「ゲーム作成機能」 アイテム・空間状態の情報 サーバー側調停メカニズム ワールド・イベントの混在 権限モデル複雑化 → サーバー側処理が肥大化 一空間の人数増加・リッチ化 → 「O(N^2)問題」の顕在化 (Brokerの通信帯域がユーザー数の二乗で増える)
54. Cluster, Inc. All Rights Reserved. 54 Room Server (リアルタイム通信+計算ができる)独自のサーバーの実装コスト < (Pubsub + 追加モジュール) の維持コスト になったと判断 サービスを継続したまま どう移行するか？
55. Cluster, Inc. All Rights Reserved. 55 Room Server Phase 1 VerneMQ (Erlang)からhmq(Go)のsubsetに 既存コードから既存コードへの移行なので比較的安全 clusterで利用している部分のみを残す Phase 2 サーバー側で計算を行っているコードを徐々に統合
56. Cluster, Inc. All Rights Reserved. 56 そして時が経ち… そして時が経ち…
57. Cluster, Inc. All Rights Reserved. 57 2022年現在の構造 Room Server内部 通信・アプリケーション層分離 タスク・スケジューラー概念 3年で数百回のリリース 数十個の別の機能・リファクタ としての結果
58. Cluster, Inc. All Rights Reserved. 58 実装上の観点 実装上の観点
59. Cluster, Inc. All Rights Reserved. 59 詰まない設計 「詰まない」無停止で任意の実装へ移行可能 バージョン混在はプログラムの境界でのみ発生 プログラム1 → データ (ネットワーク or ストレージ) → プログラム2 dual-read or dual-writeを経由することで移行
60. Cluster, Inc. All Rights Reserved. 60 具体的に役に立つもの データ形式の透明性・シリアライズ処理の制御可能性 古いデータと新しいデータの両対応・相互変換 不明なデータ or 制御不可能な部分では 必ずデータの切り捨て and/or ダウンタイムが発生する fieldの追加・削除が両方可能な汎用データ形式 e.g. ZeroFormatter → Protocol Buffer (ZFはfield削除ができない)
61. Cluster, Inc. All Rights Reserved. 61 具体的に役に立つもの 2 短いリリースサイクル & Feature Flag app: 毎週 / server: 毎日 単一機能が分割リリースされると互換性考察が困難に → Feature Flagで機能ごとのON/OFF release cycleを最小単位として 各機能が好きな期間でリリース 空間種別に応じたON/OFF制御 緊急(incident)時には高速にON/OFF可能
62. 62 4. 歴史・設計思想 4.b. 展望
63. Cluster, Inc. All Rights Reserved. 63 発生してきたデザインパターン バイナリの境界をまたぐデータは普遍的・制御可能に データを介した、ユースケース実装と最適化実装の分離 短期的な実行効率を犠牲にして疎結合性を得る 分散計算システムとしてのclient+server client: viewer & worker server: router & controller e.g. 物理演算やIKはtransformを介して分散 & 隔離 e.g. glTFベース形式でのアセット表現
64. Cluster, Inc. All Rights Reserved. 64 選択 ブラックボックスから得られるメリット vs. 制御可能性 (ソースコードがあっても全部を理解できる 組織規模が無ければ実質ブラックボックス) 限られたリソースをどの部分を「透明化」するのに使うか UGCデータの自由度 vs. 互換性 ユーザーはいずれ全ての穴をつく 固い設計: 自由度のコスパ悪い (短期) vs. 柔い設計: 自由度のコスパ良い (短期) + 確率的に{データ互換性喪失, 後の高い開発コスト} (長期)
65. Cluster, Inc. All Rights Reserved. 65 長期的に見ると… ユーザーが作りたいと欲するものをカバーする 普遍性が高い (自由度が高い) & シンプル (実装コストが低い) な要素を見つけていくプロセス・試行錯誤 cf. 既存のゲームエンジン ネットワーク経由の同期が考慮されてない (e.g. 多くの物理演算、パーティクル、シェーダーなど) → multi-player nativeな空間の要素を発掘していく
66. Cluster, Inc. All Rights Reserved. 66 指針 計算 通信 ストレージ 認知的類似度 応答時間 … 計算機の物理 認知 / 人間の物理 サービス内容は右を拘束条件として決まる 左の配置最適化問題 + 変化に対する柔軟性
67. Cluster, Inc. All Rights Reserved. 67 システムの分解の例: ベースライン 現在のclusterの 基本構成 青: ストレージ (含メモリ) 赤: 計算 線: 通信 ※ GPU-ユーザー間は非圧縮の1080p想定 I/OのDMAは無視している
68. Cluster, Inc. All Rights Reserved. 68 システム構造の例: server-side リダクション 3Dデータのserver-side リダクション 以下のトレード client計算↓↓ clientストレージ↓ client-server通信↓↓ server計算↑ serverストレージ↑
69. Cluster, Inc. All Rights Reserved. 69 システム構造の例: cloud rendering 3Dデータのserver-side リダクション 以下のトレード client計算↓↓ clientストレージ↓↓ client-server通信↑↑ server計算↑↑ serverストレージ↑↑
70. Cluster, Inc. All Rights Reserved. 70 未来 オブジェクト同期 汎用的な負の遅延要素 World Craft ITM形式 見た目+振る舞い セキュリティ境界 cf. Smalltalk 遅延を打ち消す要素 cf. 位置・速度の外挿 Machine Learningが どこまでいけるか
71. 71 5. まとめ / メタバース究極の問い
72. Cluster, Inc. All Rights Reserved. 72 究極の問い: 「完全性」 pt 1 ソーシャル・インタラクティブ空間の 「完全」な表現形式はあるか？ 人類がやりたいことが概ね何でもできる場 e.g. 動画 非インタラクティブ2Dのほぼ「完全」な表現形式 (解像度や色空間の向上は続いているが) プログラムではなくデータなので • 自動変換・編集・様々な商品形態が充実 • 後からソーシャル性を付与する余地もある
73. Cluster, Inc. All Rights Reserved. 73 究極の問い: 「完全性」 pt 2 e.g. プログラム・ゲーム インタラクティブ性の「完全」な表現形式 • 自由度 ≒ (Turing完全な)計算 + API プログラムなので、組み合わせ・編集などがほぼ不可能 (それぞれが独立した世界 → ソーシャル要素が小さい) e.g. メタバース (未解決問題) ソーシャル & インタラクティブ インタラクティブ性のモジュラー化・データ化とその流通
74. Cluster, Inc. All Rights Reserved. 74 最後に サービスを5年間運用してきて… データ形式を制御下に置くと救われることが多い が、救いを捨てることでサービス価値を増やせるときもある 未知を受け入れる設計と運用 高速なリリース・継続的改善 普遍的なこと(理論・物理)に目を向ける (一緒に) 豊かなバーチャル空間を実現しましょう！
75. 75 Thanks for Watching!