SLIMのご紹介:スケーラブルで軽量なインタラクティブモデル
軽量レンダリングコンポジットの力を活用し、あらゆるデバイス向けに、より大規模で詳細な世界を構築する

Robloxには、シンプルなミニゲームから、高精細な3Dアセットで満たされた広大なオープンワールドまで、数百万もの体験が存在します。 私たちの目標は、クリエイターが構想する、ますます高密度かつ複雑化する体験を、幅広いユーザーデバイスでサポートすることです。そのためには、エンジン、コンテンツ配信システム、インフラストラクチャにおけるイノベーションが不可欠です。「Scalable Lightweight Interactive Models(SLIM)」は、パフォーマンスを損なうことなくクリエイターが壮大な芸術的ビジョンを実現できるようにする、多角的な開発プロジェクトの一環です。
SLIMにより、クリエイターはRobloxエクスペリエンス内のあらゆるオブジェクトの軽量な表現を自動的に生成できるようになり、堅牢でシームレスな世界をレンダリングするためにクライアントが必要とするドローコール、三角形、データモデルインスタンスの数を最小限に抑えます。SLIMは、当社のストリーミングモデルにコンテンツを最適化する強力な新しい手段を提供し、ハイエンドのゲーミングPCを持つユーザーも、ローエンドのモバイルデバイスを持つユーザーも、それぞれのデバイスが処理できる最高品質で同じ体験を共有できるようにします。

インスタンスストリーミングおよびSLIMなし | インスタンスストリーミングおよびSLIMを使用 | |
クライアントデータモデルのインスタンス | 159,745 | 92,536 |
三角形 | 2,000万 | 335万 |
描画コール | 2,402 | 1,454 |
ストリーミングの2つの柱:インスタンスとアセット
お気に入りのストリーミングサービスで映画を視聴する際、デバイスは再生開始前にファイル全体をダウンロードすることはありません。すぐに視聴を開始できるだけのデータをダウンロードし、その後も体験が中断されないよう、次の数秒分のデータを継続的にダウンロード(またはバッファリング)します。 低スペックのデバイスや低速な接続環境でストリーミングを行う場合、プラットフォームは自動的に適応し、高画質のコンテンツをストリーミングするのに十分なデータをダウンロードしている間、低画質のコンテンツを送信します。
Robloxも同様の概念を用いてコンテンツをオンザフライでストリーミングしていますが、高精細な3Dシミュレーションを表現するために必要なデータには、独自の課題があります。動画は単一の視点から視聴される直線的なタイムラインを持つのに対し、Robloxの体験には、ユーザーが制御する様々な視点から閲覧可能な、多種多様なアセットで満たされた広大なインタラクティブな3Dワールドが含まれています。 さらに、1日あたり1億5,150万人のアクティブユーザーが、多種多様なデバイスからプレイ、探索、そして最終的にコンテンツをストリーミングしていることを考慮すると、コンテンツの配信と表示方法を最適化する可能性は極めて大きいと言えます。1
ユーザーがRoblox上で目にするものすべて――車、木、アバター、建物など――は、エンジン内で複数のインスタンスとして表現されています。例えば、実際に運転できる車は、バンパー、ドア、ホイールなどのインスタンスに分解されます。各インスタンスは、3Dメッシュ、テクスチャ、アニメーション、オーディオといった複数のアセットを使用して、エクスペリエンス内で構築されます。
Robloxにおけるストリーミングのほぼすべては、「インスタンスストリーミング」と「アセットストリーミング」という2つの主要な技術に分類されます。
- インスタンスストリーミングは、ユーザーのデバイスにストリーミングする必要があるインスタンスを決定します。ユーザーがまだ見たり操作したりできないエクスペリエンスの一部をストリーミングする必要はありません。上記の例では、近くの建物を表すインスタンスのみがクライアントにストリーミングされます。
- アセットストリーミングは、ストリーミングされるインスタンスの品質を決定します。ユーザーが細部を識別できないほど遠くにある山の高解像度4Kテクスチャをダウンロードする必要はありません。上の画像では、遠くにある建物や画面上の占有面積が小さい建物には、デシメーションされたメッシュと低解像度のテクスチャが使用されています。
この処理の中枢となるのが「Harmony」と呼ばれるシステムで、これは各ユーザーの利用可能なリソースを毎フレーム監視します。Harmonyは、デバイスのメモリ、GPUおよびCPUの負荷、ネットワーク帯域幅に基づいて、インスタンスとアセットの両方のストリーミングを調整し、最適な体験を提供します。ハイエンドのゲーミングPCの場合、Harmonyはすべてを最高品質に設定します。一方、通信環境が不安定なモバイルデバイスでは、ユーザー体験をスムーズに保つために自動的に品質を下げます。
チームは、ポッドキャスト『Tech Talks』の第30回エピソードで、ストリーミング、クラウドトランスコーディング、およびSLIMの背後にある技術について議論しました。
SLIM: スケーラブルで軽量なインタラクティブモデル
SLIMの核心となるアイデアはシンプルでありながら強力です。SLIMは、クリエイターの世界にあるあらゆるオブジェクトやモデルについて、最適化された軽量な表現を自動的に複数生成し、それらをサーバー上に保存して実行時に取得できるようにします。これにより、各ユーザーのクライアントは、デバイスの利用可能なリソースに応じて、元のインスタンスやアセットのレンダリングと、軽量なSLIM表現のいずれかとの間で動的に切り替えることができます。
SLIMは、軽量な表現を生成するために主に2つの手法を使用します:
1. 合成
まず、SLIMは複数のパーツを統合してパーツ数を削減します。下の図の自動車の場合、本来なら112個のメッシュと24枚のテクスチャが必要ですが、その軽量表現では1つのメッシュと4枚のテクスチャだけで済む可能性があります。この合成プロセスは、エンジンが最終的にコンテンツをレンダリングする方法に合わせて精密に調整されており、オブジェクト内の見えないジオメトリを排除し、レンダリングに必要なドローコールの数を削減します。

2. 詳細度(LoD)
モデルの合成後、SLIMは異なる詳細度(LoD)を持つ複数のバージョンを生成します。これは、従来のLoD技術を用いて個々のメッシュやテクスチャアセットを処理する場合と同様に、三角形の数を大幅に減らした3Dメッシュのバージョンを作成し、はるかに低い解像度でテクスチャを生成することを意味します。SLIMモデルには各基底インスタンスの個別の座標系が存在するため、これらの技術はSLIMモデルに適用することでさらに最適化が可能です。これにより、クリエイターがこれらのアセットをどのように組み合わせてレンダリングすることを意図していたか、その完全な文脈を把握することができます。 この知識を基に、SLIM を使用することで、不要なディテールをどこで削除し、ユーザーが気づくようなディテールをどこに残すべきかについて、より的確な判断を下すことができます。

適切なタイミングで適切な表現を
オブジェクトの複数の表現を作成した後、SLIMは特定のユーザーのデバイスに対してどの表現を使用するか、あるいは従来のレンダリング技術を使用するかを決定する必要があります。システムは世界を3つの異なる領域に分割します。これらの領域を簡単にイメージするには、プレイヤーを中心に外側へ広がる同心円状の詳細領域を想像するとよいでしょう。

HH領域(ヘビーウェイトインスタンス、ヘビーウェイトレンダリング)
HH領域では、完全なヘビーウェイトインスタンスがサーバーからクライアントのデータモデルへストリーミングされ、クライアントが各インスタンスに対してダウンロードおよびレンダリングする具体的なアセット表現を決定します。この領域でもメッシュのLoDやテクスチャのミップマップを用いてスケーリングは可能ですが、コンポジティングは行われません。SLIM導入以前は、エクスペリエンスにストリーミングされたすべてのインスタンスがこのようにレンダリングされていました。
HL領域(ヘビーウェイトインスタンス、ライトウェイトレンダリング)
HL領域は、HH領域とLL領域の中間に位置します。この領域では、クライアントはデータモデル内にヘビーウェイトインスタンスを保持していますが、フルレンダリングパイプラインとSLIMパイプラインのいずれかを使用してレンダリングを行うかを選択できます。この領域は、ユーザーがネットワーク遅延に遭遇した場合でも、HH領域とLL領域の間でシームレスな移行を保証するように適応します。 HH領域とHL領域の移行点は動的に変化するため、リソース需要がどちらの方向に急増しても、Harmonyは即座にスケールアップまたはスケールダウンすることができます。
LL領域(軽量インスタンス、軽量レンダリング)
LL領域では、クライアントはSLIMモデルの座標系を定義するために必要なインスタンスの超軽量な表現と、必要最小限のメタデータのみをストリーミングします。この領域では、すべてのインスタンスやアセットではなく、軽量に合成されたSLIMモデルのみがレンダリングされます。LL領域では、すべてのヘビーウェイトインスタンスをストリーミングし、従来のレンダリングパイプラインを使用する場合と比較して、必要な三角形数やドローコールが大幅に少なく、ユーザーのデバイス上のメモリ使用量も削減されます。
このリージョン技術により、クライアントは、すべてのヘビーウェイトなインスタンスやアセットを一度に使用する際の計算コストを負担することなく、常に可視領域全体をレンダリングできます。遠方のオブジェクトは高度に最適化された軽量な表現であり、ユーザーが近づくにつれて高精細なモデルに置き換えられます。SLIMがコンポジットや複数のスケーリングされたLoDモデルを作成できる機能により、Harmonyは各ユーザーのデバイスに合わせてアセットの品質を最適化するための手段をさらに多く持つことができます。
これらすべてが組み合わさることで、プレイヤーは完全に没入感を味わうことができ、遷移点やディテールの変化に気づくことはないはずです。
未来:SLIMの今後の展望
SLIMは多段階にわたる旅の第一歩に過ぎず、クリエイターがこの技術をワークフローにどのように組み込んでいくのか、私たちは楽しみにしています。将来的には、主に2つの方向でSLIMの拡張を検討しています。
SLIM化可能な対象の拡大
まずはクリエイターがStudioで指定する静的モデルから着手していますが、将来的には、Roblox上で最も複雑なモデルの一つであるプラットフォームアバターの最適化も可能になる予定です。アバターは、関連するアニメーション、重ね着、アクセサリーなどすべてを含め、クリエイターにとって予測不可能な変数となり得ます。アバターをSLIMの対象とすることで、エンジンが個々のアバターモデルが使用するリソースを効果的に制限できるようになります。
将来的には、動的モデルの変更にもSLIMを活用できるオプションをクリエイターに提供したいと考えています。サーバー側が能動的に変更を加える(例:ドアが開く、部品が破壊される)モデルであっても、いくつかの巧妙な手法を用いることで、クライアント側では同じ軽量な表現を再利用できるような仕組みを想定しています。
SLIMパイプラインの最適化
エンジンに新たな次元の柔軟性を提供するエンドツーエンドのパイプラインが整った今、私たちはパイプライン自体をよりスマートに、より高速に、そしてより効率的にすることにも注力しています。これには以下が含まれます:
- テクスチャの再アトラス化:複数のモデルテクスチャを、単一の最適化されたテクスチャシートにインテリジェントにパックします。
- 自動セグメンテーション:ワールドに対する意味的および空間的な理解を自動的に活用し、SLIM化に適した最適なモデルを特定します。
- より軽量な表現:レイテンシへの依存度が低い動的オブジェクトについては、クライアント側でのレンダリングに実質的にリソースを消費しない2D表現の生成を検討しています。
- 階層的SLIM:SLIMモデルを次々とネストさせることで、インスタンスのグループ全体を簡略化できるようにし、エンジンが粒度レベル(例:単一の木から森、さらには森やその他のオブジェクトで満たされた大陸全体まで)を動的に選択できるようにします。
- アップレズ:現在はパフォーマンス向上のための最適化に注力していますが、間もなくこの同じシステムにより、クリエイターの本来の芸術的意図を維持しつつ、将来のハードウェア向けにアセットの解像度を高めることが可能になります。この新しいアーキテクチャにより、エンジンの現実シミュレーション能力が向上するにつれて、使用される表現を継続的にアップグレードできるようになります。
SLIMは、Harmonyやその他のストリーミング・コンテンツ配信アーキテクチャと組み合わせることで、より多くのプレイヤーに向けて、より広大で詳細な世界を実現するという当社のビジョンにおいて、飛躍的な進歩をもたらします。エンジン、コンテンツ配信、クラウドインフラの緊密な統合に加え、数百万人のクリエイターによる膨大なコンテンツ基盤により、体験全体を向上させる、深く相互接続されたシステムを構築することが可能になります。 エンジンの現実シミュレーション能力が向上するにつれ、そこで使用される表現形式も継続的にアップグレードできるようになります。現在はパフォーマンス向上のための最適化に注力していますが、間もなくこの同じシステムにより、クリエイターの本来の芸術的意図を維持しつつ、将来のハードウェア向けにアセットの解像度を向上させることが可能になります。
私たちは、その芸術的意図を尊重するだけでなく、Robloxが利用可能な場所であればどこでも、多種多様なデバイスを通じて、あらゆるユーザーにクリエイターの作品をインテリジェントかつ自動的に配信できるプラットフォームを構築しています。コミュニティがこのプラットフォームを使ってどのような作品を生み出すのか、今から楽しみにしています。



