プロジェクトを Unity 5.3 から Unity 5.4 へとアップグレードする場合、プロジェクトに影響する可能性がある変更がいくつかあります。
WebRequest インターフェースが UnityEngine.Experimental.Networking から UnityEngine.Networking になりました。UnityWebRequest を使用している Unity 5.2 と 5.3 のプロジェクトは更新する必要があります。
ImageEffectTransformsToLDR 属性をもつイメージエフェクトは、シーンビューに自動的に適用されなくなりました。シーンビューにエフェクトを適用するための新しい属性は ImageEffectAllowedInSceneView です。5.4 の Standard Assets は更新され、この変更が反映されています。
一貫性を保つため、多数のビルトインシェーダー変数が名称変更されました。
インポートするときに、参照変数は .shader と .cginc ファイルで自動的に名称変更されます。ただし、インポート後は、手動で変数の名称変更を行わない限り、そのシェーダーを Unity 5.3 以前のバージョンで使用することはできません。
Unity 5.4 では、シェーダープロパティーの配列の処理方法が変更され、シェーダーのfloat、vector、matrix の配列 ( MaterialPropertyBlock.SetFloatArray , Shader.SetGlobalFloatArray 他経由) に、ネイティブのサポートが設定されています。これらの新しい API では、配列に最大 1,023 の要素が可能です。
個々の配列要素を参照するための数字付きの名称を使用する旧方式 ( _Colors0 、_Colors1 など) は Material と MaterialPropertyBlock では非推奨です。Material でシリアライズされたプロパティーには、もう配列要素を設定することはできません (ただし、uniform 配列の名称が数字付きである場合は可能です)。
デフォルトのシェーダーコンパイルターゲットは、“#pragma target 2.5” (DX9 の SM3.0、WinPhone の DX11 9.3 性能レベル) です。DX9 SM2.0 と DX11 9.1性能レベルもまだ、“#pragma target 2.0” でターゲットに設定することができます。
現在、ビルトインシェーダーの大半は2.5 をターゲットにしています。目立った例外は、Unlit、VertexLit、固定関数シェーダーです。つまり、大半のビルトインシェーダーと新しく作成されたシェーダーは、デフォルトでは、2004 年より前に作られた PC GPU で作動しないということを意味します。詳しくはこちらのブログを参照してください。
すでに非推奨となっている Material クラスのコンストラクター Material(文字列) は、5.4 で動作しなくなりました。使用するとエラーメッセージが表示され、結果的にマジェンタの誤ったシェーダーになります。
The internal shader used to compute screen-space directional light shadows has moved to the Graphics settings. If you were using a customized version of directional light shadows by having a copy of that shader in your project, it will no longer be used. Instead, select your custom shader under Edit > Project Settings, then select the Graphics category.
リフレクションプローブは 2 つのテクスチャ間のサンプラーを共有します。シェーダーで手動でテクスチャをサンプリングし、“undeclared identifier samplerunity_SpecCube1” のエラーが発生した場合は、コードをUNITY_PASS_TEXCUBE(unity_SpecCube1) から UNITY_PASS_TEXCUBE_SAMPLER(unity_SpecCube1,unity_SpecCube0) へ変更します。
UnityEditor.ShaderUtil.ShaderPropertyTexDim は非推奨なので、 Texture.dimension を使用してください。
自動変換される OpenGL シェーダーの ComputeBuffer のデータレイアウトは、DirectX ComputeBuffers のレイアウトに一致するように変更されました。OpenGL で ComputeBuffer を使用する場合は、以前の OpenGL に特化したレイアウトルールに合わせ微調節するためのコードを削除してください。詳しくは 、コンピュートシェーダーを参照してください。
Playable はクラスではなく構造体です。
Playable 構造体は、ネイティブの Playable クラスへのポインターではなくハンドルです。
Playable 構造体が null でないからといって必ずしも Playable が使用可能なわけではありません。.IsValid メソッドを使用してその Playable が使用可能かを確認してください。
空の input や output に対し null を返していたメソッドはすべて、Playable.Null を返すようになりました。
Playable.Null は無効な Playable です。
Playable.Null は空の input を確保するため、または、接続していた input を暗示的に非接続にするために AddInput 、SetInput 、 SetInputs に渡されることがあります。
メソッドの input として Playable.Null や無効な Playable を使用したり、無効な Playable でメソッドを呼び出すと、その作業に適切な例外が発生します。
Playable を null と比較することは無意味です。 Playable.Null と比較してください。
Playable は使用したいクラスの static メソッドの Create を使ってアロケーションしてください。
Playables は Playable ハンドルの .Destroy メソッドを使ってアロケーションを解除してください。
アロケーションを解除しない Playable はメモリーリークとなります。
Playable は、ボクシングやボクシング解除 (ボクシングに関する詳細情報はこちら) を避けてパフォーマンスを向上させるために、構造体に変換されました。
Playable をオブジェクトにキャストすることは、暗示的、または、明示的にボクシングやボクシング解除の起因となり、パフォーマンスを低下させます。
Playable クラスからの継承は、子クラスのインスタンスのボクシングやボクシング解除の原因となります。
現在、アニメーションのみが使用可能なため、 ScriptPlayable は CustomAnimationPlayable に取り換えられました。
元の Playable から派生させることはできなくなりました。カスタム作成した Playable に単純に Playable をアグリゲートしてください。
Oculus VR プロジェクトを Unity 5.3 からアップグレードするには、以下の手順で行ってください。
バーチャルリアリティサポートを再度、有効にします。
Oculus Spatializer を削除します。
Unity 5.4 では、兄弟のゲームオブジェクトが並べ替えされるときにトリガーするイベントに変更があります。兄弟 ゲームオブジェクトとはヒエラルキーウィンドウで同じ親を持つゲームオブジェクトのことです。以前のバージョンの Unity では、兄弟のゲームオブジェクトの順序が変わると、すべての兄弟が OnTransformParentChanged の呼び出しを受けました。 5.4 では、兄弟のゲームオブジェクトはこの呼び出しを受けることはなくなりました。代わりに、親のゲームオブジェクトが OnTransformChildrenChanged の呼び出しを受けます。
つまり、プロジェクト内に、兄弟が並べ替えられたときに OnTransformParentChanged の呼び出しに依存しているコードがあっても、この呼び出しはもう発生しません。そのため、代わりに親オブジェクトが__OnTransformChildrenChanged__ の呼び出しを受け取るようにコードをアップデートする必要があります。
新しい挙動を使用するとパフォーマンスが向上するため、このように変更されました。
Transform コンポーネントの最適化のためにTransform.SetParent を使用したり、1000 以上ものゲームオブジェクトを含む階層に Destroy を実行するのに、以前よりも長い時間がかかるようになりました。ランタイムに SetParent を呼び出したり、または、そのように大きな階層をランタイムに再編成するのは推奨されません。
生成された Visual Studio プロジェクトフォーマットが .NET スクリプティングバックエンド SDK すべてのためにアップデートされました。これにより、生成されたオブジェクトで何も変更がないときに発生する不必要な再ビルドが修正されました。既存の生成された *.csproj (特にそれが “Generate C# projects” オプション付きでビルドされた場合) を削除しなくてはならない場合があります。そうすることによって、それを再生成できます。
デシリアライズ (読み込み) 中に Unity API がコンストラクターとフィールドイニシアライザーからから呼び出される場合に、キャッチすべき 2 つの新しいスクリプトシリアライゼ―ションエラーが追加されました。デシリアライズはさまざまなスレッドからメインスレッドへと発生する可能性があります。そのため、デシリアライズ中にUnity API に呼び出しすることは安全ではありません。詳細は、Unity マニュアルのスクリプトシリアライゼーション ページを参照してください。
エディターは Mac OS X の高解像度テキスト、UI、3D ビューで Retina ディスプレイをサポートするようになりました。
エディターの GUI はピクセル空間というよりは、ポイント空間で決定されます。標準解像度のディスプレイでは、各ポイント (pt) が 1 ピクセル (px) のため変化はありません。しかし、Retina ディスプレイでは、各ポイントは 2 ピクセルです。現在の画面対 UI の比率は EditorGUIUtility.pixelsPerPoint で求めることができます。Unity では複数のウィンドウが可能なため、モニター上のそれぞれが異なるピクセル密度を持つことが可能で、この値がビューによって変化することがあります。
エディターコードで標準の Editor、GUI、Layout メソッドのいずれかを使用している場合は、たいてい何も変更する必用はありません。
Screen.width や Screen.height を使用している場合は、代わりにEditorWindow.position.width や EditorWindow.position.height に変更します。なぜなら、画面サイズがピクセルで測られているのに、UI はポイントで定義されているからです。インスペクターに表示するカスタムエディターには、スクロールバーを適切に表示できるように EditorGUIUtility.currentViewWidth を使用します。
UI に RenderTexture など他のコンテンツを表示したい場合、おそらくそのサイズはポイントで計算されています。Retina ディスプレイでは、ポイントサイズをピクセルサイズに変換しなくてはなりません。これを行うための新しいメソッドが EditorGUIUtility に含まれています。
カスタムの背景で GUIStyles を使用する場合、正確に寸法を 2倍にしたテクスチャを ‘GUIStyleState.scaledBackgrounds’ 配列に入力することによって Retina バージョンの背景テクスチャを加えることができます。
動力不測のグラフィックスハードウェアが設定された Mac では、増加した解像度のために 3D ビューでエディターのフレームレートが非常に遅くなることがあります。Finder でUnity.app の “Get Info” を選び、“Open in Low Resolution” をチェックすることによって Retina サポートを無効にすることができます。
以下の変更が行われました。
物理演算メッシュに無効な (non-finite) 頂点が含まれる場合、物理演算メッシュを却下するよう変更
重複する Transform の update を送信しないことによって物理演算transform ドリフトを避けるよう変更
5.3 のビヘイビアとしては、アニメーションシステムが、constant であるアニメーションカーブのために Transform のアップデートメッセージを常に送信していました。これらのメッセージはRigidbody のスリープ状態を解除し、この問題を修正することは 5.3 では危険を伴うものでした。
5.4 のビヘイビアとしては、位置の変化がない場合は、Rigidbody は (大方の予測通り) スリープしたままです。
プロジェクトが常に Rigidbody のスリープ状態を解除する 5.3 のビヘイビアに依存している場合は、5.4 では期待するように動作しないことがあります。
Unity 5.4 から Web Player はターゲットから除かれました。プロジェクトを Unity 5.4 にアップグレードすると、Web Player プラットフォームにはデプロイできなくなります。
旧 Web Player プロジェクトを維持する必要がある場合は、5.4 以降にアップグレードしないようにしてください。