デスクトップPCとコンソール機で楽しめる、素晴らしいリアルタイムGI

私たちは再びアレックス・ロベットと協力し、 Unity 5のプリコンピュートリアルタイムGI機能を有効活用したデモ「The Courtyard」を制作しました。彼は以前、 Shrine Arch-vizのデモ版を制作した。しかし今回は、リアルタイムのフレームレートを必要とするゲーム開発者向けのデモをビルドことが目標だった。こちらの動画をご覧ください。

アレックスは約8週間でデモ版をUnity 5.2のみを使用して構築しました。アセットストアからの追加パッケージは一切使用せず、すべてゼロから構築しました。

このデモは、事前計算されたリアルタイムGIとリアルタイムライティングを全面的に利用しています。完全な時間帯サイクル、エミッシブジオメトリ、夜間に点灯する約100個のアニメーションスポットライト、スタンド付きの投光器、および任意のプレイヤー用懐中電灯を備えています。時間帯の変化をキャプチャ。今回公開するPlayableデモ（下記参照）では、ゲーム内でこれらの照明機能をすべて制御できるユーザーインターフェースが追加されています。以下は、時間帯を変えて撮影した現場の写真です。

このシーンは、照明に関して特に高い要求が課されるように作られた。 そのかなりの部分は反射ライトのみで照らされており、日が沈むとほぼ完全に反射ライトで照らされる。

リアルタイムGIシステムは、シーン内の静的オブジェクト間をライトが通過する可能性のあるすべての経路を事前に計算することで機能します。これにより、照明の変更による影響を迅速に計算するために必要なすべての情報がシステムに既に備わっているため、中断することなくリアルタイムで照明を微調整することが可能になります。しかし、これは静的オブジェクトを変更すべきではないことを意味します。なぜなら、変更するとすべてのパスを再度事前に計算する必要が生じるからです。こうしたことから、レベル作成は段階的に行うのが理にかなっている。まずジオメトリを作成し、次にライティングを作成する（そして必要に応じて繰り返す）。静的ジオメトリを無計画に移動させながら同時に照明を調整すると、多くの照明ビルドが必要になります。 Unity 5.x向けに、より先進的でインタラクティブなライティングワークフローの開発に取り組んでいます。この件に関する詳細は、別のブログ記事で後日改めてお知らせします。

このデモはデスクトップPCとコンソールを念頭に置いて作成されました。モバイルプラットフォームでのリアルタイムGIの使用に関するTransporterデモについては、 Unity 5のGIに関するブログ記事をご覧ください。

Unity 5のリアルタイムGIシステムは、Geomerics Enlightenによって駆動されており、ゲームでの使用を想定して設計されています。照明に関する計算はすべてCPUワーカースレッド上で非同期的に実行されます。ゲームは通常GPUの処理能力がボトルネックとなるため、CPUの処理負荷が増加しても全体のフレームレートへの影響はごくわずかです。また、照明が変化した領域のみが再計算されます。

ゲーム内のライティングの待ち時間は、リアルタイム間接光マップに選択された解像度に依存します。このデモでは、アレックスは応答性を高めるために解像度を比較的低く設定しましたが、間接照明部分の望ましい照明の忠実度と微妙なニュアンスを捉えるようにしました。

間接ライトマップの解像度は以下のとおりです。

• 中央部では、2単位ごとに1テクセル（つまり、1単位あたり0.5テクセル）となる。
• 中央部に近い砂丘では、10区画ごとに1区画のテクセル。
• 外縁部の砂丘では、32ユニットごとに1テクセルが生息している。

解像度のバランスを取るため、シーン全体で単位あたり0.25テクセルの基準値が設定された。その後、カスタムライトマップパラメータを使用して乗数を追加することで、非常に美しいライティングを実現し、事前計算時間をわずか15分に短縮しました。

以下のスクリーンショットは、シーンのシェーディングされた概要、生成されたEnlightenシステム、 UVチャートビュー（間接ライトマップの解像度を表示）、クラスター（バウンス照明を発する役割）、バウンス照明、および照明の方向性（軸ジオメトリと鏡面反射の照明に使用）を示しています。

良好なライトマッピングUVを提供するよう配慮した。場合によっては、ライティングビルドとランタイムの両方でモデルが適切に動作するように、慎重に作成されています。その具体的な例の一つが、階段モデルである。

階段は、テクセルサイズが大きい場合、テクセルが1ステップ以上の範囲を覆う可能性があるため、適切に仕上げるのが難しい場合があります。これにより、階段ごとに照明レベルが予期せず変化する可能性があります。一方、ステップごとに多くのテクセルを使用すると、パフォーマンスの面でコストがかさむ。このシーンで使用されている階段には面取りが施されており、リアルタイムGIの展開とパッキングに大きな支障をきたし、テクセル領域を占有する不要なチャートを多数生成する可能性があります。当初の階段デザインは、リアルタイムGI UVレイアウトでは以下のようになっていました。

これは70×72テクセルのリアルタイムライトマップを使用します。このレイアウトには2つの問題点があります。まず、1ステップあたりに使用するテクセル数が多すぎる（4x4）。次に、ベベル処理が別々のチャートに分割されており、それぞれが最低でも4x4テクセルを占有している。なぜ各グラフは1テクセルだけを使用できないのですか？まず、 Enlightenはランタイムにテクスチャを処理する際に2x2テクセルブロックを使用するように最適化されているため、すべてのチャートは少なくとも2x2テクセルである必要があります。第二に、 Enlightenには、グラフを結合して、例えば球体や円柱などの滑らかな形状を実現できるステッチング特徴が搭載されています。この特徴を使用するには、グラフの各エッジに個別の方向性情報が必要です。方向性情報はブロック単位でのみ保存されるため、ステッチ可能なチャートには常に最低でも2x2ブロックが必要となり、最低でも4x4テクセルになります。階段部分は縫い合わせる必要がないため、2×2テクセルの図案で十分です。

照明パネルのオブジェクトプロパティに、このためのオプションを追加しました。

値は、方向性を使用する設定でのステッチングに適した4、またはよりコンパクトな2のいずれかになります。 最小チャートサイズオプションを2に設定すると、テクセル密度が大幅に低下し、モデルが44x46テクセルのリアルタイムライトマップに収まるようになります。

面取り部分が依然として不必要なチャートスペースを占有している。これはやや予想外です。なぜなら、ベベルとステップは、 UV 空間においてベベルがステップの一部となるように作成されているからです。下の画像は、モデル上に重ね合わせたUV境界線を示しています。面取りが段差にどのように組み込まれているかに注目してください。

ライトマッピングUVの2Dビューでは、ベベルは表示されません。これは、それらがステップチャートに統合されているため、 UV 空間に領域を持たないためです。これは、照明シミュレーションが傾斜した面取りをアカウントしないようにするためです。