ここでは、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 ディレクトリを追跡するように設定を更新する必要があります。
プロジェクトで Nuget (または任意の外部パッケージマネージャー) を使い、それを通して Packages ディレクトリを使用している場合は、別のディレクトリを使用するように設定を変更する必要があります。これは、パッケージが Unity Package Manager によって取得されてしまうわずかな可能性を排除するために有効です。Unity Package Manager によって取得されると、コンパイルエラーやインポートエラーのようなデバッグが難しい問題の原因となる可能性があります。
新しいディレクトリに移行した後、UnityPackageManager ディレクトリを安全に削除することができます。
2018.1 の新機能に関するその他の情報と詳しいアップグレードノートは 2018.1 リリースノート を参照してください。