This page lists changes in Unity 2018 LTS which might affect existing projects when you upgrade from a Unity 2017 version.
Note that 2018 LTS is also known as 2018.4.
flex-grow、flex-shrink、flex-basis を示す最多で 3 つのパラメーターを受け入れるようになりました。flex-shrink と flex-basis パラメーターは必須ではありません。これらを指定しない場合は、flex-basis のデフォルトは 0 になり、flex-shrink のデフォルトは 1 になります。flex: N は flex N 0 auto と同等でした。これは現在 flex：N 1 0 と同等にすることで CSS 標準に準ずるにようになりました。古いセマンティックを維持するには、USS ファイル内のすべての flex: N ディレクティブを flex: N 0 auto に置き換える必要があります。物理的な動作が変更されたため、新しいバージョンでは一部のプロジェクトで動作が異なる場合があります。特に以下の点に注意してください。
プロジェクトを 2018.2 以前のバージョンから 2018.3b に移行し、それに Unity の GitHub リポジトリから取得した NavMesh コンポーネントを使用する場合は、この ブランチ を使用する必要があります。
Unity 2018.3 にはパーティクルのバグ修正がいくつか含まれており、これは以前のバージョンで作成されたプロジェクトに影響を与える可能性があります。
2018.3 より前では、Unity エディターはプロジェクト内の C# ファイルをコンパイルするときに Mono C# コンパイラー (mcs) を使用していました。2018.3 以降、Roslyn C# コンパイラー (csc) が、新しいスクリプトランタイム (.NET 4.x Equivalent) を対象としたプロジェクトに使用されています。 Roslyn へ切り替えると、動作が異なる場合があります。
csc.rsp という名前にしてください。詳細は プラットフォーム依存コンパイル を参照してください。UnityScript (.js) と Boo (.boo) スクリプトファイルは、エディタでーコンパイルできなくなりました。
詳細は、2017 年 8 月の ブログ を参照してください。Unityscript2csharp ツールを使用して UnityScript を C# に変換できます。
Animator のルートモーションの再生方法が少し変更され、Animation ウィンドウでルートモーションアニメーションを作成する際の不具合を修正しました。
ルートモーションカーブをアニメーションクリップ用に生成する必要がなくなりました。 ルートモーションのアプリケーションは、Animator.applyRootMotion のみに依存するようになりました。
| ケース | ルートモーション生成 | Animator.applyRootMotion | 2018.2 | 2018.3 & 2018.4 (LTS) |
|---|---|---|---|---|
| A | はい | はい | ルートの Transform に累積的にルートモーションを適用します。 | 2018.2 と同様 |
| B | いいえ | いいえ | アニメーションクリップで編集したように、位置、回転、スケールのカーブを適用します。 | 2018.2 と同様 |
| C* | はい | いいえ | ルート Transform の移動はありません。 | アニメーションクリップで編集したように、位置、回転、スケールのカーブを適用します。 |
| D* | いいえ | はい | ルート Transform の移動はありません。 | ルートの Transform に累積的にルートモーションを適用します。 |
ケース C と D の場合、2018.3 で同じ結果を得るには、OnAnimatorMove を実装します。次に、ルートモーションを適用しない場合は Animator.deltaPosition と Animator.deltaRotation を破棄してください。
プロジェクトで applyRootMotion を使用してルート Transform の位置、回転、スケールアニメーションをミュートにする場合は、ルートの Transform プロパティを手動でオーバーライドする必要があります。
UIElements.ContextualMenu メニューアクションコールバックは、 EventBase パラメーターの代わりに ContextualMenu.MenuAction パラメーターを取るようになりました。
ContextualMenu.InsertSeparator は追加の string パラメーターを取るようになりました。
この機能は Unity 5.1 で非推奨となり、排除されました。Unity 2018.2 のプロジェクトでは使用することはできません。
Unity のネットワークに関する詳しい情報は マルチプレイヤーゲームとネットワーク を参照してください。
Photoshop は、透明度がある場合にはピクセル色を微調整し、それらをマットカラー (背景) とブレンドします。アルファチャンネルを適切に準備するプロセスは、アルファテクスチャのインポートの仕方 を参照してください。
前述のページにある、カラーレイヤーの拡張は無視することができます。重要なのは、別のアルファチャンネル/マスクを持つ “不透明” な (透明ではなく) 画像を作成する必要があるという説明です。Unity は色を微調整してマットを取り除いていましたが、この方法は 2018.2 で終了しました。透明度を持つ PSD があると、エッジが白く見える場合があります。これを修正するには、上のリンクのページを参考に (透明度の代わりに) 実際のアルファチャンネルを作成してください。
以前のバージョンでは、ゲームオブジェクトが無効にされたり破棄されたりすると、その子の 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 は Preferences の “MonoDevelop” (ビルトイン) 外部スクリプトエディターと認識しません。C# スクリプトエディターがインストールされておらず、Preferences で選択されていない場合、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 の値を代入すると動作しなくなり、特定のコントロールハンドルを無効にしやすくなりました。コントロールハンドルをデフォルトの動作にリセットする必要がある場合は、各クラスにデフォルトメソッドのための public の 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 ディレクトリを安全に削除することができます。