「Unityで働くことはとても快適で便利です。自己実現の機会はたくさんあります」と彼らは私に言いましたが、それほど簡単ではないことがわかりました。 この記事では、Unityの称賛の歌は歌いません。 この記事では、小さなインディーチームが最初の、しかしかなり大きなデスポイントゲームを作成するときに直面した厳しい現実、制限、課題について説明します。
最初は有望でした。 わずか1か月で、小さなレベル、キャラクター、および優れた作業に携わる警備員のペアがいるプロトタイプを組み立てました。
最初の問題は、私が最終的に歯の照明システムを試してみることにしたときに発生しました。 ゲームでクロスプラットフォームを実現したいという事実を考慮すると、どのデバイスでも同等に高いレベルのグラフィックスを維持することが基本的に重要でした。 Unityのドキュメンテーションが後に明らかになったので、私はここで最初に弱者に夢中になりました。
照明
私たちの軍隊は非常に限られており、私はタイルシステムを選びました。 柔軟性があり、優れた視覚的多様性、限られた手段を実現できます。 色あせたレベルを見て、「照明システムのセットアップと動作」という答えを求めて、涙を浮かべてUnityのドキュメントを調べました。 ドキュメントは非常に表面的であることが判明し、システムの完全な理解を与えませんでした。 アンリアルエンジンのドキュメントは私を救い、ゲームエンジンでこれがどのように機能するかの多くの側面を明らかにし、「それを行う方法」という質問に多くの答えを与えました。 ほんの3つの良い記事があり、作成する準備ができました。
最初のヒットは、リアルタイムレンダーとベイクのためにUnityがエディターに表示するものとの驚くべき違いでした。 焼いた後の美しい影がおridgeに変わり、光源が互いに詰まり、その明るさと色が劇的に変化しました。
実際、照明のセットアップ全体は、特定の光源がさまざまな構成でどのように見えるかを覚えることになりました。 パラメータを設定します-レンダリングをオンにします。 結果が気に入らなかったので、設定を変更して再度レンダリングします。
次に、モバイルデバイスのバリエーションにHDRがないこと。 オンにできる目盛りはどこにでもありますが、結果はオブジェクトの光源からの色の不気味な混乱に過ぎず、UnityはライトマップをHDRに保存する方法を理解していません。 その結果、テクスチャはアルベドレベルまで明るくなり、「虹」のグラデーションが照明領域の端に表示されます。
最古のベイクドライトテスト
確かに負けた短い戦争の後、回り道をすることが決定されました。 照明の効果を実現するために、アルベドカードが明るくなるようにすべてのマテリアルをやり直し始め、光源の強度の小さな値でさえ照明の効果を与えました。
多くの操作の後-パターンを持つ美しいグラデーション
同じ写真では、ランプの前に、マスクとして機能する透明なテクスチャを持つ3Dオブジェクトがあることがわかります。 これは、開発者が、ベイク処理された光源のCookie（ライトスポットの形状）のテクスチャマスクを設定する機能を追加しなかったためです。
別のポイントは、指向性ライトマップに言及できます-優れた技術的ソリューションですが、モバイルフォーカスのため、使用しませんでした。 ライトマップ自体は非常に重く、指向性ライトマップはこの値を2倍にします。 ゲームはモバイルデバイスでうまく機能するはずだったので、それほど多くのリソースを犠牲にすることはできませんでした。 その理由は、光源がカメラに入るときにのみ、指向性ライトマップ効果全体が表示されるからです。 そして、トップダウンゲームではそのような瞬間はほとんどありません。
サイズが重要
もう1つの不快な瞬間は、エラーを処理するキャッシングシステムでした。これは最終結果に大きく影響します。 前の結果の予備クリーニングでライトを焼くと、同じことが起こります。 しかし、使用可能な結果の上でベイク処理を行うと、その後の各結果は少しではありますが前の結果とは異なりますが、数回の反復の後、その差は非常に大きくなりました。 いいえ、これは悪い結果ではありませんが、非常に予測不可能です。
私たちが何ができるかを理解する時が来たとき、かなり印象的なレベルが集められました。 そして、ここでもUnity開発者からのヒットがあります-ライトマップを焼くことができないというエラーがコンソールに落ち、レベルが黒いバーで覆われています。 高すぎるレベルと高すぎる照明設定。 残念だ。
ここでは、そのレベルで、適切な照明、カスタマイズされた反射サンプル、動的オブジェクトを照明するためのライトプローブ、および部分的に実装されたゲームプレイがあります。 よさそうだ、素晴らしいプレイ。 一目は、ドローコールの数に依存します-失敗、完全な失敗...約2,000あります。
これらの数字はどこから来たのですか？ シーンには100個の固有のオブジェクトしかないため、クローンは内部システムによって戦わなければなりません。 1週間の検索は失敗し、いくつかの推測と仮定、大量のテスト、設定の選択がすべて無駄になりました。 ある時点で、Unityはレンダリング時に同じオブジェクトを結合することを完全に拒否し、一度に1つずつレンダリングしました。
私たちのゲームデザイナーは、賢い人であり、優れたプログラマーであることが判明しました。 わずか数週間で、彼は最適化システムを作成しました。このシステムは、メッシュをグループ化およびマージし、ゲームで使用されるすべてのオブジェクトからアトラスを作成しました。 その結果、モバイルアプリケーションで許容されるドローコールの数を達成しました。 シーンの最大のディテールでは、250を超えることはありませんでした。まだたくさんありますが、優れた電話は強打に対処し、非常に大事な60 FPSを提供します。
最適化システムに入った後、ドローコールの数は安定して約100になります。
独自のシェーダー
それでも、写真に何か問題がありました。 結果は予想からはほど遠いものであり、さらに望ましいものでした。 テクスチャを作成する3Dコートと、すべてがこのオブジェクトの環境にあると信じているUnityでは、モデルの外観があまりにも異なることはすぐにはわかりませんでした。
Unity開発者が標準シェーダーを最適化するために行った膨大な作業にもかかわらず、デバイスでのテストはすべてがあまり良くないことを示しました。 はい、すぐにですが、私が望むほどではありません。 はい、PBR（物理ベースのレンダリング）ですが、奇妙に見えます。 グラフィックスAPI 2.0を使用するモバイルデバイスでの反射球の不適切な操作は、シェーダーを作成する主な理由の1つになりました。 パフォーマンス障害のため、3.0に切り替えたくありませんでした。
球面反射を使用したくありませんでした。 奇妙でugいように見え、キャラクターが動き、反射が一緒に動きます。 カメラがゲームの地面を見るとき、画像を装飾するためのオプションはほとんどなく、オブジェクトの表面の反射は本当に重要な役割を果たします。
一般に、UnityのPBRはPCゲームの物語であり、リアルタイムの照明で快適に感じることができます。 ベイク処理された照明と指向性ライトマップの欠如の場合、PBRは動作の仕方を理解しないゴミの山になります。 はい、誰かが、「キューブマップが配線されているモバイルシェーダーを使用できないのはなぜですか」と言うかもしれません。 答えは簡単です。閉じた空間に反射面がたくさんあります。 反射は美しく輝くだけでなく、形状を強調し、オブジェクトの作成元である素材の特性をよりよく理解し、理解できるようにし、キャラクターがいる部屋に適切な雰囲気を与えます。 ボーナスとして、見たくないものを見ることができます：建物のファサード（ゲームプレイを妨げないようにメインカメラには表示しません）、天井、手の届かない範囲にあるさまざまなアクセサリーや標識このカメラアングルの場所。 すべてが輝き、輝き、反射し、全体の雰囲気を作り出し、このデジタル世界を活性化します。
反射なし
反射あり
偽の反射は許容できる結果を与えることができ、すべてが輝きますが、プレイヤーは欺くことは難しく、理解できないかもしれませんが、ここで何かが間違っていると感じるでしょう！ その結果、彼らが長い間努力してきたという幻想全体が破壊されます。
独自のシェーダーを作成するとき、最初は単一のソリューションをコピーしました。シェーダーを「メタリック」と「鏡面反射」の2つの部分に分割しました。 私は、これがまさにすべてが非常に悪い部分であることをすぐには理解しませんでした。 このソリューションでは、金属面と光沢面を組み合わせた複雑なオブジェクトを作成できません。 ひとつ選ぶべきもの。
つまり、複数のアトラスですべてのテクスチャを収集し、すべてに1つのシェーダーを使用した最適化システムでは、画像が奇妙に見えました。 すべてがメタリックな色合いを放ち、またはその逆は単純な光沢のように見えました。 DOOM 3の場合とほぼ同じで、すべての表面が容赦なく輝きました。
Unityには、入力シェーダーに応じて未使用のブロックを破棄する複合シェーダーを作成する素晴らしい機能があります。 つまり シェーダーに7つの入力パラメーターがあり、3つしか使用されていない場合、コンパイル中に3つのパラメーターのみがあるシェーダーバージョンが作成されます。
シェーダーの2つのバージョンが作成されました。1つはすべての可能なテクスチャマップで個別に動作し、1つは4つの組み立てられたテクスチャアトラスで動作しました。
その結果、シェーダーのデバッグバージョンでかなりの量の入力が得られました。
1.透明度/不透明度の選択
2.法線マップを無効にします（1つのオブジェクトに存在しない場合、パフォーマンスはわずかに向上しますが、大量に無効にすると顕著な結果が得られます）。 私たちの場合、これは理にかなっています。カメラが十分に離れており、常に使用するのが賢明というわけではないため、アルベドにAO（アンビエントオクルージョン）を追加すると、かなり良い結果が得られることがよくあります。
次に、さまざまなテクスチャマップがあり、シェーダーで任意の色または値をすぐに乗算できます。
3.アルベド
4.鏡面反射
5.粗さ
6. AO
7.エミッション
8.金属
9.法線マップ
コンパイル中、この多様性はすべて4つのテクスチャに適合します。
これにより、アーティストとしての生活が楽になります。特にすべての機能を使用しない場合、生産性の点で希望する結果を得ることができる柔軟なツールがあります。 上記のすべてのおかげで、テクスチャのサイズを考慮せず、必要に応じてテクスチャに色の値を掛けることができました。これにより、グラフィックエディタに移動してすべてを保存する必要がなくなったため、作業が加速しました。
もう1つのプラスは、世界の3Dモデルのサイズを計算するシステムでした。これにより、テクスチャのサイズについて考える必要がなくなりました。 64pxの低品質のテクスチャまたは128pxの過度に詳細なテクスチャを苦労して選択する必要はありませんでした。 システムは、必要なサイズにテクスチャを単純に圧縮し、サテンに詰めます。 その結果、プレーヤーにとって、すべてが同じ品質の詳細を持ちます。
キャラクターのビジョンのゾーン。 戦争の霧
プロジェクトで使用した最も独創的でシンプルなソリューションの1つについて説明します。
戦争の霧は、ポイントライトを介して実装され、キャラクター内に配置され、照明のみを考慮した最も単純なシェーダーを備えた別のカメラでレンダリングされます。 結果は、後処理の霧に使用され、他のシェーダーのマスクとして使用される文字可視性バッファーです。 たとえば、警備員の可視性の領域。
おわりに
その結果、PCで最も美しいグラフィックと、モバイルデバイスでわずかに軽量でありながら見栄えの良いバージョンの両方を取得できる強力で柔軟なツールを作成しました。
完成したレベルを3Dエディターにアップロードし直し、そこで光を焼くというアイデアがあります。 これにより、ステージ準備の速度と定性的結果の両方が大幅に向上します。 私を信じて、それは素晴らしいでしょう。 ソフトシャドウとハードシャドウ、バックライト、品質勾配。 FrostBiteだけが、ハードウェアの寸前で美しいレンダリングのすべての可能性を示すことができると思いますか？ 私たちのチームは、本当に美しいゲームがすべてのデバイスでどのように見えるべきかを示すことができます。ハードウェアの技術要件はまったく同じです。 しかし、アイデアがいくつあっても、その実装には時間がかかります。 STEAMに行くことは、私たちのすべての野望を実現する機会を与えてくれますが、そのためにはあなたの助けが必要です！
プロジェクトの詳細については、次をご覧ください。
steamcommunity.com/sharedfiles/filedetails/?id=752096160
Andrey ChelushkinとVitaly Kovalevskyの支援を得て、Sergey Krotovが執筆した記事。