Tweet
Tweet

Slide 1

Slide 1 text

3Dデータを持ち込める cross-platformメタバースの 技術的挑戦 xyx Engineering Manager | Architect

Slide 2

Slide 2 text

Cluster, Inc. All Rights Reserved. 2 xyx Engineering Manager兼Architect @ cluster 経歴 2015~: Google, Software Engineer 2019~: Cluster, Unity Engineer 2022~: Cluster, EM / Architect 誰？ @xanxys_

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

Cluster, Inc. All Rights Reserved. 4 セッション内容 1. メタバースの性質 2/3. データ配信・同期 4. 歴史・設計思想

Slide 5

Slide 5 text

5 1. メタバースとは 1.a. サービス概要

Slide 6

Slide 6 text

Cluster, Inc. All Rights Reserved. 6 基本構造

Slide 7

Slide 7 text

Cluster, Inc. All Rights Reserved. 7 基本的な体験: ワールド + アバター

Slide 8

Slide 8 text

Cluster, Inc. All Rights Reserved. 8 より簡単にアバターを手に入れる 他社モバイルアプリ とのアバター連携 cluster in-app アバター作成機能

Slide 9

Slide 9 text

Cluster, Inc. All Rights Reserved. 9 より簡単にワールドを作る: World Craft cluster in-app ワールド作成機能

Slide 10

Slide 10 text

10 1. メタバースとは 1.b. サービスの基本動作原理

Slide 11

Slide 11 text

Cluster, Inc. All Rights Reserved. 11 全体構造

Slide 12

Slide 12 text

Cluster, Inc. All Rights Reserved. 12 1クライアントに注目

Slide 13

Slide 13 text

Cluster, Inc. All Rights Reserved. 13 同期される物の種類 アバター ワールド 3Dモデルデータ 位置・姿勢 音声・コメント 3Dモデルデータ アイテム位置情報 アイテム・プレイヤー状態

Slide 14

Slide 14 text

Cluster, Inc. All Rights Reserved. 14 クライアント - Room Server 基本的にはpubsub 非同期 物理演算は分散 Item「所有権」 はたまに移動する e.g. 操作時・切断時

Slide 15

Slide 15 text

Cluster, Inc. All Rights Reserved. 15 データがどこからやってくるか UGC

Slide 16

Slide 16 text

Cluster, Inc. All Rights Reserved. 16 基本的動作原理 - まとめ ITM (World Craftアイテム) 位置・姿勢情報 音声 アバター ワールド モデルデータ リアルタイム 状態 VRM Unity Asset Bundle (Creator Kitワールド) アイテム位置 状態

Slide 17

Slide 17 text

Cluster, Inc. All Rights Reserved. 17 基本的動作原理 - まとめ ITM (World Craftアイテム) 位置・姿勢情報 アバター ワールド モデルデータ リアルタイム 状態 VRM Unity Asset Bundle (Creator Kitワールド) アイテム位置 状態 section 2 アバター3Dデータ配信 section 3 アバター状態同期 section 4: 歴史・設計思想

Slide 18

Slide 18 text

18 2. アバター3Dデータ配信

Slide 19

Slide 19 text

Cluster, Inc. All Rights Reserved. 19 ここの話

Slide 20

Slide 20 text

Cluster, Inc. All Rights Reserved. 20 アバターのデータサイズ 2019年時点の制限 2022年時点: 「無制限」 (内部的validationはある) ハイエンドVR向けの最適化されてないデータ 一部パラメータが←の数倍程度 生の一体のメモリフットプリント 数10MB~200MB程度 drawcall / 物理演算(揺れ物)も多い

Slide 21

Slide 21 text

Cluster, Inc. All Rights Reserved. 21 VRMの圧縮 GPU依存の圧縮画像形式の利用 VRMの中の画像は標準的にはPNG 展開後は生bitmapなので大きい & PNG展開処理が重い → ASTC / BC7にサーバー側で変換して配信 データそのもののリダクション 自動アトラス化・ポリゴンリダクション

Slide 22

Slide 22 text

Cluster, Inc. All Rights Reserved. 22 画像圧縮形式 Texture2D.LoadRawTextureData() で直接ロード可能 PSNR (Peak Signal-to-Noise Ratio)で 圧縮による劣化を評価 cluster内のテクスチャのサンプリング評価 (N=1391) 40dB (肉眼ではほぼ判別不能) → ASTC 4x4, BC7を採用 1 byte / px

Slide 23

Slide 23 text

Cluster, Inc. All Rights Reserved. 23 データそのもののリダクション 複数の圧縮「プロファイル」を定義 以下のような属性からプロファイルが選択される ● イベントにおけるユーザーのロール ● カメラからの相対位置・向き ● ユーザーの品質設定 ● ハードウェアの違い

Slide 24

Slide 24 text

Cluster, Inc. All Rights Reserved. 24 プロファイルの内部構成 各プロファイルは多段のoptimizerからなる ● デバッグが容易 ● コードをほぼ書かずに最適化の試行錯誤が可能 ● プロファイルを増やすのが容易 ● 中間形式もVRMなので変換オーバーヘッドがある VRM

Slide 25

Slide 25 text

Cluster, Inc. All Rights Reserved. 25 optimizerの一覧 メッシュ・テクスチャデータ削減系 アトラス化・resize ポリゴン数削減 マテリアル統合 … 追加attribute削除系 ブレンドシェイプ削除 揺れ物削除 …

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

Cluster, Inc. All Rights Reserved. 27 実データの面白い事例 面白い事例

Slide 28

Slide 28 text

Cluster, Inc. All Rights Reserved. 28 UGCならでは事例: アバター改変文化 販売者 身体部分・服・アクセサリなどを別の作者が販売 (unitypackage形式で流通) 購入者 unity上での組み合わせ 人によってはblender/photoshopで編集 複数のボーン構造 & skinned meshが混在 大量のマテリアル

Slide 29

Slide 29 text

Cluster, Inc. All Rights Reserved. 29 UGCならでは事例: 巨大透明テクスチャ とあるアバター作成ツール 絵を描ける人向けのツール 長袖ワンピースの巨大メッシュ (プリセット) + テクスチャのアルファで「形状」を描く そのままメッシュ削減すると透明部分に ポリゴン数が使われてしまう → 透明部分のメッシュを削減の前に削除

Slide 30

Slide 30 text

Cluster, Inc. All Rights Reserved. 30 リリース後が本番 モニタリング・CS prodでの変換失敗の監視 ユーザーからの問い合わせ CI テストデータと Web-based 比較ツール

Slide 31

Slide 31 text

31 3. アバター状態同期

Slide 32

Slide 32 text

Cluster, Inc. All Rights Reserved. 32 ここの話

Slide 33

Slide 33 text

Cluster, Inc. All Rights Reserved. 33 ネタばれ 送出側client rootのtransform + humanoidの全52 boneのrotation + 表情系データ (最大) 15 Hzで送出 受信側client データを全員分受信してそのまま表示 なんで？？？ このセクションは 現在の運用に集中 歴史と経緯は 次のセクションを お楽しみに

Slide 34

Slide 34 text

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 それほど大きくはない

Slide 35

Slide 35 text

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を完全に復元できる

Slide 36

Slide 36 text

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が表す回転角度をθとすると…

Slide 37

Slide 37 text

Cluster, Inc. All Rights Reserved. 37 回転のコンパクトな表現: 精度削減 part2 解決策 wが0付近で精度が悪化するので、 quaternionを前処理して分布を調整する (いくつかあるが) Half-Angle Encodingという手法が シンプルさと処理の軽さのバランスが良い

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

Cluster, Inc. All Rights Reserved. 39 頻度の間引き encodingの切り替え + 頻度の間引き ● 手と身体で品質を使い分け ● 権限・相対位置に応じて品質制御 room serverがユーザーの位置情報を使って ↑の処理を行う 最終的には: worst-caseでも(下り)1Mb/s程度に

Slide 40

Slide 40 text

Cluster, Inc. All Rights Reserved. 40 未来 さらなる圧縮余地 ● {モデルデータ, humanoid}に基づく関節ごとの可動域 ● より高度な補間 + 時系列の圧縮 いずれも、ネットワーク帯域と ● CPU負荷 ● 複雑性 (処理そのもの + データ依存性) のトレードになる

Slide 41

Slide 41 text

41 4. 歴史・設計思想

Slide 42

Slide 42 text

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会議サービス 時代

Slide 43

Slide 43 text

Cluster, Inc. All Rights Reserved. 43 サービスの変遷 2020 2021 2022

Slide 44

Slide 44 text

Cluster, Inc. All Rights Reserved. 44 設計思想 動き続ける 生活空間であり、インフラである 変化に適応 メタバースの最終系はまだ定まってない 市場・ハードウェアの変化どちらも激しい コンテンツを作るのはユーザー 事前にテストしきってコンテンツ側でバグ回避は不可能 信頼性・自由度のトレードオフ

Slide 45

Slide 45 text

Cluster, Inc. All Rights Reserved. 45 事例 事例: Room Server + 同期

Slide 46

Slide 46 text

Cluster, Inc. All Rights Reserved. 46 伏線回収 送出側client rootのtransform + humanoidの全52 boneのrotation + 表情系データ (最大) 15 Hzで送出 受信側client データを全員分受信してそのまま表示 なんで？？？ このセクションは 現在の運用に集中 歴史と経緯は 次のセクションを お楽しみに

Slide 47

Slide 47 text

Cluster, Inc. All Rights Reserved. 47 そもそも 自分自身の アバター表示されるまで データフロー ひとつのclient

Slide 48

Slide 48 text

Cluster, Inc. All Rights Reserved. 48 そもそも2 何らかの方法で インターネット経由で 他者のアバターが表示される clientがいっぱいある

Slide 49

Slide 49 text

Cluster, Inc. All Rights Reserved. 49 2019: VRイベントプラットフォーム時代 VRイベントプラットフォーム 「演者」: 数人しかいない・モーションクオリティ高 「一般参加者」: 数十人・モーションクオリティ低・喋らない PC前提・公式イベント主体 非対称な通信 client側CPUの余剰 全体で数個の空間しかない

Slide 50

Slide 50 text

Cluster, Inc. All Rights Reserved. 50 2019年の構造 送信側と同じ処理を 受信側で繰り返す

Slide 51

Slide 51 text

Cluster, Inc. All Rights Reserved. 51 2020~2021: バーチャルSNS時代 バーチャルSNS & Mobile対応 空間個数は可変 一つの空間は小さい より対等な通信 client CPUが相対的に弱い

Slide 52

Slide 52 text

Cluster, Inc. All Rights Reserved. 52 2020~2021年の構造

Slide 53

Slide 53 text

Cluster, Inc. All Rights Reserved. 53 2020~2021年の構造: アバター以外も入れると 「ゲーム作成機能」 アイテム・空間状態の情報 サーバー側調停メカニズム ワールド・イベントの混在 権限モデル複雑化 → サーバー側処理が肥大化 一空間の人数増加・リッチ化 → 「O(N^2)問題」の顕在化 (Brokerの通信帯域がユーザー数の二乗で増える)

Slide 54

Slide 54 text

Cluster, Inc. All Rights Reserved. 54 Room Server (リアルタイム通信+計算ができる)独自のサーバーの実装コスト < (Pubsub + 追加モジュール) の維持コスト になったと判断 サービスを継続したまま どう移行するか？

Slide 55

Slide 55 text

Cluster, Inc. All Rights Reserved. 55 Room Server Phase 1 VerneMQ (Erlang)からhmq(Go)のsubsetに 既存コードから既存コードへの移行なので比較的安全 clusterで利用している部分のみを残す Phase 2 サーバー側で計算を行っているコードを徐々に統合

Slide 56

Slide 56 text

Cluster, Inc. All Rights Reserved. 56 そして時が経ち… そして時が経ち…

Slide 57

Slide 57 text

Cluster, Inc. All Rights Reserved. 57 2022年現在の構造 Room Server内部 通信・アプリケーション層分離 タスク・スケジューラー概念 3年で数百回のリリース 数十個の別の機能・リファクタ としての結果

Slide 58

Slide 58 text

Cluster, Inc. All Rights Reserved. 58 実装上の観点 実装上の観点

Slide 59

Slide 59 text

Cluster, Inc. All Rights Reserved. 59 詰まない設計 「詰まない」無停止で任意の実装へ移行可能 バージョン混在はプログラムの境界でのみ発生 プログラム1 → データ (ネットワーク or ストレージ) → プログラム2 dual-read or dual-writeを経由することで移行

Slide 60

Slide 60 text

Cluster, Inc. All Rights Reserved. 60 具体的に役に立つもの データ形式の透明性・シリアライズ処理の制御可能性 古いデータと新しいデータの両対応・相互変換 不明なデータ or 制御不可能な部分では 必ずデータの切り捨て and/or ダウンタイムが発生する fieldの追加・削除が両方可能な汎用データ形式 e.g. ZeroFormatter → Protocol Buffer (ZFはfield削除ができない)

Slide 61

Slide 61 text

Cluster, Inc. All Rights Reserved. 61 具体的に役に立つもの 2 短いリリースサイクル & Feature Flag app: 毎週 / server: 毎日 単一機能が分割リリースされると互換性考察が困難に → Feature Flagで機能ごとのON/OFF release cycleを最小単位として 各機能が好きな期間でリリース 空間種別に応じたON/OFF制御 緊急(incident)時には高速にON/OFF可能

Slide 62

Slide 62 text

62 4. 歴史・設計思想 4.b. 展望

Slide 63

Slide 63 text

Cluster, Inc. All Rights Reserved. 63 発生してきたデザインパターン バイナリの境界をまたぐデータは普遍的・制御可能に データを介した、ユースケース実装と最適化実装の分離 短期的な実行効率を犠牲にして疎結合性を得る 分散計算システムとしてのclient+server client: viewer & worker server: router & controller e.g. 物理演算やIKはtransformを介して分散 & 隔離 e.g. glTFベース形式でのアセット表現

Slide 64

Slide 64 text

Cluster, Inc. All Rights Reserved. 64 選択 ブラックボックスから得られるメリット vs. 制御可能性 (ソースコードがあっても全部を理解できる 組織規模が無ければ実質ブラックボックス) 限られたリソースをどの部分を「透明化」するのに使うか UGCデータの自由度 vs. 互換性 ユーザーはいずれ全ての穴をつく 固い設計: 自由度のコスパ悪い (短期) vs. 柔い設計: 自由度のコスパ良い (短期) + 確率的に{データ互換性喪失, 後の高い開発コスト} (長期)

Slide 65

Slide 65 text

Cluster, Inc. All Rights Reserved. 65 長期的に見ると… ユーザーが作りたいと欲するものをカバーする 普遍性が高い (自由度が高い) & シンプル (実装コストが低い) な要素を見つけていくプロセス・試行錯誤 cf. 既存のゲームエンジン ネットワーク経由の同期が考慮されてない (e.g. 多くの物理演算、パーティクル、シェーダーなど) → multi-player nativeな空間の要素を発掘していく

Slide 66

Slide 66 text

Cluster, Inc. All Rights Reserved. 66 指針 計算 通信 ストレージ 認知的類似度 応答時間 … 計算機の物理 認知 / 人間の物理 サービス内容は右を拘束条件として決まる 左の配置最適化問題 + 変化に対する柔軟性

Slide 67

Slide 67 text

Cluster, Inc. All Rights Reserved. 67 システムの分解の例: ベースライン 現在のclusterの 基本構成 青: ストレージ (含メモリ) 赤: 計算 線: 通信 ※ GPU-ユーザー間は非圧縮の1080p想定 I/OのDMAは無視している

Slide 68

Slide 68 text

Cluster, Inc. All Rights Reserved. 68 システム構造の例: server-side リダクション 3Dデータのserver-side リダクション 以下のトレード client計算↓↓ clientストレージ↓ client-server通信↓↓ server計算↑ serverストレージ↑

Slide 69

Slide 69 text

Cluster, Inc. All Rights Reserved. 69 システム構造の例: cloud rendering 3Dデータのserver-side リダクション 以下のトレード client計算↓↓ clientストレージ↓↓ client-server通信↑↑ server計算↑↑ serverストレージ↑↑

Slide 70

Slide 70 text

Cluster, Inc. All Rights Reserved. 70 未来 オブジェクト同期 汎用的な負の遅延要素 World Craft ITM形式 見た目+振る舞い セキュリティ境界 cf. Smalltalk 遅延を打ち消す要素 cf. 位置・速度の外挿 Machine Learningが どこまでいけるか

Slide 71

Slide 71 text

71 5. まとめ / メタバース究極の問い

Slide 72

Slide 72 text

Cluster, Inc. All Rights Reserved. 72 究極の問い: 「完全性」 pt 1 ソーシャル・インタラクティブ空間の 「完全」な表現形式はあるか？ 人類がやりたいことが概ね何でもできる場 e.g. 動画 非インタラクティブ2Dのほぼ「完全」な表現形式 (解像度や色空間の向上は続いているが) プログラムではなくデータなので ● 自動変換・編集・様々な商品形態が充実 ● 後からソーシャル性を付与する余地もある

Slide 73

Slide 73 text

Cluster, Inc. All Rights Reserved. 73 究極の問い: 「完全性」 pt 2 e.g. プログラム・ゲーム インタラクティブ性の「完全」な表現形式 ● 自由度 ≒ (Turing完全な)計算 + API プログラムなので、組み合わせ・編集などがほぼ不可能 (それぞれが独立した世界 → ソーシャル要素が小さい) e.g. メタバース (未解決問題) ソーシャル & インタラクティブ インタラクティブ性のモジュラー化・データ化とその流通

Slide 74

Slide 74 text

Cluster, Inc. All Rights Reserved. 74 最後に サービスを5年間運用してきて… データ形式を制御下に置くと救われることが多い が、救いを捨てることでサービス価値を増やせるときもある 未知を受け入れる設計と運用 高速なリリース・継続的改善 普遍的なこと(理論・物理)に目を向ける (一緒に) 豊かなバーチャル空間を実現しましょう！

Slide 75

Slide 75 text

75 Thanks for Watching!