自分用も兼ねて、UE4+Oculusについて色々纏めてみる　-高速化編- (2015/02/01)

今回は、UE4+Oculusの高速化編です。

準備編　：http://pafuhana1213.hatenablog.com/entry/2015/02/01/020043
高速化編：ここ
Tips編　：工事中

はじめに

新しい情報の紹介というよりも、他の方が書かれた記事で
紹介されている高速化手法のまとめと、実際にどの程度高速化されるかの
検証がメインになります。

参考記事

・Epic社のシモダさん(@junyash)の記事
Oculus向けのコンテンツをUE4で制作するためのノウハウ共有♪（Oculus向けの最適化とか品質向上とか） - Qiita
・スミオ(仮設幼稚園)さん（@tempkinder）の記事
【UE4】GPUコストの高いHZBとはどんな機能？ - だらけ者だらけ

検証環境

PCスペック

OS ：Windows8.1 64bit
CPU：Core i5-4670 3.40GHz
GPU：GTX770 4GB

テスト用のレベル

f:id:pafuhana1213:20150201152609j:plain
FPSテンプレートの初期レベル + 箱を幾つか複製

ProfileGPUによる計測結果は、こんな感じ
f:id:pafuhana1213:20150201153833j:plain
処理速度が目立つ項目に対して、高速化対応をしていきます。

HZB
PostProcessing
Lights
Fog
View0,1
ReflectionEnvironmentGather

HZB

HZBに関しては、スミオさんの記事が全てです。ありがとうございます！
【UE4】GPUコストの高いHZBとはどんな機能？ - だらけ者だらけ

レベルBPのBeginPlayで「r.HZBOcclusion 0」を実行してみます。
f:id:pafuhana1213:20150201154454j:plain
f:id:pafuhana1213:20150201154839j:plain
HZBに関しては、処理時間をかなり削減できました。が、別の箇所で
処理時間が増えている為、全体的な処理時間は余り削減できていません…
（viewが増えているのが分かると思います）

とりあえず、次はPostProcessingに対して高速化対応します。

PostProcessing

ポストプロセスって何？という方には、@aizen76さんの記事がオススメです。
UE4 ポストプロセスエフェクトについて - Let's Enjoy Unreal Engine

ポストプロセスの処理負荷を下げるには、ポストプロセスを切るのが一番です。
早速レベルに配置されているPostProcessVolumeを消してみましょう

消した後の計測結果
f:id:pafuhana1213:20150201155921j:plain
アイエエエエ! ポスト!? ポストナンデ!?

実は、UE4 には「Default PostProcessing Setting」という設定があります。
この設定項目にチェックが入っていると、シーンにPostProcessVolumeを
配置していなくても、対象のポストプロセスが有効になります。
f:id:pafuhana1213:20150201160452j:plain
レベル上のPostProcessVolumeを触っている際に、どうも思うような絵にならないと
思ったら、この設定を確認してみましょう。

チェックを全て外してみました。
f:id:pafuhana1213:20150201161603j:plain
消した筈なのにまだ残っているのは気になりますが、1ms以内に収めることが
出来たので、これで良しとします。

※Default PostProcessing Settingのチェックを外すと、1つだけ困ることがあります。
それは「レベルエディタ以外のエディタ上でポストプロセスが効かなくなる」ことです。

↑の画像は、エミッシブに(6,0,0)を入れたマテリアルを
Default PostProcessing SettingのBloomを有効・無効にした状態で
見た時の結果です。（左：有効右：無効）

もちろん、実際にレベル上に置いて確認するのがベストなのですが、
無効状態では、仮設定すら出来ません…
多人数で開発している時はトラブルの原因になりそうです…

なので、Default PostProcessing Settingの変更は十分に注意しましょう。

HZBの項で問題になった「view」についてですが、この段階で
大幅に高速化されています。なぜなら、viewにはポストプロセスの1つである
AmbientOcclusion（SSAO）処理の処理が含まれていたからです。

Lights

次は、鬼門のライトの高速化対応です。
と言っても、ライト周りの高速化に関してはシモダさんの記事が全てです。
Oculus向けのコンテンツをUE4で制作するためのノウハウ共有♪（Oculus向けの最適化とか品質向上とか） - Qiita

と、終われればいいのですが、今回のレベルのように
動的なオブジェクトが多数存在 + 個々に自由に動くので親子付けが難しい場合は、
↑の記事で紹介されている手法は使いづらいです…
f:id:pafuhana1213:20150201173225g:plain

どうしましょうか…シモダさんの記事を読み返します…

動的ライトを極力抑えてライトマップだけにする、
動的オブジェクトには間接光のキャッシュを適用、
シャドウもシャドウバッファを使うのではなく丸影等フェイク表現も

丸影などのフェイク表現…UE4で丸影…どこかで見たような…

【Oculus向け】UE4で丸影を表示してみた (未完成記事 2015/01/20現在） - ぼっちプログラマのメモ
ありました（茶番）
せっかくの機会なので、どれ程高速化できるのか検証してみます。

f:id:pafuhana1213:20150201174631j:plain
左が通常のシャドウ（動的生成）、右が丸影版です。
…正直、丸影は違和感はありますね。影なしよりはマシですが。
光源との位置関係を考慮して、丸影を配置するようにすればマシになるかもしれません。

そして、肝心の処理速度
f:id:pafuhana1213:20150201175136j:plain
1.3msも高速化できています！…そういえば、Lightの可動性を
Stationaryにする必要ないよね。Staticにしてみました。

f:id:pafuhana1213:20150201175813j:plain
f:id:pafuhana1213:20150201175902j:plain
0.00ms!(ﾄﾞﾔｧ)
(ライトマップの焼き込みなので、当たり前)

丸影を使うことでLight周りの処理を格段に高速化することができました。
ただし、丸影は違和感を生む（＝VRコンテンツに夢中になるユーザを覚まさせる）原因
になる可能性があるので、使いドコロには十分に注意しましょう。

例えば、Mikulusのようなキャラクターと一対一でｷｬｯｷｬｳﾌﾌするようなコンテンツの場合
は、多少処理が重くてもStationaryLightによる動的シャドウの方が良いと思います。

Fog

レベル上に配置されているfogを取り除きます。以上。
f:id:pafuhana1213:20150201182759j:plain

ReflectionEnvironmentGather

レベル上に配置されているSphereReflectionCaptureを取り除きます。
当然ですが、反射が使えなくなるので注意です。

反射環境：Unreal Engine | 反射環境
f:id:pafuhana1213:20150201183431j:plain
ついに、5msを切りました…！

レンダリング設定の変更

シモダさんの記事にもありましたが、Showdownデモで
使われたレンダリング設定が公開されています。

公開されているパワポには有益な情報が沢山あるので、一度読んでみる事オススメです。
Unreal Engine | Oculus Rift の開発の
「Oculus Rift のアンリアルエンジン 4 への統合の教訓」に資料へのリンクがあります。

プロジェクトへの適応は簡単です。
まずは、「プロジェクト設定/エンジン/レンダリング」から設定をエクスポートします。
f:id:pafuhana1213:20150201192050j:plain
次に、出力された.iniファイルに、↑の記事・資料で紹介されている設定を
追加します。こぴー&ぺーすとです。
最後に、「プロジェクト設定/エンジン/レンダリング」から設定をインポートします。