このセクションのアドバイスには、リリース順に従ってください。例えば、プロジェクトを 2019 年から 2021 年にアップグレードする必要がある場合、2021 年のアップグレードガイドを読む前に、2020 年のアップグレードガイドを読んで変更すべき点がないかどうかを確認します。
このページでは、2020 バージョンから 2021 LTS にアップグレードする際に、既存のプロジェクトに影響を与える可能性のある Unity 2021 LTS バージョンの変更点を記載しています。
ノート: 2021LTS は、2021.3 とも呼ばれます。
Device Simulator は、エディターの一部となり、ゲームビューからアクセスできるようになりました。
Device Simulator を設定するには、UnityEngine.Device
名前空間を Screen、Application、SystemInfo クラスに加えます。
UnityEngine.Device.Screen;
UnityEngine.Device.Application;
UnityEngine.Device.SystemInfo;
UnityEngine.Device
に切り替えるには、シミュレーターで使用したい各スクリプトに以下のロジックを加えてください。
using Screen = UnityEngine.Device.Screen;
using Application = UnityEngine.Device.Application;
using SystemInfo = UnityEngine.Device.SystemInfo;
新しい名前空間 UnityEngine.Device
は、ランタイムビルドで Simulator (エディター内の場合) から実際のデバイス API にスムーズに移行します。
エディターは、デフォルトの [スカイボックス(skyboxes-using) プローブと アンビエントプローブ を自動的にベイクし、手動でシーンをベイクするまでそのデータを維持するようになりました。アップグレードすると、アンビエントライトの影響がないシーンは視覚的に変化する場合があります。これらのシーンの元の外観を復元するには、環境ライティングの Intensity Multiplier を 0 に設定します。または、スカイボックスを黒に設定してシーンをベイクしてから、スカイボックスを好みの空の色に再設定します。
Unity の Progressive Lightmapper は、デフォルトですべてのシーンのアンビエントプローブ とスカイボックスリフレクションプローブを自動的に生成するようになりました。つまり、Lighting 設定パネルの Environment タブの設定に従って、シーンが自動的に環境ライテ ィングを受け取ることを意味します。エディターは、ライトを生成するまで、環境ライティングが変わるたびにアンビエントプローブとスカイボックスのリフレクションプローブを更新します。Generate Lighting コントロールを使用してベイクすると、エディターはプローブの更新を停止し、次のベイク時にのみプローブを再更新します。Auto Generate オプションを有効にすると、環境ライトが変わるたびにエディターはプローブを更新し続けま す。ライトを生成してから、プロジェクトからライティングデータアセットを削除してこのライティングデータを削除すると、エディターはアンビエントプローブとスカイボックスのリフレクションプローブを自動的に再生成します。
プロジェクトのアップグレードを行う際に、対応が必要な状況があります。これは、プロジェクトに環境ライティングの影響をまったく受けたくない場合で、以下の条件のときです。
このような場合は、Window > Rendering > Lighting Settings > Environment に移動し、以下のいずれかの変更を行って、自動生成されたアンビエントプローブとスカイボックスのリフレクションプローブの環境への影響を無効にし てください。
Code Coverage を管理するためのユーザーインターフェースは、一般環境設定から Code Coverage package 内に移動しました。
Code Coverage のパッケージは、Unity 2019.3 以上の Package Manager を通し、リリースパッケージとして提供されています。最新バージョンは 1.0.0 です。
Code Coverage を有効にするには、以下の方法のいずれかを使用します。
-enableCodeCoverage
を使用します。Coverage.enabled
API を使用します。以下はクラス例です。// CodeCoverageMenuItem という名前の新しい C# スクリプトを作成し
// Editor フォルダーの下に配置します。
// このクラスは、Code Coverage > Enable Code Coverage の下にトグルメニューを作成します。
// それを使って、Code Coverage を有効化/無効化します。
using UnityEditor;
using UnityEngine.TestTools;
class CodeCoverageMenuItem
{
const string EnableCodeCoverageItemName = "Code Coverage/Enable Code Coverage";
[MenuItem(EnableCodeCoverageItemName, false)]
static void EnableCodeCoverage()
{
Coverage.enabled = !Coverage.enabled;
}
[MenuItem(EnableCodeCoverageItemName, true)]
static bool EnableCodeCoverageValidate()
{
Menu.SetChecked(EnableCodeCoverageItemName, Coverage.enabled);
return true;
}
}
以前は、一部の Force Field プロパティが異なるフレームレート (または Time Manager 設定で Time Scale を使用する場合)で異なる動作をすることがありました。
パーティクルシステムは、30fps の基準フレームレートを使用してシミュレーションを行うようになりました。アプリケーションが異なるフレームレートで動作する場合、以下の設定は以前のバージョンの Unity と比較して動作が異なる可能性があります。
これらの設定が影響を受ける場合は、望ましい外観になるようにその部分の強度を調整してください。
以前は、Rate over Distance 放出は Start Delay の設定を無視していました。現在では、Start Delay 設定が定義されている場合、距離に基づく放出の開始を遅らせることができます。
このフィールドが以前に設定されていた場合、調整が必要な場合があります。
PackedAssets.file は、直接代替することなく廃止されました。以前は、BuildReport.files に ID またはインデックスを意味する整数が格納されていました。 BuildReport のファイルを検索するには、PackedAssets.shortPath を使用してください。
実験的な Terrain API は、非実験的な名前空間に移動されました。また、Terrain API にいくつか小さな変更を加えました。実験的な Terrain API を使用していた場合、代わりに以下の API を使用してください。
UnityEngine.TerrainTools
;UnityEditor.TerrainTools
;UnityEngine.TerrainUtils
;以下は、API 変更の全リストです。
UnityEngine.Experimental.TerrainAPI
と UnityEditor.Experimental.TerrainAPI
は、それぞれ UnityEngine.TerrainTools
と UnityEditor.TerrainTools
に変更され ています。ランタイム API の一部は、新しい UnityEngine.TerrainUtils
名前空間に移されています。TerrainPaintTool<T>
クラスの GetDesc()
は、GetDescription()
に名称変更されました。TerrainUtility
クラスは UnityEngine.Experimental.TerrainAPI
から UnityEngine.TerrainUtils
へ移されています。TerrainUtility.TerrainMap
クラスは内部クラスではなくなり、UnityEngine.TerrainUtils
名前空間に属します。TerrainMap.TileCoord
構造体は TerrainMap
クラスではなくなり、TerrainTileCoord
に名称変更され、UnityEngine.TerrainUtils
名前空間に含まれるようになりまし た。UnityEditor.Experimental.TerrainAPI.BrushPreviewMode
enum は TerrainBrushPreviewMode
に名称変更され、UnityEditor.TerrainTools
名前空間に移されました。TerrainPaintUtilityEditor.BuiltinPaintMaterialPasses
enum は TerrainPaintUtilityEditor
クラスから UnityEditor.TerrainTools
名前空間に移されました。また、TerrainBuiltinPaintMaterialPasses
に名称変更されました。IOnInspectorGUI
の 3 つの ShowBrushGUI
関数は、異なるオーバーロードされた関数ではなく、デフォルトのパラメーター値を持つ 1 つの関数に統合されました。TerrainFilter
は削除されました。System.Predicate<Terrain>
を代わりに使用してください。Texture2D.Resize
とそのオーバーロードは Texture2D.Reinitialize
に名称が変更されました。
API Updater は自動的にこの名前を変更します。そうでない場合は、Texture2D.Resize
の使用箇所を Texture2D.Reinitialize
に変更してください。
Android のビルドパイプラインの大部分はインクリメンタルになり、Unity は以前のビルドパイプラインにあった以下の機能を排除しました。
libil2cpp.so
シンボルを生成します。デフォルトの Image.scaleMode が ScaleAndCrop から ScaleToFit に変更されました。
画像に期待される動作は、要素の大きさに合わせて拡大縮小することです。そこで、Image.scaleMode のデフォルト値を ScaleToFit に変更しました。 もし、Image のスケールモードをオーバーライドしなかった場合、一部のクロップされた画像は、要素のサイズに合うように縮小されることがあります。 ScaleAndCrop が画像にとって期待されるモードである場合、UXML ファイルのインラインスタイルに以下の値を追加することで、そのスタイルをオーバーライドすることができます。
-unity-background-scale-mode: scale-and-crop;
また、オーバーライドしてスタイルクラスを作成し、ScaleAndCrop を必要とする画像に適用することも可能です。
基盤となる C# ランタイム、Mono が最新版にバージョンアップされました。これには、Mono の既存バージョンからの多くの修正と、いくつかの注目すべき動作の変更が含まれています。
Directory.GetFiles
は、ソートされたリストを返すことが保証しなくなりました。
Directory.GetFiles(dir).OrderBy(f => f)
;Object.GetHashCode
は異なる値を返すようになったので、オペレーティングシステム間の決定論的なハッシュアルゴリズムとして信頼すべきではありません。
GetHashCode
の結果を現在のプロセスの外部で使用すべきではありません。つまり、シリアル化したり、次に新しいプロセスでコードが実行されたときに同じであることを期待しないでください。Unity では、MD5 のような決定論的なハッシュアルゴリズムを使用することを推奨しています。Adaptive Performance パッケージのバージョン 3.0 が使用できるようになりました。バージョン 3.0 へのアップグレードの方法に関しては、Adaptive Performance アップグレードガイド を参照してください。
以前は、RenderTexture.depth
プロパティを 32 ビットに設定すると、プラットフォームによっては D24_S8 になることがありました。現在、32 ビットに設定すると、現在のプラットフォームでその形式がサポートされている場合、深度コンポーネントに 32 ビットを使用して D32_S8 になります。ただし、この場合、深度バッファのメモリ使用量が 2 倍になります。
新しいRenderTexture.depthStencilFormat
プロパティは、グラフィックス API がビデオメモリ内のリソースを作成するために使用する形式を返します。このプロパティを使用して、特定の形式を要求することもできます。ただし、すべてのプラットフォームがすべての深度ステンシル形式をサポートするわけではありません。DepthStencilFormat
プロパティをサポートされていない形式に設定すると、Unity は自動的に、深度およびステンシルコンポーネントに同等以上のビット数を持つ、互換性のある形式を選択します。
RenderTexture アセットは、選択した深度ステンシル形式をシリアル化するようになりました。形式の代わりにビット数を受け取る API を使用する場合、これらのビットは形式にマップされ、その形式がシリアラル化されます。深度を 16 ビットより大きく設定した古いバージョンの RenderTexture アセットは、D24_S8 を使用するように自動的にアップグレードされます。
DirectX グラフィックス API を使用する一部のプラットフォーム (Windowsなど) では、16 ビットより大きく設定するとグラフィックスバックエンドが内部で D32_S8 形式を選択するため、深度ビットの少ない形式になります。すべてのプラットフォームで一貫したアップグレードを保証するために、すべてのプラットフォームで自動アップグレードに D24_S8 が使用されています。ただし、プロジェクトに RenderTexture アセットがある場合、プロジェクトのレンダー出力に視覚的なアーティファクトが発生する可能性があります。これらのアセットを確認し、必要に応じて深度ステンシル形式を D32_S8 に変更してください。以下の問題が発生する可能性があります。
以下のグラフィックス形式は現在非推奨となっています。
これらの Auto の形式は正確な形式が不明確であり、プラットフォームによって異なる可能性があります。
これらの非推奨形式の使用を廃止する手順は、形式と使用ケースに依存します。
現在のプラットフォームの自動ビデオ形式を取得するには、 SystemInfo.GetGraphicsFormat(DefaultFormat.Video)
を使用します。
GraphicsFormat API では、DepthAuto または ShadowAuto を使用して、深度のみのレンダリング、およびカラーバッファを使用しないレンダーテクスチャを作成することがよくあります。この使用例は以下の通りです。
renderTextureDescriptor.graphicsFormat = GraphicsFormat.ShadowAuto
RenderTexture.GetTemporary(width, height, bits, GraphicsFormat.ShadowAuto)
深度のみ (カラーなし) のレンダリングを示すには、新しいカラー形式として GraphicsFormat.None を使用します。
renderTextureDescriptor.graphicsFormat = GraphicsFormat.None;
ShadowAuto を使用する場合は、RenderTextureDescriptor の shadowSamplingMode を ShadowSamplingMode.CompareDepths に設定して深度テクスチャの深度比較サンプリングを有効にし、RenderTextureDescriptor を受け取るオーバーロードを使用するようにコードを変更します。
renderTextureDescriptor.shadowSamplingMode = ShadowSamplingMode.CompareDepths;
一部の状況では、DepthAuto/ShadowAuto 形式は、現在のプラットフォームに適した自動的に選択された深度形式を表していました。このような場合に非推奨の値を置き換えるには、SystemInfo.GetGraphicsFormat(DefaultFormat.Depth/Shadow)
を使用します。
上級者向けに提供していた asm.js リンカーターゲットは廃止されました。
Pointer_stringify()
は、現在非推奨です。代わりに、関数 UTF8ToString()
を呼び出して、WebAssembly ヒープから UTF8 エンコードされたヌル終端 (null-terminated) C 文字列を JavaScript 文字列にマーシャリングしてください。Progressive GPU Lightmapper は、CPU OpenCL デバイスをサポート終了しました。サポートされている GPU が見つからず、CPU OpenCL デバイスが検出される場合、そのデバイスがスキップされ、Progressive CPU Lightmapper にフォールバックされることを警告メッセージが通知します。Progressive CPU Lightmapper は、ライトマップの CPU ベースの計算のパフォーマンスを向上させます。 この動作の変更は自動的に行われ、ライトマップは期待どおりに計算されます。
Unity がアセットインポート処理中に InitializeOnLoad
メソッドを呼び出すと、アセットのロードに失敗することがあります。アセットインポート中、アセットデータベースは更新状態にあり、Unity はどのアセットが既にインポートされているかを判断できません。InitializeOnLoad
メソッドは、インポートされていないアセットをロードすることはできません。
アセットインポートプロセスを改善するために、OnPostprocessAllAssets
コールバックが改善されました。特に、OnPostprocessAllAssets
コールバックが強化されています。
didDomainReload
パラメーターを含み、ドメインが再ロードされた場合、true に設定されます。アセット操作を必要とするドメイン関連の初期化ロジックを OnPostprocessAllAsset
コールバックに移動します。InitializeOnLoad
メソッド内でアセット操作を実行しません。
以下の動作変更コード例では、以前、アセット操作を先送りにされていたかを示しています。
例 1
public class AssetPostprocessorTester1 : AssetPostprocessor
{
static void OnPostprocessAllAssets(string[] importedAssets, string[] deletedAssets, string[] movedAssets, string[] movedFromAssetPaths)
{
var assetPath = "Assets/hello.txt";
if (File.Exists(assetPath))
{
var txtObj = AssetDatabase.LoadAssetAtPath<TextAsset>("Assets/hello.txt");
AssetDatabase.DeleteAsset("Assets/hello.txt");
if (txtObj == null)
Debug.Log("New Behaviour: Asset object is unloaded");
else
Debug.Log("Old Behaviour: Asset is loaded for deleted asset!!");
}
}
}
例 2
public class AssetPostprocessorTester2 : AssetPostprocessor
{
static void OnPostprocessAllAssets(string[] importedAssets, string[] deletedAssets, string[] movedAssets, string[] movedFromAssetPaths)
{
var assetPath = "Assets/SomeText.txt";
if (!File.Exists(assetPath))
{
File.WriteAllText(assetPath, "hello world");
AssetDatabase.ImportAsset(assetPath);
var txtObj = AssetDatabase.LoadAssetAtPath<TextAsset>(assetPath);
if (txtObj == null)
Debug.Log("Old Behaviour: Asset hasn't been imported yet");
else
Debug.Log("New Behaviour: Asset is imported and loaded");
}
}
}
次の例には、didDomainReload
パラメーターを持つ新しい OnPostprocessAllAssets
バリアントが含まれています。
static void OnPostprocessAllAssets(string[] importedAssets, string[] deletedAssets, string[] movedAssets, string[] movedFromAssetPaths, bool didDomainReload)
{
if (didDomainReload)
Debug.Log("Domain has been reloaded");
else
Debug.Log("Domain did not reload during import");
}
すべてのドメインの再ロードは、アセットデータベース内で処理されるようになりました。
OnPostprocessAllAssets
は、アセット操作でよりよく動作するようになりましたが、このコールバックでの処理は、アセットデータベースのリフレッシュとドメインの再ロード時間を増加させます。InitializeOnLoad
メソッドもドメインの再ロード時間を増加させます。これらのコールバックでの処理を最小限にすることが、繰り返しの間のエディターの応答性を向上させるためには効率的です。
Mixed モード のポイントライトとスポットライトは、Shadow Type の設定に関わらず、Subtractive ライティングモード を使ってシーンのベイクした直接光に常に影響するようになりました。その結果、静的ゲームオブジェクトのスペキュラーライティングが、影響を受けるシーンで欠落しているように見えることがあります。この問題を解決するには、影響を受ける Mixed モードのライトを Realtime モードライト に置き換えます。または、Baked Indirect または Shadowmask ライティングモードを混合ライトと一緒に使用します。
シェーダキーワードシステムは、シェーダまたはコンピュートシェーダごとに最大 65534 のローカルキーワードと、プロジェクトごとに 232–2 のグローバルキーワードを使用できるようになりました。シェーダーまたはコンピュートシェーダーで宣言するすべてのキーワードは、このシェーダーに対してローカルになりました。 _local というサフィックスを持つディレクティブで宣言したキー ワードは、グローバルキーワードの状態に影響されません。
例:
シェーダ内のパスは、以下のキーワードを宣言します。
#pragma shader_feature FOO BAR
#pragma shader_feature_local BOO BAZ
このパスを使用すると、キーワード FOO と BAR は、グローバルまたはマテリアル上で有効になっている場合に有効になります。キーワード BOO と BAZ は、マテリアル上で有効になっている場合のみ有効です。
Unity は、.NET Standard 2.1 API のすべての API を含む、.NET 基本クラスライブラリの多くの追加 API をサポートするようになりました。新しい API と競合するコードがある場合、プロジェクトはコンパイルに失敗する可能性があります。
以前のバージョンの Unity で作成したプロジェクトをアップグレードする際にエラーを避けるために、.NET Standard 2.1 で利用可能になった型やメソッドと競合しないようにコードを確認し、更新してください。
競合の原因としては、以下のようなものがあります。
.NET Standard 2.1 が加える型やメソッドと競合する名前を持つ型やメソッドをコードに実装すると、コンパイルに失敗します。名前の競合は、あいまいな参照が原因の C# コンパイラーエラーにつながる可能性があります。
例えば、MyCompany.MyCode.Range
という型をプロジェクトのコードに加える場合、既存の System.Range
型と競合する可能性があります。using System;
と using MyCompany;
の両方のステートメントを含むコードは、コンパイルに失敗します。
エラーを防ぐため、C# のコードでは、名前が競合する型については、すべて名前空間を指定してください。
既存のコードに .NET Standard 2.1 が直接型に実装した拡張メソッドがある場合、拡張メソッドの名前を変更するか、基本クラスライブラリで実装されたメソッドを使用するかを選択できます。
例えば、プロジェクトのコードは、ArraySegment
型に CopyTo
という拡張メソッドを実装したとします。.NET Standard 2.1 では、ArraySegment
にビルトインの CopyTo
というメソッドがあります。この場合、CopyTo
拡張メソッドの名前を変更するか、または、完全にそれを削除してビルトインのメソッドを使用するかを選択できます。
もしプロジェクトが、現在基本クラスライブラリの一部となっている型やメソッドを実装したプリコンパイルされたアセンブリ (つまりマネージプラグイン) を使用している場合は、プロジェクトからこれらのアセンブリを削除してビルトインの実装を使用するようにしてください。
例えば、Unity の以前のバージョンでは、System.Span
値の型にアクセスするために、NuGet から System.Memory.dll
アセンブリを使用する必要がありました。現在、.NET Standard 2.1 では、基本クラスライブラリで System.Span
が提供されています。 System.Memory.dll
マネージプラグインを Unity 2021.2 で使用しようとすると、プロジェクトはビルドに失敗します。
Microsoft は、Windows XR プラグインを非推奨とし、OpenXR プラグインを通じて Windows Mixed Reality (WMR) 機能とデバイスをサポートするようになりました。
Unity OpenXR プラグインにアップグレードする場合は、以下を行います。
OpenXR プラグインが有効になると、Microsoft が提供する Mixed Reality Feature Tool を使って、必要なサポートパッケージをインストールできます。
WMR の機能、ツール、サンプルをインストールまたはアップデートするには、以下を行います。
Windows Mixed Reality を使用するための Unity プロジェクトの新規および更新の設定については、Microsoft のドキュメントサイトの Setting up your XR configuration を参照してください。