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が利用可能なあらゆるデバイスに対して、作品を自動かつインテリジェントに届けられるプラットフォームを構築しています。 コミュニティがこの技術を使ってどのような作品を作るのか、今から心待ちにしています。