Note: Follow the advice in this section in release order. For example, if you need to upgrade your project from 2019 to 2021, read the 2020 upgrade guides to see if there are any changes that you need to make before you read the 2021 upgrade guides.
This page lists changes in the Unity 2019 versions which might affect existing projects when you upgrade from any Unity 2018 version to 2019 LTS.
2019 LTS は 2019.4 と同じです。
このアップグレードガイドでは、Unity のビルトインレンダーパイプラインをバージョン 2022.2 にアップグレードする方法を説明します。 他のレンダーパイプラインをバージョン 2022.2 にアップグレードするには、以下を参照してください:
他のパッケージをアップグレードする場合は、使用しているパッケージのドキュメントを参照してください。
軽量レンダーパイプライン (LWRP) は、Unity 2019.3 からユニバーサルレンダーパイプライン (URP) になりました。
プロジェクトに LWRP が使用されている場合、URP を使用するためにプロジェクトをアップグレードする必要があります。アップグレードプロセスの手順については、LWRP から URP へのアップグレードガイド を参照してください。
名前に一貫性を持たせるため、ShaderUtil.ClearShaderErrors()
は ShaderUtil.ClearShaderMessages()
に替わり、ShaderUtil.ClearShaderMessages は古い機能 (非推奨) となりました。Unity 2019.4 で既存のプロジェクトを開くと、スクリプトは自動的にアップグレードされます。
Animation C# ジョブは、実験的な名前空間 UnityEngine.Experimental.Animations から UnityEngine.Animations に移動しました。
Unity 2019.4 は、以下の Animator ジョブ拡張メソッドを含むスクリプトを除いて、ほとんどのスクリプトを自動的に更新します。
using UnityEngine.Animations;
ステートメントをそれらのスクリプトに手動で加える必要があります。
ドキュメントに記載されていない RenderPipeline.beginCameraRendering
イベントと RenderPipeline.beginFrameRendering
イベントは削除されました。そのため、これらを RenderPipelineManager
クラスのイベントに置き換える必要があります。
RenderPipeline の保護された static 関数 BeginFrameRendering
と BeginCameraRendering
は削除されました。そのため、パラメーターにScriptableRenderContext
を取るシグネチャを使って、これらを置き換える必要があります。 さらに、EndCameraRendering メソッドと EndFrameRendering メソッドも呼び出す必要があります。
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 では、1 日に複数回プラットフォームの切り替えを行うと、プロジェクトのサイズによっては容易に何時間も消費してしまいます。 マシンのプラットフォームごとにプロジェクトのコピーを作成するなど、この問題の回避策を工夫しているユーザーもいますが、あまり拡張性に優れた方法とはいえません。 新しいアセットインポートパイプラインによって、GUID からファイル名へのマッピング処理を排除できました。特定のアセットの依存関係が追跡できるため、それらをまとめてハッシュして、アセットのインポート結果のリビジョンを作成できます。これにより、アセットごとに複数のリビジョンを持つことができるようになりました。つまり、もう GUID からファイル名へのマッピングに縛られる必要がなくなりました。この必要条件がなくなったことによって、さまざまな設定に使えるインポート結果を持つことができるようになりました。プラットフォームを短時間で切り替えるために、プラットフォームごとにインポート結果を設定できます。プラットフォームの切り替え時にインポート結果がすでにそこにあるため、新しいアセットインポートパイプラインでは、V1 よりもはるかに高速にプラットフォームを切り替えることができます。
キャッシュ処理と Unity Accelerator
ほとんどのインポーターは、決定性を改善しキャッシュ処理を効果的にするために、著しい作業を行ってきました。Unity Accelerator を使用すると、インポート結果は 1 か所にまとめられたストレージにアップロードされます。そこに、他のマシンが接続して、別のマシンで同じアセットに対して行われた作業の恩恵を受けることができます。また、ネストされたプレハブ、シェーダーなど動的な依存関係を持つアセットをキャッシュできるようになりました。インポーターとその関連ファイルのより包括的なリストは、新しい AssetDatabase のマニュアルを参照してください。
ScriptedImporter のキャッシュ処理
ScriptedImporter および依存関係が登録されているインポーターは、従来のアセットインポーターパイプラインではキャッシュできませんでした。
従来の動作
従来のアセットインポートパイプラインでは、インポート結果が GUID ベースであるため、プラットフォームを切り替えるとすべてのインポートが無効になり、インポート結果が毎回上書きされました。
新しい動作
新しいアセットインポートパイプラインでは、インポート結果であるディスク上のファイルは、それ自体のコンテンツのハッシュであるため、プラットフォームを切り替えてもインポートは無効になりません。したがって、プラットフォームを切り替えるときに、内容は異なり新しいファイルに保存されるため、両方のバージョンのインポート結果が保持され、何もインポートすることなく、簡単に別のバージョンに切り替えることができます。
従来のアセットインポートパイプラインでは、OnPostProcessAllAssets
関数の呼び出し回数は非決定論的でした。つまり、この関数は、同じ変更に対して 1 回または複数回呼び出すことができたという意味です。新しいアセットインポートパイプラインでは、検出されたスクリプトの変更 (.cs ファイル) とスクリプト以外の変更 (.png、.fbx、.wav ファイルなど) に対して、OnPostProcessAllAssets
への呼び出しを 1 回ずつ行います。
従来のアセットインポートパイプラインでは、コンパイルを起動して、その実行中にチェーンを再生モードにすることができました。これは、特定の状況では大幅な時間の節約になり、非同期のコンパイルを行うと、非決定論的な結果になる可能性がありました。新しいアセットインポートパイプラインでは、この点が変更され、アセットインポートパイプラインがスクリプトコンパイルの大部分を行うようになりました。このようなことから、決定論的アプローチが必要となるため、スクリプトコンパイルが完了するまでエディターがロックされます。
Tilemap Editor はパッケージになりました。このパッケージは、2D プロジェクトテンプレートで作成される新しい Unity プロジェクトに自動的にインストールされます。パッケージをインストールするための詳細は、パッケージの追加と削除 を参照してください。
すべての public クラスを UnityEditor.Tilemaps 名前空間に移動しました。Unity は、これらのクラスを参照するスクリプトを “Unity.2D.Tilemap.Editor” アセンブリ定義 (Assembly Definition) アセットにコンパイルします。 それらは以下の通りです。
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 クラスからメソッドを作成したり呼び出したりすることが原因で発生する場合があります。
Sprite Tooling (Sprite Editor Window) がパッケージ化されました。パッケージのインストールについては、パッケージの追加と削除 を参照してください。
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 2019.1 アップグレードガイド (英語) を参照してください。
スクリプティングランタイムバージョンの .NET 3.5 Equivalent オプションは廃止されました。プロジェクトを 2019.2 で開くと、自動的に .NET 4.x Equivalent オプションを使用するように移行します。
2019.1 より前の Indirect Intensity スライダーは、プログレッシブライトマッパーを使用している場合、ライトマップにのみ影響しました。Enlighten の場合、ライトプローブとライトマップの両方に適用されました。現在では、すべてのバックエンドが Indirect Intensity 値をライトマップとライトプローブの両方に適用します。ライティングを再度ベイクすると、Indirect Intensity の値に変更を加えた場合に、プローブがより明るく見えることに気がつくかもしれません。このようなことを避けるために、アップグレード後にライトマップを再度ベイクする前には、ベイクしたデータを消去してください。
文字列を 1 つとるコンストラクターは廃止されました。 サポートされているオーバーロードについては、ドキュメント を参照してください。
Unity 2019 LTS で作成されたプロジェクトには、macOS 10.12 または Ubuntu 16.04 以降が必要です。
Multiplayer の高レベル API (Multiplayer HLAPI) を拡張機能からパッケージに移動しました。これは NetworkTransport クラス (低レベルAPI) には影響しません。Unity エンジン内のすべての依存関係もパッケージに移動しました。つまり、高レベル API は、現時点で移動できなかったプロファイラーへのフックを除いて、独立した機能になっています。
高レベル API を含む古いプロジェクトには、コンパイラエラーを防ぐためにパッケージが自動的に加えられます。これは新しいプロジェクトでは行われませんが、必要に応じ Package Manager ウィンドウで加えることができます。詳しくは、Multiplayer の高レベル API の ドキュメント (英語) を参照してください。
2019.4 現在、Unity は自動的に UNITY_ADS
を定義していません。スクリプトで UNITY_ADS
を使用を止めるか、新しいカスタムのグローバル #define を作成する必要があります。新しいカスタムのグローバル #define を作成する方法については、プラットフォーム依存のコンパイル ページを参照してください。