[UE4ぷちコン映像編3rd]振り返り:360°映像制作

長所
- 安定
- Blueprintで完結
- 結果のPreviewが容易
  - UE4内でCubemapや再CaptureしたTextureはViewerで確認できる
短所
- 無改造だと出力解像度が上限4K
  - Cubemap解像度上限に引っ張られる模様。4096 x 2048まで。
  - ほぼ十分だが、昨今の高解像2D動画に慣れた目で見てしまうと…もう一声！と思うかも
- 撮影面は画角90°で前後上下左右の6枚で固定
  - 画角90°だと、撮影面の境界付近でPixelが疎になっていくのがやや顕著
    - 何かしらアーティファクト出るかも
      - 例えば輪郭線処理をPost Processでやっている場合、境界を跨いで太さが変わってしまう事も
- 撮影面1つあたりの解像度がCubeMapのSize Xで固定
  - Screen Percentageをアゲてジャギー等を滅するみたいな事はできない

Bloomの注意点

- 基本的にはあまり気にせず使える
- 平面投影したCubemapをCapture2Dで再撮影する際にBloomを効かせるので、撮影面の境界ではBloomが途切れない
  - ※平面投影の境界、すなわち球面の真上・真下・背後で効果が途切れる
    - ヒストリアさんのネコぱらの動画だと背後にBloomの境界が見える(が普通に視聴する分には全く気にならない。うまい！)
  - ※平面投影状態でBloom効果が添加される為、球面投影時は変形する点は注意

余談：
この記事を書いている時に初めて知ったが、全方向立体視画像に対応するPropertyがScene Capture Component Cubeにあった。環境マッピング以外にCubemapを使う事も普通に想定されているということでよいのかな。

Panoramic Captureを使う手法

公式のPanoramic Capture Pluginを使う手法。

参考資料

長所・短所

長所
- 出力解像度上限なし
  - 8Kも可能
- 撮影面の数・解像度が指定可能
  - 高解像撮影してジャギー回避できる…かもしれない
  - 正直、どの程度撮影面を分割するのが良いのかはProject毎に確認したほうがよい
    - 細かくするほど良くなっていくわけでもない
      - 最終的に平面化される際にどうしても圧縮される部分は出るし…
- Render Path別の出力が可能
  - Base Color, Scene Depthなど個別に画像出力可能
  - UE外でCompositeして最終出力を得るワークフローであれば必須
短所
- 重い
  - 基本的にCubemapを使う方法より重い
    - 比較用に画角90°で並行・垂直90°刻みに撮影する設定にしても12回撮影しちゃってる気がする
      - 水平方向360°/90°=4分割、垂直方向180°/90°+1で3分割の4x3=12枚
        そのうち6枚は真上又は真下方向でRollしただけの絵なのでは…？
        (水平方向分割数-1)*2枚無駄になってるかも…？
    - あまり検証に時間を割けていないので、間違った使い方をしているかも
    - 撮影パラメータ次第で多少改善はする(後述)
- やや不安定
  - 誤ったParameterを設定するとCrash、あるいはTextureがバグる(後述)
    - Crashされるとエラー文も読めないので、原因の理解にはC++コードの解読が必須
    - 流石に適切に使えばCrashはしない
  - 5.0EAでPluginを有効化するとProject起動中にCrash
    - まぁこれは仕方ない
- プレビューには不向き
  - 画像出力しないと結果を確認できない
  - 低解像度撮影設定を別途設けて切り替えて運用するなどで軽減できる(後述)
- 素の使い勝手はやや微妙
  - パラメータ設定から撮影開始命令まで全てがConsole制御
    - ラップ処理を自分でつくれば改善する(後述)
  - 公式Docすら「詳細はソースコード読んでくれ！」と言い放つ漢仕様
    - コード自体は素直なので読めばわかる
    - 載ってないパラメータもある(後述)

Parameter設定の注意事項

基本的なパラメータ設定は公式ドキュメントを参照して頂くとして、ここでは扱いに注意が必要なものについて述べる。

カメラ回転追従設定

SP.UseCameraRotation
- 4.20から追加された設定
- 0でカメラ(Player Camera Managerの制御対象)の回転を無視
- 漢のbit flag制御
  - 1でPitch、 2でYaw、4でRoll、7で全軸追従
  - とりあえず360画像のカメラ回したいなら "SP.UseCameraRotation 7"

スライスの調節

SP.HorizontalAngularIncrement
- 最大値は120(360の約数のうち180未満の最大値)
- Docに書いてあるが、CaptureHorizontalFOV ≧ HorizontalAngularIncrement である事
  - さもなくばCrash
SP.VerticalAngularIncrement
- 最大値は90(180の約数のうち180未満の最大値)

デバッグの調節

SP.ConcurrentCaptures
- 連続で発行(一度にflush)するキャプチャの最大数
- レンダリング時間の短縮に効く
- 撮影面の数が理論的な最大値？
  - すなわち (360/SP.HorizontalAngularIncrement) * (180/SP.VerticalAngularIncrement + 1)
  - これより大きい値を設定すると描画結果がバグる事がある。あった(締切2日前)。
    - 詳細未調査。
  - 分割数が少ない(12とかの)時も、最大値だと描画結果がバグる事がある。あった(締切2日前)。
    - 詳細未調査。
  - 他のパラメータやハードウェアとの兼ね合いで、理論値で最大の速さになるわけでもないみたい
    - 理論最大値300の時、150を設定してもレンダリング時間に差がなかったりする
  - とりあえず理論値の半分を自動的に設定するようにして今回は使った

サンプリングの調節

SP.CaptureSlicePixelWidth
- 撮影面1つあたりの解像度
- 球面に張り合わせる際にPixelが不足する値だとCrash
  - 逆に大きめに設定すればSuperなSamplingが可能
    - ジャギ回避、輪郭線出しが捗るなど効果アリ
    - なお重くなる模様
- (SP.StepCaptureWidth * tan(SP.CaptureHorizontalFOV/2))/(360*tan(SP.HorizontalAngularIncrement/2)) が最低値
  - 直接入力しないほうがいい
  - 設定用アセットでケアしよう(後述)

Bloomの注意点

撮影面を細かくする＝境界が増えるという事なので、何も考えず使うと効果が途切れまくる
- SP.CaptureHorizontalFOVをSP.HorizontalAngularIncrementよりも大きな値にすることである程度回避できる
  - 広めに撮影して中央部分だけ使う挙動になり、隣接する撮影面に描画されるEmissive物体も考慮できる為
  - もろちんSP.CaptureHorizontalFOVを広げるほどに重くなるので注意
  - Bloom側でもSize Scaleを下げて効果範囲を抑える対応が必要
    - ただBloom効果範囲はFOVにも連動するので、出力結果を見つつ両者を調整していくことになる

左：症状が出ている状態　右：FOVのみ二倍にした結果

Post Process対応

なんとUE4.27.2付属のPluginだとPost Process Material設定が反映されない
- Answerhubに答えがある
  - プルリクもされてるけど拾われてないのかな…
- 内部的な撮影に使うScene Capture 2DのAlwaysPersistRenderingStateがfalseである為に反映されない
- 自分が行った解決手順
  - 適当な新規C++ Classを定義してVS Solution生成
  - (エンジンインストールフォルダ)/Engine/Plugins/Experimental/PanoramicCapture をフォルダごと (自Project)/Plugins 内にコピー
  - AlwaysPersistRenderingStateをtrueにする修正を反映
  - VSでビルド

今作での運用例

Data Assetで各種パラメータを素早く切り替えられるようにしておくと、検証や凡ミス軽減が捗る。

Data Assetの基本的な扱いはこちらの神講演資料を参照

Pluginに付属するCapture用Blueprintサンプルから、パラメータ設定部を抜き出してData Assetの関数にする。

するとCapture用BlueprintはData Assetを切り替えてApply Settingsを呼ぶだけで済む。

左：プレビュー用の高速設定。撮影時間1枚0.4秒

右：本番用の高品質設定。撮影時間1枚18秒

レンダリング関連

上述の通り、本番用設定で1枚18秒かかるので、60FPSの30秒動画だと9時間近くレンダリングに持っていかれる。
- 物理やパーティクル挙動を決定的にできれば分散もできそうではある
本番用は5K
- 4Kだと輪郭線が若干粗く、8Kは美麗ではあるが出力が大変すぎるので5Kに落ち着いた
  - 8Kは1枚57秒かかる。28.5時間…
- 4Kで出してUE4外で超解像して8Kにできそうだがレギュ違反
- 5K出力だと12GBの元データを連結して153MBぐらいになる
- パラメータは正直詰めきれていない
  - もっと撮影面を荒くして高速化しても品質に影響ないかも
  - ソースコード最適化も要検討
元旦以降締め切りまで毎日、寝る前にレンダリングを仕掛ける生活
- 途中でCrashした事は一度もなし
- 翌日Aviutlで結合してYouTubeにテストアップロードというのが習慣になった
- そして「アップした動画のアラ探し」から着手する。案外細かいアラが見つかってよい
  - これが継続的インテグレーションだと言われている[誰によって?][要出典][独自研究]
RICOHさんのTHETA用アプリを入れておくと便利
- 静止画を球面投影状態で確認できる
- 動画も360°動画メタ情報を埋める前に確認できる

演出関連

視線の誘導
- 意識高い看板→トイレに駆け込む人→空き缶→赤ヘッドの人が転倒→スプリンクラー→様子を見に来た黄ヘッドの人→青ヘッドの様子を見に行く黄ヘッドの人→ピンチの青ヘッドの人→青ヘッドがなぎ倒すダンボール→大爆発黄ヘッド→壁にぶっささる黄ヘッドの人→安全第一
- 「事故の連鎖」という手法だと、どの事故から見ても「なぜコレが発生したのか？」というのを痕から探してもらえる…と思う
  - 興味を持ってもらえることが前提ではある…
失敗した点
- 黄ヘッド大爆発後に出てくる存在とその振る舞いが目立ちすぎ
  - 年末にYouTubeでやってたAKIRAの影響受けすぎ
  - 安全第一を見て欲しいのにそれどころじゃない
    - 中止だ中止
  - 爆発後はクレーターの静止状態にして退屈にさせ、吹っ飛んだ人を探させたほうがいい
  - アレを出す場合でも爆発の収束を遅くするとか煙まみれにするとかで退屈にさせればいい
    - 安全第一を見たあと、ふと爆心地どうなったかなと思って振り向いたら「なんかいる」みたいな流れがベストか

所感

最初に「これ回転できる動画ですよ」の案内を入れなかったことが悔やまれる
- とりあえず字幕機能で後付した…
普通の2D動画だとカットや構図の技法が必要になるが360°動画なら不要！ワッショイ！
- 360°動画専用の技法が必要！グワーッ！
- 基本的に長回しになるので逆に手間になる部分も…
「いちいち視点変えるのめんどくさい問題」に立ち向かう必要あり
- 参考資料の「プレイヤーが見回すことに対してご褒美を与える」が難しい！
  - 今作は「事故の真相がわかる」が褒美になっている…と思う
    - 各ブルーマンヘッドを注視すると性質がﾁｮｯﾄﾜｶﾙので、事故の連鎖に納得性を持たせられていますか？
      - いつのまにか自分が質問側になるほどわからん…
チャレンジとしては面白かった
- 未知すぎて逆に何やってもいいや感は正直あった
- みんなも…やりましょうね！

[UE4ぷちコン 映像編3rd]振り返り:360°映像制作

概要

注意事項

Scene Capture Component Cubeを使う手法

参考資料

長所・短所

Panoramic Captureを使う手法

参考資料

長所・短所

Parameter設定の注意事項

Bloomの注意点

Post Process対応

今作での運用例

レンダリング関連

演出関連

所感

[UE4ぷちコン映像編3rd]振り返り:360°映像制作