ここでは、Unity の以前のバージョンからアップグレードするときに、既存のプロジェクトに影響を与える可能性のある Unity 2018.1 の変更点を列挙します。
以前のバージョンでは、ゲームオブジェクトが無効にされたり破壊されたりすると、その子の MonoBehaviour で実行中のコルーチンのすべてが停止されました。ただし、特定の場合である、ゲームオブジェクトが無効にされたり破壊されたりする瞬間に呼び出されたメソッド (例えば、OnBecameInvisible()) で開始されたコルーチンは実行することができました。それが原因で、コンポーネントの順序特有の挙動が発生し、場合によってはクラッシュしました。
Unity 2018.1 では、ゲームオブジェクトを無効化または破棄した状態で返されたコルーチンは実行されなくなりました。
BuildPipeline.BuildPlayer、BuildPipeline.BuildAssetBundles などの BuildPipeline API は、以前は文字列を返していました。ビルドが成功した場合は空で、ビルドが失敗した場合はエラーメッセージが表示されました。
2018.1 では、これは新しい BuildReport オブジェクトに変更されました。このオブジェクトには、ビルド処理に関するより豊富な情報が含まれています。
ビルドが成功したかどうかを確認するには、report オブジェクトの summary プロパティーを取得し、その result プロパティーを確認します。ビルドが成功した場合は BuildResult.Succeeded になります。
var report = BuildPipeline.BuildPlayer(...);
if (report.summary.result != BuildResult.Succeeded)
{
throw new Exception("Build failed");
}
以前は、Unity のスタンドアロンプレイヤーが終了したときに通知を受けるには、MonoBehaviour に OnApplicationQuit メソッドを実装し、プレイヤーの終了をキャンセルするには Application.CancelQuit を呼び出していました。
2 つの新しいイベントが導入されました。これらは Application.wantsToQuit と Application.quitting です。Unity スタンドアロンプレイヤーの終了時に通知を受けるためには、これらのイベントをリッスンします。Application.wantsToQuit は、プレイヤーが終了しようとするときに呼び出されます。wantsToQuit のリスナーは true または false を返す必要があります。プレイヤーに終了を続けさせたい場合は true を返し、終了をキャンセルする場合は false を返します。Application.quitting イベントは、プレイヤーが終了することが確実でキャンセルできない場合に呼び出されます。
Application.CancelQuit は非推奨になりました。代わりに Application.wantsToQuit を使用してください。
using UnityEngine;
public class PlayerQuitExample
{
static bool WantsToQuit()
{
// エディターを終了したいですか?
return true;
}
static void Quit()
{
Debug.Log("Quitting the Player");
}
[RuntimeInitializeOnLoadMethod]
static void RunOnStart()
{
Application.wantsToQuit += WantsToQuit;
Application.quit += Quit;
}
}
この変更は WSAPlayerX86、WSAPlayerX64、WSAPlayerARM のランタイムプラットフォームに影響します。
今のところ、代替手段はありません。
新しい TouchScreenKeyboard.status では、非推奨の状態やその他の状態を含む参照もできます。
MonoDevelop 5.9.6 は、macOS インストーラーのバンドル C# スクリプトエディターとして、macOS の Visual Studio for Mac に置き換えられました。Visual Studio 2017 Community は、Windows の Unity と共にインストールされる唯一の C# スクリプトエディターです。
MonoDevelop を Unity 実行ファイル近くのデフォルトの場所にインストールしても、Unity はそれを環境設定の外部スクリプトエディターとして指定している「MonoDevelop (built-in)」として認識しなくなります。C＃スクリプトエディターがインストールされておらず、環境設定で選択されていない場合、Unity は C# (.cs) スクリプトを開くためにシステムデフォルトのアプリケーションを使用します。
BuildPipeline コールバックインターフェースで、IPreprocessBuild、IPostprocessBuild、IProcessScene は変更され、BuildReport オブジェクトに渡すように変更されました。 これはビルドパス/ターゲットプラットフォームの以前のパラメーターを置き換えます。これらのインターフェースを実装している場合は、コードを変更する必要があります。
ビルドパスとターゲットプラットフォームの両方が、BuildReport オブジェクトからアクセスできます。ビルドパスは report.summary.outputPath になり、ターゲットプラットフォームは report.summary.platform になります。
以前は、プラグインフォルダー (例えば、拡張子が .bundle、.plugin、.folder のディレクトリなど) にあるアセットは、専用のインポーターを使用してインポートされていました。テクスチャはテクスチャインポーター、オーディオクリップはオーディオインポーターなどを通してインポートされました。現在、これらすべてのアセットはデフォルトのインポーターを使用してインポートされるようになりました。つまり、以前のようにそれらのアセットを参照できなくなりました。なぜなら、タイプ (テクスチャ、オーディオクリップなど) が廃止されたからです。プラグインフォルダーはパッケージに含まれているため、プラグインでアクセスする方法以外では、内部のアセットに外からアクセスすることはできません。
これらのアセットを使い続けるには、それらをプラグインフォルダーの外に移動する必要があります。
メッシュにピボットオフセットを適用するために使用された数式が正しくなく、ビルボードパーティクルに対する機能の仕方が一定でありませんでした。正しいスケールを実現するには、ピボットオフセットにパーティクルのサイズを掛けます。すると、ピボットオフセットの 1 がパーティクルの全幅の 1 倍と等しくなります。
メッシュの場合、サイズは 2 倍になっていました。つまり、ピボットの値はパーティクルサイズを 2 乗してから使用していました。 このため、さまざまなサイズのパーティクルを含むシステムで一貫した結果を得ることは不可能でした。
同じサイズのパーティクルを使用するシステムでは、この振る舞いの変化を補正するために、式をリバースエンジニアリングしてピボットオフセットを調整する量を決定できます。この動作の変更は以下のように行われています。
古い式: offset = size * size * pivot
新しい式: offset = size * pivot
従って、すべてのパーティクルのサイズが等しい場合は以下のようになります。
newOffset = pivot / size
パーティクルのサイズがばらばらのシステムでは、対象のシステムの視覚的な再評価が必要になります。
2018.1 から、グローバルイルミネーション (GI) は Unity の GPU インスタンシングレンダリングによってサポートされています。各 GPU インスタンスは、異なる ライトプローブ、1 つの ライトマップ (ただしアトラスでは異なる範囲)、1 つの Light Probe Proxy Volume コンポーネント (すべてのインスタンスを含む空間ボリューム用にベイク処理) のいずれかからの GI をサポートできます。スタンダードシェーダーとサーフェスシェーダーには変更が自動的に含まれますが、これらの機能を有効にするにはカスタムシェーダーコードを更新する必要があります。
UnityEditor.IMGUI.Controls 名前空間内の BoxBoundsHandle、CapsuleBoundsHandle、SphereBoundsHandle、ArcHandle、JointAngularLimitHandle などの複雑なハンドルには、コントロールポイントの外観を変更するために割り当て可能なデリゲートがあります。 以前は、これらのデリゲートに null の値を割り当てると、デフォルトの動作に戻りました。しかし、これらに null の値を代入しても動作しなくなり、特定のコントロールハンドルを無効にしやすくなりました。 それぞれ、コントロールハンドルをデフォルトの動作にリセットする必要がある場合は、各クラスにデフォルトメソッドのパブリック API ポイントがあります。
‘unsafe’ C# コードをコンパイルするには、定義済みアセンブリ (Assembly-CSharp.dll など) の Player Settings と Assembly Definition Files アセンブリのインスペクターで、Allow ‘unsafe’ code オプションを有効にする必要があります。 このオプションを有効にすると、スクリプトをコンパイルするときに Unity は C# コンパイラーに unsafe オプションを渡すようになります。
2017.2 と 2017.3 で、Unity Package Manager は UnityPackageManager ディレクトリを使用し、このディレクトリは manifest.json という名前のファイルを格納するために使われていました。パッケージのコンテンツは、Packages から始まる仮想相対パスを使用してスクリプトからアクセスできます。
2018.1 では、パッケージ化されたアセットの仮想相対パスとの一貫性のために UnityPackageManager ディレクトリは Packages に改名されました。manifest.json ファイルは自動的に新しいディレクトリに移動されます。
結果として以下のようになります。
プロジェクトで Perforce や Git などのバージョン管理システム (VCS) を使用している場合は、UnityPackageManager ディレクトリではなく Packages ディレクトリを追跡するように設定を更新する必要があります。
プロジェクトが Packages ディレクトリを使用するように Nuget (または任意の外部パッケージマネージャー) を設定している場合は、別のディレクトリを使用するように設定を変更する必要があります。これは、パッケージが Unity Package Manager によって取得されるという微小な可能性を排除するために推奨されます。Unity Package Manager によって取得されると、コンパイルエラーやインポートエラーのようなデバッグが難しい問題の原因となる可能性があります。
新しいディレクトリに移行した後、UnityPackageManager ディレクトリを安全に削除することができます。
2018.1 の新機能に関するその他の情報と詳しいアップグレードノートは 2018.1 リリースノート を参照してください。