Roblox（ロブロックス）には、シンプルなミニゲームから高精細な3Dアセットであふれる広大なオープンワールドまで、数百万ものコンテンツがあります。 当社の目標は、クリエーターの方々が想像する多彩で充実した体験を、幅広いユーザーデバイスでサポートすることです。そのためには、エンジンやコンテンツ配信システム、インフラの革新が必要です。 スケーラブルで軽量なインタラクティブモデル（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万人のアクティブユーザーが、さまざまなデバイスで遊んだり探索したり、最終的にコンテンツをストリーミングしたりすることを考えると、コンテンツの配信や表示方法の最適化余地は非常に大きいです。¹

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は異なる詳細レベルの複数のバージョンを生成します。 これは、3Dメッシュの三角形数を大幅に減らしたバージョンを作成したり、テクスチャをより低解像度で生成したりすることを意味します。これは、従来のLoD技術で個別のメッシュやテクスチャアセットに対して行う方法と同じです。 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は多段階開発の第一歩に過ぎず、クリエーターの方々がこの技術をワークフローに組み込む展開に注目しています。 今後、SLIMを拡張する方向性として、大きく2つの領域を検討しています。

SLIM化できる対象の拡大

まずは、クリエーターの方々がStudioで指定した静的モデルから始めますが、将来的にはRoblox上で最も複雑なモデルの一部、プラットフォームのアバターも最適化可能になる予定です。 アバターは、関連するアニメーションや重ね着、アクセサリなどを含むため、クリエーターの方々にとって予測の難しい要素となり得ます。 アバターをSLIM化できるようにすることで、エンジンは個々のアバターモデルが使用するリソースを効果的に制限できるようになります。

さらに、動的モデルの変更に対してもクリエーターの方々がSLIMを活用できるようにすることを目指しています。 たとえば、サーバーがモデルに対して動的に変化を加えられる場合（ドアが開く、パーツが破壊されるなど）でも、いくつかの工夫により、クライアントが同じ軽量化表現を再利用できるようになります。

SLIMパイプラインの最適化

エンジンに新しい柔軟性をもたらすエンドツーエンドのパイプラインを構築した今、パイプライン自体をよりスマートに、高速かつ効率的にすることにも注力しています。 具体的には以下の取り組みを進めています。

• テクスチャ再アトラス化：複数のモデルテクスチャを1つの最適化されたテクスチャシートにインテリジェントにまとめます。

• 自動セグメンテーション：ワールドの意味的・空間的理解を用いて、SLIM化に適したモデルを自動的に特定します。

• より軽量な表現：レイテンシーの影響を受けにくい動的オブジェクトについては、クライアント上でほぼリソースを消費せずレンダリングできる2D表現の生成を検討しています。

• 階層的SLIM：SLIMモデルを入れ子構造にすることで、インスタンス群全体を簡略化し、エンジンが粒度の異なるレベルを動的に選択できるようにします。たとえば、1本の木から森林、さらに森林や他のオブジェクトを含む土地全体まで対応可能です。

• 高解像度化：現在はパフォーマンス向上のために解像度を下げる最適化に注力していますが、将来的には、このシステムにより、クリエーターの方々のオリジナルの芸術的意図を保持したまま、将来のハードウェア向けにアセットの高解像度化も可能になります。 この新しいアーキテクチャにより、エンジンが現実世界のシミュレーションをより高度に行えるようになるにつれて、使用する表現も継続的にアップグレードできるようになります。 

SLIMは、Harmonyやその他のストリーミング・コンテンツ配信アーキテクチャと組み合わせることで、より広大で詳細なワールドをより多くのプレイヤーに提供するという当社のビジョンにおける大きな飛躍となります。 エンジン、コンテンツ配信、クラウドインフラの緊密な統合と、数百万のクリエーターの方々による膨大なコンテンツベースにより、ユーザー体験全体を向上させる深く相互接続されたシステムを構築できます。 エンジンが現実世界のシミュレーションをより高度に行えるようになるにつれて、使用する表現も継続的にアップグレードできるようになります。 現在はパフォーマンス向上のために解像度を下げる最適化に注力していますが、近い将来、この同じシステムにより、クリエーターの方々のオリジナルの芸術的意図を維持したまま、将来のハードウェア向けにアセットを高解像度化することも可能になります。

当社は、クリエーターの方々の意図を尊重するだけでなく、Robloxが利用可能なあらゆるデバイスに対して、作品を自動かつインテリジェントに届けられるプラットフォームを構築しています。 コミュニティがこの技術を使ってどのような作品を作るのか、今から心待ちにしています。