Unity 2019 LTS へのアップグレード

ノート: このセクションのアドバイスには、リリース順に従ってください。例えば、プロジェクトを 2018 年から 2020 年にアップグレードする必要がある場合、2020 年のアップグレードガイドを読む前に、2019 年のアップグレードガイドを読んで変更すべき点がないかどうかを確認します。

このページでは、Unity 2018 バージョンから 2019 LTS にアップグレードする際に、既存のプロジェクトに影響する可能性のある Unity 2019 バージョンの変更点を記載しています。Unity 2017 バージョンからアップグレードする場合は、まず Unity 2018 LTS へのアップグレード ガイドを参照してください。

2019 LTS は 2019.4 と同じです。

このページに含まれる内容

• 軽量レンダーパイプライン (LWRP) からユニバーサルレンダーパイプライン (URP) へ
• ShaderUtil の更新
• Animation C# ジョブ
• スクリプティングレンダーパイプライン (SRP) API の変更
• Addressable
• 新しいアセットインポートパイプライン
• Tilemap エディターをパッケージに移動
• SpriteTooling をパッケージに移動
• Unity UI をパッケージに移動
• UI Elements が実験版から標準機能に
• .NET 3.5 Equivalent スクリプティングランタイムの廃止
• ライティングの向上
• UnityAPICompatibilityVersionAttribute コンストラクターの変更
• システム要件の変更
• Multiplayer (UNet) 高レベル API をパッケージに移動
• UNITY_ADS コンパイラーディレクティブが削除されました

---

軽量レンダーパイプライン (LWRP) からユニバーサルレンダーパイプライン (URP) へ

軽量レンダーパイプライン (LWRP) は、Unity 2019.3 からユニバーサルレンダーパイプライン (URP) になりました。

プロジェクトに LWRP が使用されている場合、URP を使用するためにプロジェクトをアップグレードする必要があります。アップグレードプロセスの手順については、LWRP から URP へのアップグレードガイド を参照してください。

ページ始めに戻る

ShaderUtil の更新

名前に一貫性を持たせるため、ShaderUtil.ClearShaderErrors() は ShaderUtil.ClearShaderMessages() に替わり、ShaderUtil.ClearShaderMessages は古い機能 (非推奨) となりました。Unity 2019.4 で既存のプロジェクトを開くと、スクリプトは自動的にアップグレードされます。

ページ始めに戻る

Animation C# ジョブ

Animation C# ジョブは、実験的な名前空間 UnityEngine.Experimental.Animations から UnityEngine.Animations に移動しました。

Unity 2019.4 は、以下の Animator ジョブ拡張メソッドを含むスクリプトを除いて、ほとんどのスクリプトを自動的に更新します。

• BindStreamTransform
• BindStreamProperty
• BindCustomStreamProperty
• BindSceneTransform
• BindSceneProperty
• OpenAnimationStream
• CloseAnimationStream
• ResolveAllStreamHandles
• ResolveAllSceneHandles

using UnityEngine.Animations; ステートメントをそれらのスクリプトに手動で加える必要があります。

ページ始めに戻る

スクリプティングレンダーパイプライン (SRP) API の変更

ドキュメントに記載されていない RenderPipeline.beginCameraRendering イベントと RenderPipeline.beginFrameRendering イベントは削除されました。そのため、これらを RenderPipelineManager クラスのイベントに置き換える必要があります。

RenderPipeline の保護された static 関数 BeginFrameRenderingと BeginCameraRendering は削除されました。そのため、パラメーターにScriptableRenderContext を取るシグネチャを使って、これらを置き換える必要があります。 さらに、EndCameraRendering メソッドと EndFrameRendering メソッドも呼び出す必要があります。

ページ始めに戻る

Addressable

AsyncLoad は古い機能 (非推奨) になりました。代わりに Async.LoadAssetAsync を使ってください。

ページ始めに戻る

新しいアセットインポートパイプライン

新しい Asset Import Pipeline (アセットインポートパイプライン) は、Unity 2019.3 以降で使用できます。既存のプロジェクトがある場合は、エディターの Project Settings ウィンドウ を使用して、新しいアセットインポートパイプラインにアップグレードできます。

Version 2 を選択すると、このプロジェクトに新しいアセットインポートパイプラインを使用することをエディターに指示します。プロジェクトを再ロードすると、新しいアセットインポートパイプラインコードを使用してアセットを再インポートします。実際に Library フォルダーを削除することはありませんが、本質的には Library フォルダーを削除するのと同じ効果があります。アセットインポートパイプラインを V2 に切り替えても、従来のアセットインポートパイプラインを使ったインポート結果は削除されません。これは、V2 が独自のフォルダー構造を作成してインポート結果を保存するためです。Unity 2019.2 以前で作成したプロジェクトは、デフォルトで今まで通り従来のアセットインポートパイプラインを使用します。そのようなプロジェクトを Unity 2019.3 で初めて開くと、新しいアセットインポートパイプラインにアップグレードするオプションが表示されます。それを却下すると、プロジェクトは従来のアセットインポートパイプラインを使用します。さらに、選択したバージョンはプロジェクトの EditorSettings.asset ファイルに保存されるため、バージョン管理されます。

新しいアセットインポートパイプラインで作成した新しいプロジェクト

Unity 2019.3 以降で新しいプロジェクトを作成する場合、新しいアセットインポートパイプラインの使用が新たなデフォルトになりました。作成するすべての新しいプロジェクトが新しいアセットインポートパイプラインを使用します。

新しいアセットインポートパイプラインの動作の変更

同じアセットの複数のバージョンをライブラリフォルダーにキャッシュ
\nUnity 2019.2 まで (従来のアセットインポートパイプラインを使用) は、Library フォルダーはアセットの GUID で構成され、それがファイル名になっていました。そのため、あるプラットフォームから別のプラットフォームに切り替えると、Library フォルダーのインポート結果が無効になり、その結果、プラットフォームを切り替えるたびにフォルダーが再インポートされる原因になりました。

アセットインポートパイプライン V1

アセットインポートパイプライン V1 では、1 日に複数回プラットフォームの切り替えを行うと、プロジェクトのサイズによっては容易に何時間も消費してしまいます。 マシンのプラットフォームごとにプロジェクトのコピーを作成するなど、この問題の回避策を工夫しているユーザーもいますが、あまり拡張性に優れた方法とはいえません。 新しいアセットインポートパイプラインによって、GUID からファイル名へのマッピング処理を排除できました。特定のアセットの依存関係が追跡できるため、それらをまとめてハッシュして、アセットのインポート結果のリビジョンを作成できます。これにより、アセットごとに複数のリビジョンを持つことができるようになりました。つまり、もう GUID からファイル名へのマッピングに縛られる必要がなくなりました。この必要条件がなくなったことによって、さまざまな設定に使えるインポート結果を持つことができるようになりました。プラットフォームを短時間で切り替えるために、プラットフォームごとにインポート結果を設定できます。プラットフォームの切り替え時にインポート結果がすでにそこにあるため、新しいアセットインポートパイプラインでは、V1 よりもはるかに高速にプラットフォームを切り替えることができます。

アセットインポートパイプライン V2

キャッシュ処理と Unity Accelerator
ほとんどのインポーターは、決定性を改善しキャッシュ処理を効果的にするために、著しい作業を行ってきました。Unity Accelerator を使用すると、インポート結果は 1 か所にまとめられたストレージにアップロードされます。そこに、他のマシンが接続して、別のマシンで同じアセットに対して行われた作業の恩恵を受けることができます。また、ネストされたプレハブ、シェーダーなど動的な依存関係を持つアセットをキャッシュできるようになりました。インポーターとその関連ファイルのより包括的なリストは、新しい AssetDatabase のマニュアルを参照してください。

ScriptedImporter のキャッシュ処理
ScriptedImporter および依存関係が登録されているインポーターは、従来のアセットインポーターパイプラインではキャッシュできませんでした。

従来の動作
従来のアセットインポートパイプラインでは、インポート結果が GUID ベースであるため、プラットフォームを切り替えるとすべてのインポートが無効になり、インポート結果が毎回上書きされました。

新しい動作
新しいアセットインポートパイプラインでは、プラットフォームを切り替えてもインポートは無効になりません。なぜなら、インポート結果であるディスク上のファイルは、それ自体のコンテンツのハッシュだからです。したがって、プラットフォームを切り替えるときに、内容は異なり新しいファイルに保存されるため、両方のバージョンのインポート結果が保持され、何もインポートすることなく、簡単に別のバージョンに切り替えることができます。

OnPostProcessAllAssets の呼び出し回数

従来のアセットインポートパイプラインでは、OnPostProcessAllAssets 関数の呼び出し回数は非決定論的でした。つまり、この関数は、同じ変更に対して 1 回または複数回呼び出すことができたという意味です。新しいアセットインポートパイプラインでは、検出されたスクリプトの変更 (.cs ファイル) とスクリプト以外の変更 (.png、.fbx、.wav ファイルなど) に対して、OnPostProcessAllAssets への呼び出しを 1 回ずつ行います。

スクリプトのコンパイルの同期

従来のアセットインポートパイプラインでは、コンパイルを起動して、その実行中にチェーンを再生モードにすることができました。これは、特定の状況では大幅な時間の節約になり、非同期のコンパイルを行うと、非決定論的な結果になる可能性がありました。新しいアセットインポートパイプラインでは、この点が変更され、アセットインポートパイプラインがスクリプトコンパイルの大部分を行うようになりました。このようなことから、決定論的アプローチが必要となるため、スクリプトコンパイルが完了するまでエディターがロックされます。

ページ始めに戻る

Tilemap Editor をパッケージに移動

Tilemap Editor はパッケージになりました。このパッケージは、2D プロジェクトテンプレートで作成される新しい Unity プロジェクトに自動的にインストールされます。パッケージをインストールするための詳細は、パッケージの追加と削除 を参照してください。

すべての public クラスを UnityEditor.Tilemaps 名前空間に移動しました。Unity は、これらのクラスを参照するスクリプトを “Unity.2D.Tilemap.Editor” アセンブリ定義 (Assembly Definition) アセットにコンパイルします。 それらは以下の通りです。

• GridBrush
• GridBrushEditorBase
• GridBrushEditor
• GridSelection

Unity は、スクリプト内で関連する Tilemap の using ステートメントを更新します。ただし、必要に応じて確認、変更を行ってください。

アセンブリ定義の一部であるスクリプトで Tilemap Tooling クラスを参照する場合は、アセンブリ定義 “Unity.2D.Tilemap.Editor” を アセンブリ定義ファイル下にアセンブリ定義参照 (Assembly Definition Reference) として加える必要があります。Unity が自動的に設定する場合もありますが、そうでない場合は手動で変更してください。

以前のバージョンの Unity の Tilemap Tooling クラスを参照するプリコンパイル済みアセンブリがある場合、前述の変更のために、プリコンパイル済みアセンブリを使用するときに問題が発生します。可能な場合は、これらのアセンブリを更新して、新しい Tilemap Tooling アセンブリに合わせて再コンパイルしてください。

以前のバージョンの Unity の Tilemap Tooling クラスを参照するプリコンパイル済みアセンブリがある場合、これらのアセンブリを更新および再コンパイルして、新しい Tilemap Tooling アセンブリを参照する必要があります。

プリコンパイルされたアセンブリをインポートするときに発生する問題の例 (コンソールウィンドウのエラー表示) は、以下の通りです。

Failed to extract {Class in Precompiled Assembly} class of base type UnityEditor.GridBrush when inspecting {Precompiled Assembly}
Unloading broken assembly {Precompiled Assembly}, this assembly can cause crashes in the runtime

日本語訳
{プリコンパイル済みアセンブリ} の検証中に {プリコンパイル済みアセンブリのクラス} クラスの基本型の UnityEditor.GridBrush を抽出するのに失敗しました。
壊れたアセンブリ {プリコンパイル済みアセンブリ} をアンロードしています。このアセンブリはランタイムにクラッシュの原因となる可能性があります。

これらのエラーは、GridBrush などの Tilemap Tooling クラスからの継承が原因で発生する場合があります。

プリコンパイル済みアセンブリの使用時に発生する問題の例 (コンソールウィンドウのエラー表示) は、以下の通りです。

TypeLoadException: Could not resolve type with token 01000011 (from typeref, class/assembly UnityEditor.GridBrush, UnityEditor, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null)
Error: Could not load signature of {Method in Precompiled Assembly} due to: Could not resolve type with token 01000011 (from typeref, class/assembly UnityEditor.GridBrush, UnityEditor, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null) assembly:UnityEditor, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null type:UnityEditor.GridBrush member:(null) signature:<none>

日本語訳
TypeLoadException: トークン 01000011 の型を解決できませんでした (typeref から、クラス/アセンブリ UnityEditor.GridBrush, UnityEditor, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null))
エラー: 以下のために {プリコンパイル済みアセンブリのメソッド} のシグネチャをロードできませんでした: トークン 01000011 の型を解決できませんでした (typeref から、クラス/アセンブリ UnityEditor.GridBrush, UnityEditor, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null) assembly:UnityEditor, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null type:UnityEditor.GridBrush member:(null) signature:<none>

これらのエラーは、GridBrush などの Tilemap Tooling クラスからメソッドを作成したり呼び出したりすることが原因で発生する場合があります。

ページ始めに戻る

SpriteTooling をパッケージに移動

Sprite Tooling (Sprite Editor Window) がパッケージ化されました。パッケージのインストールについては、パッケージの追加と削除 を参照してください。

• 新しいプロジェクトを 2D プロジェクトテンプレートで作成しないかぎり、このパッケージは新しい Unity プロジェクトにデフォルトでは含まれません。
• Unity 2019.1 にアップグレードすると、このパッケージは、既存の Unity プロジェクト (2019.1 以前) に加えられます。プロジェクトで 2D スプライトを使用しておらず、Sprite Tooling を使用する必要がない場合は、このパッケージを削除できます。
• Sprite Tooling をパッケージに変更する一環として、Experimental 名前空間が削除されました。プロジェクトに Sprite Tooling に関連するクラスを参照するスクリプトがある場合は、アップグレード後に正しい名前空間を使用していることを確認してください。例えば、必要に応じて “using UnityEditor.U2D.Sprites” を追加します。
• アセンブリ定義の一部であるスクリプトで Sprite クラスを参照する場合は、アセンブリ定義 “Unity.2D.Tilemap.Editor” をアセンブリ定義ファイル下にアセンブリ定義参照 (Assembly Definition Reference) として加える必要があります。

ページ始めに戻る

Unity UI をパッケージに移動

Unity UI (UGUI) はパッケージ com.unity.ugui になりました。パッケージマネージャー (Window > Package Manager) からアクセスできます。

Unity UI は、Unity の配信時に付属するコアパッケージです。 新しいプロジェクトに改めてインストールする必要はありません。バージョン 2019.2b1 以前で作成された既存の Unity プロジェクトを Unity 2019.2 にアップグレードすると、このパッケージは自動的に追加されます。アセンブリ定義は、uGUI アセンブリへの参照を自動的に取得します。Unity 2019.2 を古いバージョンの Unity の上にインストールする場合は、\Editor\Data\UnityExtensions\Unity 内の GUISystem フォルダーが削除されていることを確認してください。削除しないと、クラスの再定義エラーが発生する可能性があります。Unity UI ソースコードはパッケージとして提供されるようになったため、 BitBucket に公開されなくなりました。Unity UI API のドキュメントはメインのスクリプトリファレンスには含まれていません。代わりに、Unity UI パッケージドキュメントからアクセスしてください。

ページ始めに戻る

UI Elements は実験的期間を終え、標準機能となりました

詳しくは UI Elements 2019.1 アップグレードガイド (英語) を参照してください。

ページ始めに戻る

.NET 3.5 Equivalent スクリプティングランタイムの廃止

スクリプティングランタイムバージョンの .NET 3.5 Equivalent オプションは廃止されました。プロジェクトを 2019.2 で開くと、自動的に .NET 4.x Equivalent オプションを使用するように移行します。

ページ始めに戻る

ライティングの改良

2019.1 より前の Indirect Intensity スライダーは、プログレッシブライトマッパーを使用している場合、ライトマップにのみ影響しました。Enlighten の場合、ライトプローブとライトマップの両方に適用されました。現在では、すべてのバックエンドが Indirect Intensity 値をライトマップとライトプローブの両方に適用します。ライティングを再度ベイクすると、Indirect Intensity の値に変更を加えた場合に、プローブがより明るく見えることに気がつくかもしれません。このようなことを避けるために、アップグレード後にライトマップを再度ベイクする前には、ベイクしたデータを消去してください。

ページ始めに戻る

UnityAPICompatibilityVersionAttribute コンストラクターの変更

文字列を 1 つとるコンストラクターは廃止されました。 サポートされているオーバーロードについては、ドキュメント を参照してください。

ページ始めに戻る

変更されたシステム要件

Unity 2019 LTS で作成されたプロジェクトには、macOS 10.12 または Ubuntu 16.04 以降が必要です。

ページ始めに戻る

Multiplayer (UNet) 高レベル API をパッケージに移動

Multiplayer の高レベル API (Multiplayer HLAPI) を拡張機能からパッケージに移動しました。これは NetworkTransport クラス (低レベルAPI) には影響しません。Unity エンジン内のすべての依存関係もパッケージに移動しました。つまり、高レベル API は、現時点で移動できなかったプロファイラーへのフックを除いて、独立した機能になっています。

高レベル API を含む古いプロジェクトには、コンパイラエラーを防ぐためにパッケージが自動的に加えられます。これは新しいプロジェクトでは行われませんが、必要に応じ Package Manager ウィンドウで加えることができます。詳しくは、Multiplayer の高レベル API の ドキュメント (英語) を参照してください。　

ページ始めに戻る

UNITY_ADS ディレクティブを削除しました

2019.4 現在、Unity は自動的に UNITY_ADS を定義していません。スクリプトで UNITY_ADS を使用を止めるか、新しいカスタムのグローバル #define を作成する必要があります。新しいカスタムのグローバル #define を作成する方法については、プラットフォーム依存のコンパイル ページを参照してください。