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

Transcript

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

   View Slide

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_
   

   View Slide

3. View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

31. 31
    3. アバター状態同期
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

41. 41
    4. 歴史・設計思想
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

75. 75
    Thanks
    for
    Watching!
    

    View Slide