Zenn
🔥

Unity歴5年の僕がUnreal Engineをこれから学びたい人向けの記事を書く

2021/01/04に公開
Unity
Unreal Engine
MR
virtualproduction
tech

はじめに

この記事は
Unity歴5年の僕がUnreal Engineをこれから学びたい人向けの記事を書く
をZennに移植した記事です。

自己紹介

こんにちは、サイバーエージェント2018年入社のイワケンと申します。
私は半年前から、AI事業本部のフューチャーライブ事業部に異動しました。
仕事では、CyberHuman Productionsと共に、フューチャーライブのテクニカルディレクター & エンジニアをしています。

直近の公開できるプロジェクトとしては、社内の表彰式をフューチャーライブで行いました。このように、物理空間の撮影ではグリーンバックのスタジオですが、視聴者に配信される映像はバーチャル空間の中に人間がいる絵になっています。
CABASEAWARD.png
(引用: https://www.instagram.com/p/CIjNmnUDoi2/)
(参考映像: https://twitter.com/ca_developers/status/1336220497684488193?s=20 )

私の仕事は、バーチャルイベントの演出、合成撮影の要件に合わせて、CG空間の制作を設計&実装することです。これらの詳しい内容は別の機会に話しましょう。

さて、フューチャーライブ事業部に異動し、大きく変わったことが一つあります。

それが、主要ゲームエンジンがUnityからUnreal Engine4(以下UE4)に変わったことです。
それまで仕事趣味含めて5年間Unityを触り、UE4にはほとんど近づかなかった人間としては大きな環境の変化でした。

そこで本記事では、主要ツールがUnityからUE4に変わって得た学びを書きたいと思います。

本記事対象ユーザ

  • 現在Unityユーザだけど、UE4も興味ある
  • UnityからUE4に触ることになってどう学べばいいかわからない

という人におすすめです。

本記事の内容

大きく分けて2つ紹介します。

  • UE4キャッチアップでやったこと
  • UE4の癖を知る (Unityとの違いを知る)

です。

主にUE4の癖、すなわちUnityとの違いについて知ることで、UE4の扱い方に慣れやすくなると思います。

とはいえ、私もまだUE4に触れて半年、UE4を完全に使いこなしているわけではありません。私がこの部署に所属された当時、周りにUE4の達人となる人はいませんでした。
あくまで、独学でUE4でバーチャルイベントの案件を担当できるようになった程度のエンジニアの経験談だと思って聞いていただけるとありがたいです。

UE4キャッチアップでやったこと

まず、何からUE4に触れるか、というところでおすすめの教材や資料を共有します。
以下の3つを紹介します。

  • UE4のオンラインラーニングを受ける
  • UE4の公式ドキュメントを見る
  • UE4のSlideShareを見る
  • 番外編
    • プロの人に聞く

UE4のオンラインラーニングを受ける

こちらからログインすると受講することができます。
https://learn.unrealengine.com/home/dashboard

とりあえず最初に行ったのがUnity ユーザー向けの Unreal Engine 入門です。

image.png

image.png

ここから、UnityとUE4の違いを見つつUE4の使い方に慣れていきました。
UE4を実際に触りながら行いましょう。

合わせてこちらのページもおすすめです。

Unity 引っ越しガイド

他におすすめなオンラインコース

Unity→UE4の学習においてブループリントとマテリアルを抑えておくと良いでしょう。

ブループリントはUE4専用のビジュアルスクリプトプログラミングの機能です。UnityでいうPlayMaker的な機能を持ちます。
マテリアルに関して、おおむねUnityのマテリアルと同じ立ち位置ですが、UnityでいうShaderで解決する部分も、UE4のマテリアルで解決できることが多いです (VFX Graphのようなふるまいができる)

個人的には業務でシーケンサーを使用したので、シーケンサーのオンラインコースも初期の段階で受講しました。シーケンサーはUnityでいうTimelineに当たる機能です。

UE4の公式ドキュメントを見る

https://docs.unrealengine.com/ja/index.html

王道ですが、言葉の概念や定義を知るために見る癖をつけましょう。
ドキュメントの中にチュートリアルもあるので、オンラインコースの代わりに行うのも良いと思います。

SlideShareを見る

今までお世話になったSlideShareを共有します。

ドキュメントでは理解に届かない内容もSlideShareでみると頭に入る！ということが良くありました。ベストプラクティスが必要な領域や、原理的なワークフローの勉強にとても役立ちました。

また、Tips記事という意味ではヒストリアのブログもおすすめです

https://historia.co.jp/archives/

番外編

他にも

  • プロの人に聞く

という手段も初期の段階で行いました。
ソース管理含めた運用の話などが相談でき、非常に有用でした。

こちらは会社のサポートがあり達成できたことなので、個人の開発者の人には難しいかもしれないということで番外編とさせていただきました。

UE4の癖を知る (Unityとの違いを知る)

ここからは個人的に「ここを抑えておくとスッと理解しやすい」と思った部分を紹介しようと思います。

  • ディレクトリ構成
  • BluePrintとC++
  • アセットの参照/移行

ディレクトリ構成

PC上のUE4のディレクトリ構成をみるとこうなっています。

  • ProjectName
    • (Binaries)
    • Config
    • Content
    • Intermediate
    • (Plugins)
    • (Source)
    • Saved
    • (ProjectName.sln)
    • ProjectName.uproject

はい、私は最初わけがわかりませんでした。
まず最小単位を知りましょう。

  • ProjectName
    • Config
    • Content
    • ProjectName.uproject

これです。空のプロジェクトを作成すると、このフォルダ群が生成されます。
これは、Unityでいうと

  • ProjectName
    • Assets
    • Packages
    • ProjectSettings

の状態です。最低限のプロジェクト構成です。

無理やり対応づけるとすると

UE4 Unity
バージョン管理するもの
Config ProjectSettings
Content Assets
ProjectName.uproject Packages
バージョン管理しないもの
Intermediate Library
Saved Logs

のようなイメージでしょうか？

C++がないプロジェクトでは、これらのファイル群をバージョン管理しましょう。

  • ProjectName
    • Config
    • Content
    • ProjectName.uproject

逆に

  • Intermediate
  • Saved

といったディレクトリは中間ファイルやキャッシュにあたるので、バージョン管理しないようにしています。

BluePrintとC++

ブループリント(BluePrint)はUE4のビジュアルスクリプトプログラミングするための機能だけでなく、BluePrint ActorとしてUnityのPrefabのような機能も持っています。(Prefab機能についてはこの記事では割愛し、プログラミング機能のみに述べます)

  • BluePrint = PrefabのようなActor複製機能とPlayMakerのようなビジュアルスクリプトプログラミング機能
  • C++ = C#Scriptとdll

ここらへんは感覚的な話なので、厳密ではないかもしれません。

さて、エンジニアからすると「BluePrintなんて使うか！俺はC++で書く！」と思うでしょうか？それとも「便利やん！」と思うでしょうか？
個人的には「BluePrintもC++もどちらも扱えるようにしておく」「プロジェクト要件に応じて使用割合のバランスを取る」がスタンスとして正解だと思っています。

Unityの「C#で基本実装を書く」という感覚と比べると、BluePrintを使用するケースの割合が大きく感じるでしょう。

では、超簡単な部分だけBluePrintの雰囲気を見てみましょう。

例えば、このように弊社のリモデイの曜日を配列に格納しPrintするプログラムはこのように書きます。

image.png

EventBeginPlayは、Playが始まった時に呼ばれるEventです (UnityでいうC#のStart関数)
String型の配列を変数として定義し、ForEachでLoop処理で回し、PrintString (UnityでいうDebug.Log)で表示する処理です。

より丁寧に書くとこんな感じです。

image.png

結局BluePrintとC++どちらを使えばいいの？

この問いに絶対的な答えはありません。プロジェクトの要件によって割合を決めていくというのが大事になってきます。

ここで一つ、この問題に対する有名な格言をご紹介します。

「BluePrintは恋人、結婚するならC++」

引用: バイキング流UE4活用術 ～BPとお別れするまでの18ヶ月～

このスライドでは、最初BluePrintを導入したが、運用していく上でC++に移行していくというプロジェクトの例です。

また、下記のようにブループリントの割合が多めのプロジェクトも存在します。
UE4におけるレベル制作事例

これらを見てわかったことは

  • BluePrintとC++の実装は両立できる (片方のみも可能)
  • BluePrintは初期の段階では実装しやすく、プログラマ以外も触りやすいという利点があるが、プロジェクトが複雑化していくとパフォーマンスやデバッグの面で悪い影響が出やすい

ということがわかります。
結婚するならC++というのは、長く運用していくことを考えると、C++の方が良いという考え方の表れだと思います。

これらを踏まえて、弊プロジェクトでは

  • 基本BluePrint Onlyのプロジェクトにする
  • Editor用ツールかつBluePrintで届かない実装であるとき、C++による実装を検討する

という方針をとっています。
これらの理由としては

  • 合成に使用しているReality EngineがC++のSourceファイルや、外部Pluginを受け付けない
  • アーティストの作業割合が大きいため、BluePrint主体の実装にしておきたい
  • バーチャルライブに必要な実装部分がまだ複雑化していないため、BluePrintのままで運用できると判断
  • バーチャルライブのプロジェクトデータ運用期間が短い

といった理由からです。主に1つ目の理由が大きいです。

アセットの参照/移行

UnityでもUE4でもアセットが参照しあう事態が発生します。しかしその挙動は似て非なるものです。

一言でいうと「Unityはmetaファイルのguid, UE4はContent以下の相対パス」によって参照を持っています。

これにより、アセットの移動や、他プロジェクトの移行の際に、Unityとは違う思考を持って臨まないといけません。
例えば、MaterialがTextureを参照しているケースを考えてみましょう。

Unityの参照の持ち方はmetaファイルのguid

image.png

image.png

このように、Iwakenマテリアルが、iwasaki.jpgのTextureデータを参照しています。

この参照の持ち方を見るために、Iwaken.matをテキストエディタで開きます。

image.png

すると、_MainTex:のm_Textureを見るとguidの欄にf2706e4f5ccd3f24987003412e3a85dfと書いてあることがわかります。
では、iwasaki.jpg.metaを見てみましょう。
image.png

image.png
metaファイルのguidと一致していることがわかります。これがUnityのアセットの参照の持ち方の基本です。

ここでmetaファイルを削除したりguidを変更させると、Missing状態になります。

image.png

UE4の参照の持ち方はContent以下の相対パス

Unityと同様MaterialにTextureを張り付ける処理を書きました。
image.png

こちらはIwaken.uassetに対して右クリックしReferenceViewerを開いた時の図です。
image.png

image.png

このように「Content以下の相対パスで参照を持っている」ことを確認してください。また「/Game/=Contentディレクトリ」になります。

Unityのアセット移動はmetaファイルに気を付ける

Unityの参照の取り方はmetaファイルのguidですから、metaファイルの挙動に注目しておくことが大切です。
基本的には、Unity上からのアセット操作を行っていれば、フォルダ移動したとしても自動でmetaファイルを生成、移動、削除を行ってくれます。

間違って、Explorerからファイル移動やリネームを行うと参照がMissingになる原因になります。これは、ファイル操作に対してmetaファイルが更新されないことが問題です。バージョン管理にmetaファイルを含めない運用にすると、同様の問題が起きるでしょう。

外部にアセットをExportする場合は、Export Packageを行って、.unitypackageを生成すれば、自動的にmetaファイルもまとめて外に持ち出すことができます。

UE4のアセット移動はRedirectorとMigrateについて知る

さて、UE4は相対パスで参照を持ちますが、アセット移動/移行させるときにどのような挙動になるでしょう？

試しに、

Content/Test/Materials
Content/Test/Textures
を
Content/Test2/Materials
Content/Test2/Textures

に移動します。

image.png

image.png

なぜかContent/Test/Materialsにフォルダが残っています。Unityの感覚からすると「Why?」という感覚でしょう。残っているファイルを見てみましょう。

Filters/Other Filters/Show Redirectorsをクリックします。
残っているのがRedirectorという種類のファイルだからです。

image.png

image.png

先ほど、
レベル(UnityでのScene)→Material→Textureの参照順でしたが
レベル→Redirector→Material

の順になっています。
さらに、Materialの参照を見ると

image.png

Redirector→Material→None

になっています。

このことから

  • UE4ではアセットが移動するとRedirectorが生成される
    • Redirectorは移動する前の場所に残り、移動先の相対パスの情報を持っている
  • 上流の参照する側のアセットの参照先のアドレスは更新されない
  • Redirectorがなぜか生成されなかったTextureアセットに関しては、Materialからの参照がMissingになっている (のになぜか存在している)

ということがわかります。

ここから「Redirectorを無くして、参照関係を更新したい！」という場合は、右クリックしてFix up Redirector in folderを選択すると更新されます。

image.png

それでもRedirectorが生成されなかったTextureアセットはNoneのままですが、レベルの参照先が新しいMaterialアセットの場所になりました。

他のプロジェクトに移行する場合、Migrate(移行)という機能を使います。しかし、やっていることは「依存関係があるアセットを全て選択しコピー&ペースト」しているだけです。
結局Content以下の相対パスが変化しなければ、どのプロジェクトでも基本動いてくれます。

したがって、UE4のアセット管理では「Content直下にディレクトリを置かない」ということが大事になってきます。

例えば、

  • Content
    • BluePrints
    • Maps
    • Materials
    • ....

と、Content直下に置いていた場合、他のプロジェクトに移行した場合、そのままContent直下に移行されるため、元のアセットとごちゃまぜになる可能性があります。なので

  • Content
    • UtilityAssets
      • BluePrints
      • Maps
      • Materials
      • ...

のように、一つフォルダを挟むことで、移行してもごちゃまぜにならなくなります (同じディレクトリ名があった場合はごちゃまぜになるリスクがあります)

Discussion