League of Legendsフレームのレンダリング方法

こんにちは、私の名前はトニーアルブレヒトです。私は、 League of LegendsでSustainability Initiativeを実行している新しいRender Strikeチームの開発者の1人です。 私のチームは、 LoLレンダリングエンジンの改善を依頼され、喜んで作業を開始しました。 この記事では、エンジンの動作方法を説明します 。 それが良い基盤を築いてくれることを願っています。その基盤に基づいて、私たちが行っている変更について話をすることができます。 この記事は、レンダリングプロセスを段階的に研究するための良い言い訳になります。そのため、チームとして、内部で何が起こっているのかを完全に理解できます。



LoLがゲームの個々のフレームをどのように配置して表示するかを詳細に説明します（最も強力なマシンでは1秒あたり100回以上発生することを忘れないでください）。 ストーリーは主に技術的なものですが、レンダリングの経験がない人でも簡単に学べることを期待しています。 明確にするために、いくつかの難しい点を見逃しますが、詳細を知りたい場合は、[元の記事への]コメントにそれについて書いてください。



まず、私たちが持っているグラフィックライブラリについて少しお話します。 リーグは、幅広いプラットフォームで可能な限り効率的に動作する必要があります。 実際、現在、Windows XPは、ゲームを起動するOSの4番目に人気のあるバージョンです（Windows 7、10、および8のみがより人気があります）。 Windows XPでは、毎月1,000万のゲームセッションをプレイします。したがって、下位互換性を維持するには、DirectX 9をサポートする必要があり、提供する機能のみを使用する必要があります。 また、OS Xを実行しているマシンで、OpenGL 1.5の同等の機能セットを使用します（すぐに変更されます）。



それでは始めましょう！ まず、コンピューターが実際に画像をレンダリングする方法を学習します。

初心者向けのレンダリング

ほとんどのコンピューターには、CPU（中央処理装置）とGPU（グラフィックプロセッサー）があります。 CPUはゲームのロジックと計算を実行し、GPUはCPUから三角形とテクスチャのデータを受け取り、それらをピクセルとして画面に表示します。 シェーダーと呼ばれる小さなGPUプログラムを使用すると、レンダリング方法に影響を与えることができます。 たとえば、テクスチャを三角形に適用する方法を変更したり、テクスチャ内の各テクセルに対して計算を実行するようGPに指示したりできます。 したがって、単純に三角形にテクスチャをオーバーレイしたり、三角形に複数のテクスチャを追加または乗算したり、 エンボス加工、照明の計算、反射、さらには非常にリアルなスキンシェーダーなどのより複雑なプロセスを実行できます 。 すべての可視オブジェクトは、すべてのレンダリングが完了した後にのみ表示される非表示可能なフレームバッファーに描画されます。



例を見てみましょう。 以下は、「ワイヤー」フレームを構成する6,336個の三角形と、テクスチャーのないソリッドモデルで構成されるGarenの画像です。 このモデルはアーティストによって作成され、 Leagueエンジンがロードしてアニメーション化できる形式にエクスポートされました。 （Garenには非フラットシェーディングがあることに注意してください。これは、レンダリングの学習に使用されるアプリケーションの制限です）。







テクスチャのないこのモデルは退屈なだけでなく、認識可能なガレンを表示しません。 Garenaに命を吹き込むには、テクスチャを適用する必要があります。







ダウンロードする前に、GarenaテクスチャはDDSまたはTGAファイルとしてディスクに保存されます。これらは、それ自体がホラー映画のシーンのように見えます。 モデルに正しいオーバーレイを適用すると、次の結果が得られます。







すでに何かを始めています。 スキニンググリッドをレンダリングするシェーダーは、テクスチャを適用するだけでなく、これについては後で説明します。



これらは基本でしたが、 LoLはキャラクターモデルとテクスチャよりもはるかにレンダリングする必要があります。 次のシーンのレンダリングを構成する手順を見てみましょう。

レンダリングステージ0：戦争の霧

シーンの一部の描画を開始する前に、最初に戦争と影の霧を準備する必要があります（ああ、「霧と影」、なんて不吉なの！）。 戦争の霧は、中央処理装置によって128x128グリッドとして保存され、512x512の正方形のテクスチャにスケーリングされます（詳細については、記事「霧と戦争の物語」を参照してください）。 次に、このテクスチャをぼかして適用し、ゲームとミニマップの対応する領域を暗くします。

レンダリングステージ1：影

影は3Dシーンの不可欠な部分です。 それらがないと、オブジェクトは平らに見えます。 ミニオンまたはチャンピオンによってキャストされたように見えるシャドウを作成するには、光源のポイントからレンダリングする必要があります。 光源から影を落とすキャラクターまでの距離は、RGBコンポーネントのピクセルごとに保存され、アルファ透明度コンポーネントをゼロにします。 これは以下で見ることができます。 左側には、包囲された塔、手下、2人のチャンピオンのRGBに影の高さフィールドがあります。 右側には、アルファ透明度コンポーネントのみがあります。 これらのテクスチャは、影の詳細をより明確に表示するためにトリミングされています-下部の手先、上部の塔とチャンピオン。







最後に、影をぼかして滑らかな境界線を作成します（ 最近追加された最適化とともに、フレームレートが増加します）。 その結果、静的ジオメトリに適用して影の効果を得ることができるテクスチャを取得します。

レンダリングステージ2：静的ジオメトリ

霧と影の霧のテクスチャを準備したら、残りのシーンをフレームに描き始めます。 まず第一に、静的なジオメトリ（動きがないため、そう呼ばれます）。 このジオメトリは、戦争の霧と影の情報をそのメインテクスチャと結合し、次のシーンを提供します。







ミニオンの影と戦争の霧がシーンの端に向かってクリープしていることに注意してください。 レンダラーSummoner's Riftは、静的ジオメトリの動的シャドウをレンダリングしません。 メインの光源は動かないので、静的グリッドの影をテクスチャに焼き付けます。 これにより、アーティストはマップの外観をより細かく制御でき、生産性も向上します（静的グリッドの影のレンダリングは不要です）。 ミニオン、タワー、チャンピオンのみが影を落とします。

レンダリングステージ3：グリッドのスキニング

だから、私たちはレリーフと影を持っているので、それらにオブジェクトを課し始めることができます。 最初のミニオン、チャンピオン、タワー、つまり 現実的に移動する必要がある可動ジョイントを持つすべてのオブジェクト。







各アニメーショングリッドは、スケルトン（階層的に接続されたボーンのフレームワーク）と三角形のグリッド（上記のGarenの画像を参照）で構成されています。 各三角形の各頂点は1つまたは4つのボーンに接続されているため、ボーンを移動すると、頂点はスキンのように一緒に移動します。 したがって、それらは「スキニングネット」と呼ばれます。 才能あるアーティストは、すべてのオブジェクトのアニメーションとグリッドを作成し、ゲームの開始時にリーグにロードされる形式にエクスポートします。







上の画像は、Garenグリッドのすべてのボーンを示しています。 左の画像は、彼のすべての骨（名前付き）を示しています。 右側の画像では、選択した頂点が青で表示され、位置を制御するボーンとのリンクが黄色の線で表示されています。



スキンメッシュシェーダーは、スキンメッシュをフレームバッファーに描画するだけでなく、スケーリングされた深度を別のバッファーにレンダリングします。これは後でアウトラインを描画するために使用します。 さらに、スキニングシェーダーは、フレネル反射、放射光の計算、反射の計算、戦争の霧の照明の変更を行います。

レンダリングステージ4：輪郭（概要）

デフォルトでは、スキニングされたメッシュの輪郭が有効になっており、輪郭がより明確になります。 これにより、特にコントラストの低い領域で、背景のスキニングを使用してグリッドを強調表示できます。 以下の画像では、描写が無効（左）と有効（右）になっています。







輪郭は、前の段階からスケーリングされた深さを取得し、Sobelオペレーターによって処理して、スキングリッドにレンダリングする面を抽出することによって作成されます。 この操作は、グリッドごとに個別に実行されます。 複数のオブジェクトを同時にレンダリングできないGPUのテンプレートバッファーを使用するreturnメソッドもあります。

レンダリングステージ5：草

水と草のレンダリングに関係するものを判断するために、別のシーンを見てみましょう。



これは、水と草のないフレーム、静的な背景ジオメトリ、スキニングのあるいくつかのグリッドです。







草の影はすでに静的レリーフのテクスチャの一部であり、動的にレンダリングされないことに注意してください。 次に、草を追加します。







草の房は、実際には皮を剥いた網です。 これにより、キャラクターがキャラクターを通り抜けて、風からサモナーズゴージに心地よい揺れを与えながら、アニメーション化することができます。

レンダリングステージ6：水

草の後に、わずかにアニメーション化された水テクスチャのある半透明のメッシュを使用して水をレンダリングします。 次に、睡蓮の葉、石の周りや海岸近くのさざなみ、虫を追加します。 これらすべてのオブジェクトは、シーンに生命感をもたらすためにアニメーション化されます。



水の効果を高めるために（弱すぎる場合があります）、水の透明度を維持し、下のジオメトリを無視しました。 これは水の影響を強調しており、分析でそれらをよりよく考慮することができます。







すべてのリップルを「ワイヤ」フレームとして選択すると、次のようになります。







石や睡蓮の周りだけでなく、川のほとりに沿った水の影響をはっきりと見ることができます。



通常のレンダリングとアニメーションでは、水は次のようになります。

レンダリングステージ7：デカール

草と水を適用した後、デカルを追加します。たとえば、下図のタワー範囲インジケーターなど、地形に重ねられた平らなテクスチャーを備えた単純な幾何学的要素です。

レンダリングステージ8：特別な輪郭

ここでは、次の図の塔の輪郭の場合のように、マウスイベントまたは特別なアクティブ化状態によって含まれるより太い輪郭を扱います。 これは、スキナブルグリッドが作成されたのとほぼ同じ方法で行われますが、ここでは輪郭をぼかして太くします。 この選択は、レンダリングプロセスの後半で実行され、既に適用されているエフェクトと重複する可能性があるため、著しく強力です。

レンダリングステップ9：パーティクル

次の段階は最も重要なものの1つです。粒子です。 私はすでにこの記事で粒子について書いています 。 各スペル、バフ、およびエフェクトは、アニメーション化および更新が必要なパーティクルシステムです。 たとえば、5対5のチームバトルのように、検討しているシーンにはあまりアクションがありませんが、表示されるパーティクルは非常に多くあります。



パーティクルのみを考慮する場合（背景シーン全体をオフにする）、次の図を取得します。







バイオレットの輪郭（テクスチャなし、ジオメトリのみ）で粒子を構成する三角形をレンダリングすると、次のようになります。







パーティクルを通常にレンダリングすると、見慣れた外観になります。

レンダリングステージ10：後処理効果

そのため、シーンの基本部分はすでにレンダリングされており、もう少し「きらきら」させることができます。 これは2段階で行われます。 まず、平滑化パス（アンチエイリアス、AA）を実行します。 ギザギザのエッジを滑らかにし、フレーム全体をシャープにします。 静止画像では、この効果はほとんど見えませんが、画面上でコントラストの高い顔を移動するときに発生する可能性がある「ピクセルのちらつき」をなくすのに役立ちます。 LoLでは、 高速近似アンチエイリアシング （FXAA）平滑化アルゴリズムを使用します。



左側の画像はFXAAの前のミニオン、平滑化後の右側です。 オブジェクトのエッジがどのように平滑化されているかに注目してください。







FXAAパスの完了後、ガンマ補正パスを実行します。これにより、シーンの明るさを調整できます。 最適化として、最近、死の画面の彩度を下げる効果をガンマ補正パッセージに追加しました 。これにより、以前に彩度が個別に減少していた死のオプションの現在の表示グリッドのすべてのシェーダーを交換する必要がなくなりました。

レンダリングステージ11：ダメージストリップとヘルスストリップ

次に、すべてのゲームインジケーターをレンダリングします。ヘルスバー、ダメージテキスト、画面上のテキスト、および下の画像のダメージ効果など、後処理に関連しないすべてのフルスクリーン効果です。

レンダリングステージ12：インターフェース

最後に、ユーザーインターフェイスが描画されます。 すべてのテキスト、アイコン、およびオブジェクトは、個別のテクスチャとして画面上に描画され、それらの下にあるすべてのものに重なります。 分析中の場合、インターフェイスを描画するのに約1,000個の三角形が必要でした。ミニマップの場合は約300個、それ以外の場合は700個です。

すべてをまとめる

そして、完全にレンダリングされたシーンを取得します。 シーン全体には約200,000個の三角形が含まれ、そのうち90,000個がパーティクルに使用されます。 695回の描画呼び出しで、2800万ピクセルが描画されます。 ゲームをプレイするためには、このすべての作業を可能な限り迅速に行う必要があります。 1秒あたり60以上のフレームに到達するには、16.66ミリ秒未満ですべてのステージを完了する必要があります。 また、これらはGPU側での単なる計算です。すべてのゲームロジック、プレーヤー入力処理、衝突、パーティクル処理、アニメーション、およびレンダリング用のコマンドの送信も、中央プロセッサで同時に実行する必要があります。 300 fpsでプレイすると、すべてが3.3ミリ秒未満で発生します！

レンダラーをリファクタリングする理由

これで、 リーグゲームのシングルショットをレンダリングすることが難しくなります。 ただし、これはデータ出力側にすぎません。画面に表示されるのは、レンダリングエンジンの関数を何千回も呼び出した結果です。 現在のレンダリングのニーズによりよく応えるために、絶えず変化し進化しています。 これにより、新しいコードを考慮に入れて古い機器を維持する必要があるため、レンダリングコードのさまざまな形式がリーグコードベースに共存することになりました。 たとえば、Summoner's Riftは、Howling AbyssやTwisted Treelineとは少し異なります。 Leagueの古いバージョンから残ったレンダラーの部分と、まだ十分な可能性に達していない部分があります。 Render Strikeチームのタスクは、すべてのレンダリングコードを取得してリファクタリングし、すべてのレンダリングが同じインターフェイスを介して実行されるようにすることです。 仕事をうまくやれば、プレイヤーは違いにまったく気付かないでしょう（ただし、異なるポイントでの速度のわずかな増加を除きます）。 しかし、終了後、すべてのリーグゲームモードを同時に変更できる絶好の機会があります。



League of Legendsのレンダリングプロセスのこのツアーが面白いことを願っています。 記事の冒頭で、詳細には触れたくないと述べました。 リーグのすべてのゲームのすべてのフレームで起こるプロセスをよりよく理解するためにできるだけ多くの人を獲得しようとしました。 ご質問がある場合は、[元の記事への]コメントで質問してください。できる限り詳細に回答するよう努めます。