UE4のShowdownデモの解析はじめました その1

コツコツとしていきますよっと
UE4のShowdownデモの解析はじめました その0 - ぼっちプログラマのメモ

レベル・サブレベル

解析結果に応じて、ちょこちょこ更新していく予定

まずは検証を始める前に、各レベルがどういう役割で分けられているのかを
確認します。確レベル名の左横にある目玉アイコンをONOFFすると、
そのレベルに所属するオブジェクトの表示が切り替わるので、確認しやすいです

パーシスタントレベル：

• カメラ・プレイヤースタート
• 各入力制御
• マップの切り替え（ロード・表示ONOFF）
• マップ切替時のホワイトアウトの表示ONOFF
• 各レベルの初期化イベントの発行
  • ce "EventName"
    • 表示されている全レベルの"EventName"のカスタムイベントを呼び出す
    • [UE4] コンソールコマンドの使い方＆よく使うコマンド一覧 | historia Inc - 株式会社ヒストリア

メインシーン

• EnvironmentMap
  • 背景モデル
    • 地味に、頭上の道路はSplineMesh
  • ライティング（Staticのみ）]
  • ポストプロセス
  • 配置しているTargetPointの用途がまだ不明
• MatineeMap
  • マチネでの制御部分・制御するオブジェクト(エフェクトやモデル)
  • マチネ上での制御に加えて、レベルBPでのマチネのイベント毎の処理を定義
    • 各兵士の射撃と、後半の車が横転開始するときのImpulse
  • まずはマチネ(SlomoRailMatinee)を再生する
• SL_Audip_ASSET
  • AmbientSound
    • SE的なものは、MatineeMapの方で鳴らしている
  • 呻き声（MoanSpline）
    • スプライン上に沿って呻き声SEを移動させている
• SL_Interaction_Design
  • レベルBPで、GameStateのパラメータを有効にしているだけ
    • StaretExperience、TRIGGER Trail Start
  • 残っている無駄ノードからの推測
    • 初期段階では、ロゴシーンで右を向いたら開始にしていた。そして、その実装はこのレベルでしていた
    • が、途中でスペースバーを押すだけで開始に仕様変更された為、実装が無駄に。でも一応残しとく。的な流れ

ロゴシーン

• SL_Lighting_MASTER
  • ライティング・ポスト
• SL_Logo_Asset
  • ロゴモデルの制御
  • Matineeでは、イベントを発行するのみ
• SL_LogoExtra_FX
  • ゴッドレイ制御
  • Matineeでは、ゴッドレイの半透明部分を制御
• SL_MatineeCore
  • 環境音・地面のモデル・地面を照らすライティング
  • シーン制御用のマチネ
• SL_ParticleTrails_FX
  • エフェクト全般
    • ロゴに沿ったエフェクトはスプライン上座標をエフェクトにセットしている
• SL_ParticleVortex_FX
  • シーン遷移時の渦巻きエフェクトの＋α
• SL_Sky_ASSET
  • スカイドーム

追記：何故サブレベルに分けているのか

サブレベルを使う理由としては、
「広大なレベルをサブレベルに分割することで、ロード時間の短縮やメモリ節約になる」
がよく挙げられます

今回もロゴシーンからメインシーンに遷移するので、↑の利点は確かに活用されています
が、ここまで要素ごとに細かく分割しているのは何故でしょうか？

理由は、複数人（特に、異なる分野の人同士）でレベルを編集する際は
個々の担当範囲をサブレベルで分けた方が様々な面で便利だからです

個人開発していると気づきにくいのですが、1つのレベルを複数人が同時に編集すると
色々と酷いことになります。
衝突(※1)が起きたり、弄って欲しくない所を他人が触ってしまったり…
Unityで複数人開発をした人はよく分かるのではないでしょうか？
※1:同じ箇所に対して別の編集が行われてどちらを採用していいか分からなくなる）

こういった自体を避けるために、担当範囲毎にサブレベルで切り分けるのは有効です
また、不要なサブレベルの表示をOFFにすることで、
自分によって見易い環境で作業することもできます

少し面倒な点としては、サブレベル間でのデータのやり取りが少し面倒なことです
ただ、4.9で異なるレベル間でのデータのやり取りが強化されたりしているので、
今後この欠点は解消されていくと思います
https://www.unrealengine.com/ja/blog/unreal-engine-49-released

個人開発では利点よりも欠点が目立ってしまうかもしれませんが、
一度意識して開発してみてもいいかもしれません

ライティング

VRする上でライティング処理の負荷は頭痛の種なので、早めに解析します

最も処理負荷の低いStaticにしておくことがVRでは推奨されていますが、
Showdownデモでは、幾つかのライトがStationery, Movableだったりします
(エフェクトにはライトは埋め込まれてませんでした)

ライトの可動性で分けるとこんな感じ

• Static
  • メインシーン背景のライティング
• Stationery, Movable
  • ミサイル爆発時のSpotLight
  • ロゴシーンのライティング

Stationery, Movableにしている理由は以下の2つ、だと思います

• ランタイム中、輝度を動的に変更したい
• ライトを破棄した際に、そのライトによる影響も破棄したい

一つ目の理由に関しては、
Staticライトはゲーム中に動的に明るさを変えることができないので、
Stationery, Movableにする必要があるということです。
実際に、ミサイル爆破のライトではマチネからIntensityが制御されています。

二つ目の理由に関しては、
Staticライトを使った場合、そのライトが配置されているサブレベルとは
別のサブレベルに配置されているオブジェクトにも影響を及ぼすことが
そもそもの理由です。

もしロゴシーンにおけるライトの設定がStaticだった場合、
ロゴシーンからメインシーンに遷移した際に、そのライトは破棄されますが、
ライトの影響は残り続けるので、メインシーンでのライティングが
不自然なものになります。
これは、Staticライトは事前計算によるライトマップのベイクをしているからです。

逆に言うと、ライトマップにベイクしないStationery, Movableライトは
ライトが破棄されるとその影響も破棄されます。
これが、ロゴシーンでのライトの設定がStationery, Movableになっている理由、
だと思います。

( Stationery, Movableを使い分けている理由はハッキリとしたものは分かっていません
マチネで制御はしていないっぽいので、Movableのパラメータ変更範囲の広さが
理由ではないと思うのですが…うーん…
　IESプロファイルを使うライトは綺麗なライティング結果にしたかった？
　それとも、単純にライトのビルド時間の短縮？)

…ただ、VRではライティングがボトルネックになることは多いので、
超ハイスペックなPCを使わない場合は、Staticにすることをオススメしておきます

追記　シャドウは落としてませんよ

メインシーンでのStationery, Movableになっているライトのパラメータを
よく見ると、Cast ShadowがOFFられています。
つまり、ライトで照らしてはいますが、影は落としていないのです（そのままですね）

影周りはライティングと同様に負荷の高い処理なので、
無効にするのはVRではよくある手です
ただ影がないと周りから浮き、VRにおける没入感を阻害する可能性がでてきます

ので、Showdownではフェイクな影を使うことで、ある意味誤魔化しています
それについて次回紹介します

今回はここまで

とりあえず、今回はここまで
ライティングに触れたので、次はシャドウ