このページには、2022 LTS バージョンから Unity 6 へのアップグレード時に既存のプロジェクトに影響を与える可能性がある、Unity 6 の変更点を記載しています。
このアップグレードガイドでは、Unity のビルトインレンダーパイプラインの Unity 6 バージョンへのアップグレード方法を説明します。他のレンダーパイプラインをアップグレードするには、以下を参照してください。
他のパッケージをアップグレードする場合は、使用しているパッケージのドキュメントを参照してください。
プログレッシブなライトマッパーの上級者向けフィルタリングオプションにはガウシアンオプションがあります (Lighting ウィンドウ > Lightmapping Settings > Filtering > Direct Filter > Gaussian)。ガウシアンフィルタリングの半径コントロールは、0.5 などの 10 進数の増分をサポートするようになりました。以前は、このコントロールは整数ステップ（1 - 5）のみをサポートしていました。
この変更の結果、これらのプロパティは C# API で非推奨になりました。
int LightingSettings.filteringGaussRadiusAOint LightingSettings.filteringGaussRadiusDirectint LightingSettings.filteringGaussRadiusIndirect非推奨となったプロパティの浮動小数点は以下のように置き換えられています。
float LightingSettings.filteringGaussianRadiusAOfloat LightingSettings.filteringGaussianRadiusDirectfloat LightingSettings.filteringGaussianRadiusIndirect非推奨メンバー関数のいずれかを呼び出して、ガウシアンフィルター半径を端数処理して最も近い整数に設定できます。
ライトプローブはライトマップと同じくらい明るくなりました。以前は、Unity のライトプローブの輝度は 94% にとどまっていました。このため、ライトプローブで照らされたオブジェクトは、ライトマップで照らされたオブジェクトよりもやや暗く表示されていました。この変更は小さなものであるため、多くのユーザーに認識可能な違いが見られない可能性があります。
以前の外観が必要な場合は、以下の方法で実現できます。
Enlighten のベイクしたグローバルイルミネーションのライトマッピングバックエンドが使用可能ではなくなりました。
プロジェクトをこのバージョンにアップグレードすると、ライトマッパー選択ドロップダウンから Enlighten ベイキングバックエンドが削除され、Enlighten ベイキングバックエンドを選択したすべてのシーンで、代用として Progressive Lightmapper が使用されます。
Apple シリコンデバイスでは、Unity は Enlighten ベイキングバックエンドをプログレッシブ GPU ライトマッパーに置き換えます。その他のデバイスでは、Unity は CPU プログレッシブライトマッパーを選択します。
Enlighten の事前計算されたリアルタイムグローバルイルミネーションは引き続き使用可能であり、Unity 2024 LTS までサポートされます。
UnityPlayer Java クラスは、UnityPlayerForActivityOrService と UnityPlayerForGameActivity という 2 つの新しいブリッジクラスに置き換えられました。これらの新しいクラスは両方とも UnityPlayer から派生していますが、displayChanged や windowFocusChanged などの一般公開メソッドは、UnityPlayer から UnityPlayerForActivityOrService 専用に変更されました。
デフォルトの Unity アクティビティを拡張して UnityPlayer クラスを使用すると、コンパイルエラーが発生する場合があります。この場合は、UnityPlayer の名前を UnityPlayerForActivityOrService に変更してください。
UnityPlayer Java クラスは FrameLayout を拡張しなくなりました。FrameLayout にアクセスする必要がある場合は、UnityPlayer インスタンスで getFrameLayout 関数を呼び出します。
RenderPipelineEditorUtility.FetchFirstCompatibleTypeUsingScriptableRenderPipelineExtension は非推奨になりました。代わりに GetDerivedTypesSupportedOnCurrentPipeline を使用してください。このメソッドのシグネチャも異なります。このメソッドは、最初に見つかった型だけでなく、派生型もすべて返します。これにより、Unity が型の順序を保証しないため、矛盾を回避できます。
CustomEditorForRenderPipelineAttribute と VolumeComponentMenuForRenderPipelineAttribute は非推奨になりました。代わりに CustomEditor と VolumeComponentMenu を使用してください。これらの属性がアクティブなときにパイプラインの選択を制限するには、SupportedOnRenderPipelineAttribute と組み合わせて RenderPipelineAsset 型を指定します。ビルトインレンダーパイプラインで動作する SRP 属性をアクティベートする場合は、パラメーターなしで SupportedOnRenderPipelineAttribute を使用します。これにより、特定のパイプラインでアクティベートする必要がある場合に、両方の属性の統合ワークフローが提供されます。
Android Gradle プロジェクトを変更する新しい API が導入されました。API を使用して、古い Android Gradle テンプレートのワークフローを置き換えることができます。新しい API が使用されていない場合でも、テンプレートは以前と同様に動作します。
新しい API を使用するには、Templates Upgrader を使用します。
Unity のプログレッシブライトマッパーは、デフォルトでアンビエントプローブとスカイボックスリフレクションプローブをベイクしなくなり、Lighting ウィンドウの Recalculate Environment Lighting 設定は削除されました。
新しく作成されたシーンに環境ライティングが含まれないように、Unity はデフォルトのスカイボックスマテリアルに一致する環境ライティングを含むデフォルトのライティングデータアセットを割り当てます。
以下の場合は、Lighting ウィンドウで Generate Lighting を選択する必要があります。
以前の自動ベイク動作に依存しながらデフォルトの環境ライティング設定を使用する場合、Unity はデフォルトのライティングデータアセットを使用するようにシーンをアップグレードします。
Lighting ウィンドウの Auto Generate 設定は削除され、関連する API は廃止されました。
シーンのベイクしたライティングを生成するには、以下のいずれかを実行します。
Lightmapping.Bake API を使用します。Lightmapping.BakeAsync API を使用します。編集中にライトマップを確認する必要がある場合には、シーンビュー描画モードを選択し、ライティングデータをプレビューに設定できるようになりました。これによってベイクしたライティングのプレビューが表示されます。プレビューマップは非破壊的であるため、シーンをベイクした後に使用できます。
シーンが自動生成ライティングに依存している場合は、ベイクしたライティングは行われなくなります。Lighting ウィンドウで Generate Lighting を選択し、ライティングを手動で再ベイクします。
スクリプトを使用してシーンを開く場合は、自動生成されたライティングの完了を待つのではなく、Lightmapping.Bake または Lightmapping.BakeAsync を使用する必要があります。
以下のグラフィックス形式は、2022.1 で非推奨になりましたが、現在は廃止され、使用するとコンパイルエラーが発生します。
GraphicsFormat.DepthAutoGraphicsFormat.ShadowAutoGraphicsFormat.VideoAutoGraphicsFormatUtility.GetGraphicsFormat API が古い形式を返さなくなりました。代わりに以下の処理を行います。
RenderTextureFormat.Depth を GraphicsFormat.DepthAuto ではなく GraphicsFormat.None に変換します。GraphicsFormat.None は深度のみのレンダリングを示します。RenderTextureFormat.Shadowmap を GraphicsFormat.ShadowAuto ではなく GraphicsFormat.None に変換します。GraphicsFormat.None 形式でレンダーテクスチャを作成する場合は、RenderTextureDescriptor.shadowSamplingMode を ShadowSamplingMode.CompareDepths に設定して深度比較サンプリングを有効にする必要があります。
GraphicsFormat.DepthAuto と GraphicsFormat.ShadowAuto は両方とも深度ステンシル形式とみなされていましたが、カラーフォーマットとして使用されるため、コードの調整が必要な場合があります。
例えば、以下のスニペットでは、GraphicsFormatUtility.IsDepthFormat は true ではなく false を返します。
RenderTextureDescriptor desc = new RenderTextureDescriptor(256, 256, RenderTextureFormat.Depth, 32);
bool isDepthOnly = GraphicsFormatUtility.IsDepthFormat(desc.graphicsFormat);
RenderTexture または RenderTextureDescriptor が深度専用かどうかをチェックするには、以下のいずれかを使用します。
if (renderTexture.graphicsFormat == GraphicsFormat.None && renderTexture.depthStencilFormat != GraphicsFormat.None)if (renderTexture.format == RenderTextureFormat.Depth || renderTexture.format == RenderTextureFormat.Shadowmap)
ランタイムに作成された 2D テクスチャのミップマップアップロードはデフォルトで制限されなくなります。以前は、ミップマップ制限は Texture2D コンストラクター (コンストラクターが TextureFormat で呼び出される場合は ignoreMipmapLimit ブーリアンパラメーター、GraphicsFormat で呼び出される場合は IgnoreMipmapLimit TextureCreationFlag を指定する) によって、または構築されたテクスチャの tex.ignoreMipmapLimit を切り替えることによって明示的に無効にする必要がありました。この動作が変更され、ランタイム作成の 2D テクスチャにミップマップ制限がオプトインされるようになりました。
プロジェクトに変更を加えないと、以下の場合に、ユーザーは GPU 帯域幅とメモリの最適化を見逃し、テクスチャが最大解像度でアップロードされるようになったため、意図した水準よりも品質が低くなる可能性があります。
以下の場合、ユーザーはこの変更の影響を受けません。
ignoreMipmapLimitが false であるコンストラクターを使用、tex.ignoreMipmapLimit を false に設定。これらのユーザーは、非推奨のコンストラクターを使用している場合は、スクリプトをアップグレードすることもできます。
スクリプトをアップグレードするには、MipmapLimitDescriptor を指定して Texture2D コンストラクターを使用し、ランタイムテクスチャが品質設定の影響を受けることを示します。
この変更は、Texture2DArrays の新しいミップマップ制限サポートとの一貫性を確保するために行われました。各テクスチャ形状によって独自のデフォルトのミップマップ制限に関する動作を定義するのではなく、一貫性を確報することを選択し、ランタイムテクスチャが明示的にミップマップ制限を有効にするようにしました。このオプトイン動作はオプトアウトよりも優先されます。ランタイムテクスチャは、予想よりも少ないミップを予期せずアップロードする方が、予想よりも多くのミップをアップロードするよりも有害であるため、より汎用性の高い方法で頻繁に使用されるためです。
UI Toolkit の UXML を使用することによるカスタムコントロールの作成をシンプルにし、ワークフローのスピードと直感的な操作性を向上させました。
主な改善点は、UxmlElement 属性と UxmlAttribute 属性の導入です。これらの属性は、属性のオーサリングを簡素化し、プロパティ名から属性名を自動的に派生させます。そのため、UxmlTraits クラスや UxmlFactory クラスは必要ありません。
特定のデータ型用のカスタム属性コンバーターを作成できるようになりました。これにより、UXML 属性文字列との間で値のシームレスな変換が可能になります。また、UxmlObject も強化され、カスタムの非ビジュアル要素をビジュアル要素内で定義できるようになりました。新しいシステムは、Unity のシリアル化を活用し、ソースジェネレーターを使用して、各カスタム要素クラスのすべての UxmlAttribute 定義から要素の UxmlSerializedData クラスを作成し、カスタムプロパティドロワー、デコレーター、およびさまざまな属性をサポートできるようにします。
“属性オーバーライド” の導入により、UXML 属性の動作をカスタマイズでき、継承された属性を使用する際の柔軟性が向上します。これらの改善により、Unity 2023.2 以降で複雑な UI 要素を作成するためのより効率的でユーザーフレンドリーな操作性が実現します。
例えば、以下のコードサンプルは、UxmlFactory と UxmlTraits を使用して作成したカスタムコントロールです。
public class HealthBar : VisualElement
{
private const float k_LowValue = 0;
private const float k_HighValue = 100;
// Declare as usable with Uxml
public new class UxmlFactory : UxmlFactory<HealthBar, UxmlTraits> { }
// Define attributes (and connect with class properties) for Uxml
public new class UxmlTraits : BindableElement.UxmlTraits
{
UxmlColorAttributeDescription m_Color = new UxmlColorAttributeDescription { name = "color", defaultValue = Color.white };
UxmlFloatAttributeDescription m_Value = new UxmlFloatAttributeDescription { name = "value", defaultValue = k_HighValue };
public override void Init(VisualElement ve, IUxmlAttributes bag, CreationContext cc)
{
base.Init(ve, bag, cc);
var bar = ve as HealthBar;
bar.color = m_Color.GetValueFromBag(bag, cc);
bar.value = m_Value.GetValueFromBag(bag, cc);
}
}
public Color color { get; set; }
[Range(k_LowValue, k_HighValue)]
public float value { get; set; }
}
以下のコードサンプルは、以前のコードサンプルと同じ動作をしますが、新しい UxmlElement と UxmlAttributes システムを使用します。
[UxmlElement]
public class HealthBar2 : VisualElement
{
private const float k_LowValue = 0;
private const float k_HighValue = 100;
[UxmlAttribute]
public Color color { get; set; } = Color.white;
[UxmlAttribute]
[Range(k_LowValue, k_HighValue)]
public float value { get; set; } = k_HighValue;
}
その他の例と情報については、Unity UI Toolkit ドキュメントを参照し、今秋の詳細なブログ投稿にご期待ください。
Assets/Create メニューが再編成され、分類されました。このオーバーホールの一環として、Unity ビルトインスクリプトテンプレートファイルの名前が変更されました。
CreateAssetMenuAttribute``, MenuItemAt 属性またはカスタムスクリプトテンプレートを使用して Assets/Create メニューに要素を追加したユーザーは、他の要素に対する相対的な配置が異なるため、メニュー項目の優先順位を変更することが必要な可能性があります。
EditorApplication.ExecuteMenuItem API でこれらのメニュー項目を実行してアセットを作成していたユーザーは、メニュー項目への新しいパスを確認する必要があります。
以前に Unity ビルトインスクリプトテンプレートをオーバーライドしたことがあるユーザーは、オーバーライドファイルの名前を更新して、ビルトインの新しい名前と一致することを確認する必要があります。
ExecuteDefaultAction メソッドと ExecuteDefaultActionAtTarget メソッドは非推奨になりました。CallbackEventHandler から派生したこれらのメソッドは、VisualElement のサブクラスに影響します。イベントの伝播を処理するためにこれらのメソッドをオーバーライドまたは呼び出しするカスタム VisualElement サブクラスがある場合は、これらのメソッドはイベントでのデフォルトアクションの処理には推奨されなくなった点に留意してください。この変更は、CallbackEventHandler からの継承のため、VisualElement から派生するほとんどのユーザーに影響します。
ExecuteDefaultAction と ExecuteDefaultActionAtTarget を置き換えるために以下のメソッドが追加されました。
HandleEventTrickleDownHandleEventBubbleUpUnity は、イベントディスパッチパスの各要素に対して、対象要素のコールバックの TrickleDown の直後と BubbleUp の前にこれらの新しいメソッドを実行します。これらのメソッドの間、ディスパッチフェーズはそれに応じて TrickleDown または BubbleUp に設定され、イベントの currentTarget はメソッドを実行する要素と一致します。
AtTarget ディスパッチフェーズと PreventDefault メソッドは非推奨になりました。StopPropagation または StopPropagationImmediately の呼び出しは、HandleEventTrickleDown および HandleEventBubbleUp コールバックの以降の呼び出しを停止すると同時に、TrickleDown および BubbleUp コールバックの以降の実行を停止するようになりました。
新しいメソッドにアップグレードしないほとんどの場合について、コードの動作に大きな変化はありません。UI Toolkit は、古いメソッドを以前と同じ順序、または最小限の調整を行った状態で呼び出します。ただし、UI Toolkit 内のすべての標準コントロールは新しいメソッドを使用するように移行されロジックの実行順序が適宜調整されています。古いメソッドの呼び出しとアップグレードされたコントロールの使用を混在させると、一部のロジックが以前のバージョンの Unity に対して同期しない場合があります。
既存のコードを新しいメソッドにアップグレードするには、次の手順に従います。
ExecuteDefaultAction と ExecuteDefaultActionAtTarget を HandleEventBubbleUp で置換し、PreventDefault を StopPropagation で置換します (または、StopPropagation が同じコードブロック内ですでに呼び出されている場合は、PreventDefault の呼び出しを削除します。これは、ほとんどのケースをカバーします)。BubbleUp コールバック中の古いコード呼び出し PreventDefault が原因で問題が発生し、それが不可能になり、イベントがすでにターゲットに達しているために StopPropagation で置き換えることができない場合は、StopPropagation を呼び出す TrickleDown フェーズでコールバックを追加することを検討してください。通常は、このステップでこのようなシナリオに十分に対処できます。
Unity シェーダーと Metal シェーダーのクロスコンパイルは、バッファレイアウトに関して変更されました。min16float 型、half 型、real 型を含むバッファのメモリレイアウトが以前のバージョンの Unity と異なるようになりました。
Metal をターゲットとし、Raw データをバッファに直接書き込む API を使用する場合にのみ対応する必要があります。以下に例を示します。
CommandBuffer.SetComputeFloatParam または Material.SetFloat のみを使用する場合は、対応する必要はありません。
具体的には、HLSL の min16float、half、および real inside の各バッファは常に 32 ビット MSL Float に変換されますが、Unity の以前のバージョンでは、ターゲットプラットフォームに応じて 16 ビット MSL half に変換されていました。
Metal プラットフォームでのみシェーダーをテストした場合は、生成された MSL コードのバッファを確認して、レイアウトが C# でアクセスされバッファデータと一致していることを確認します。シェーダーコードに #pragma metal_fxc_allow_float16_in_cpu_visible_buffers を追加し、ビジュアルアーティファクトが修正されているかどうかを確認することで、この変更がシェーダーに影響するかどうかをテストできます。違いに気付いた場合は、このプラグマを削除してシェーダーと C# コードを調整し、プラグマがなくても正しく動作するようにして、プロジェクトのクロスプラットフォーム互換性を向上させてください。
バッファでネイティブ 16 ビット float を使用するには、DXC HLSL コンパイラーの使用とシェーダーへの #pragma require Native16Bit の追加を検討してください。ただし、Unity での DXC の使用はまだ実験的段階です。
グローバルパッケージキャッシュには、いくつかのサブフォルダーが含まれます。これらのサブフォルダーの 1 つである packages は、Package Manager では使用されなくなりました。
グローバルパッケージキャッシュの packages サブフォルダーと直接相互作用する自動化スクリプトまたはパイプラインがある場合、例えば UPM_CACHE_PATH 環境変数を使用する場合にのみ対応する必要があります。その場合は、参照を削除できます。Unity には、packages の直接置換サブフォルダーは用意されていません。パッケージがプロジェクトキャッシュに直接抽出されるようになりました。
Unity 2023.2 で作成されたプロジェクトを維持しない場合は、グローバルパッケージキャッシュルートから packages サブディレクトリを安全に削除できます。この操作は任意です。
以前のバージョンの Unity エディターでは、UPM_CACHE_PATH 環境変数を使用して、Package Manager がパッケージの tarball の非圧縮コンテンツを保存する場所への絶対パスを指定することができました。
UPM_CACHE_PATH にパス値を設定する自動化スクリプトまたはパイプラインがある場合にのみ対応する必要があります。パッケージはプロジェクトキャッシュに直接抽出されるようになったため、UPM_CACHE_PATH に置き換わる機能はありません。ただし、以前は UPM_CACHE_PATH を使用していた場合について、グローバルキャッシュのルートを設定する UPM_CACHE_ROOT 環境変数を使用できるようになりました。グローバルキャッシュルートは、以前は UPM_CACHE_PATH と関連付けられていたサブフォルダーの親ディレクトリです。
詳細については、グローバルキャッシュのカスタマイズを参照してください。
Unity は、Android によって使用される以下のツールのデフォルトバージョンを更新しました。NDK、SDK コマンドラインツール、SDK ツールのデフォルトバージョンは変更されていません。更新後のバージョンは以下のとおりです。
| ツール | バージョン |
|---|---|
| Gradle | 8.4 |
| Android Gradle プラグイン | 8.3.0 |
| SDK ビルドツール | 34.0.0 |
| SDK プラットフォームツール | 34.0.5 |
| Java Development Kit (JDK) | 17 |
プロジェクトでカスタム Gradle テンプレートを使用する場合は、それらのテンプレートを再作成して、Android Gradle プラグインの最新バージョンでのビルドに関する問題を回避することを検討してください。詳細については、Gradle テンプレートファイルを使用した Gradle プロジェクトファイルの変更を参照してください。
Unity エディターの以前のバージョンには、zstandard 圧縮をサポートする 7-Zip フォークが含まれていました。
Windows バージョンには、mcmilk/7-Zip-zstd のフォークである 7-Zip-zstd (アップストリーム 7-Zip バージョン 22.01 のフォーク) が含まれていました。このコードは、CVE–2023–31102 や CVE–2023–40481 などの既知のセキュリティ問題に対して脆弱です。
macOS および Linux バージョンには、tehmul/p7zip-zstd (2017 年に廃止) のフォークである p7zip-zstd が含まれていました。p7zip-zstd は、アップストリーム 7-Zip のフォークである p7zip (2016 年に廃止) のフォークです。このコードは、CVE–2016–7804、CVE–2017–17969、CVE–2018–10115、CVE–2018–10172、CVE–2018–5996、CVE–2023–31102、CVE–2023–40481 などの既知のセキュリティ問題に対して脆弱です。
Unity 6 には、Windows、macOS、および Linux の 7-Zip エディターの標準アップストリームバージョン 23.01 が含まれています。ただし、この 7-Zip のアップストリームバージョンは、.zip または .7z アーカイブの zstandard 圧縮と解凍をサポートしません。また、mcmilk/7-Zip-zstd フォークで追加されたその他の圧縮形式とハッシュアルゴリズムもサポートされません。
zstandard 圧縮を使用してアーカイブを操作する 7za または 7z.exe バイナリを使用するパッケージがある場合は、以下のいずれかのオプションを使用します。