物理ベースのシェーダー関連コードは Unity 5.5 でリファクタリングされました (UnityStandardBRDF.cginc ファイルなど)。手動で直接関数を呼び出さない限り、大抵はシェーダーコードに直接影響することはありません。主な変更は以下の通りです。
smoothness、roughness、perceptual roughness 間を変換する関数が加わりました。
PerceptualRoughnessToRoughness,
RoughnessToPerceptualRoughness, SmoothnessToRoughness,
RoughnessToSmoothness
UnityStandardBRDF.cginc 内の可視性の項は引数として roughness を取り、perceptualRoughness は取りません。
古いバージョンの Unity では、Marmoset ラフネスでリマップを行うことが可能でした。これが GGX への変更により適合しなくなり、UNITY_GLOSS_MATCHES_MARMOSET_TOOLBAG2 の定義とその関連コードは削除されました。
G バッファ内からの読み出しと G バッファ内への書き込みはすべて、新しい関数 UnityStandardDataToGbuffer / UnityStandardDataFromGbuffer を経由するようになります。
Unity_GlossyEnvironmentData 構造体の初期化は、手動で行う代わりにシェーダーコードが UnityGlossyEnvironmentSetup() を呼び出すようになります。
Unity_GlossyEnvironmentData の roughness 変数は実際には perceptual roughness ですが、既存のシェーダーコードとの関連によるエラーを回避するために、名前は変更されていません (注) UnityGlossyEnvironmentSetup はパラメーターとして smoothness を取り、perceptual roughness を計算します。
UnityLight 内の ndotl 変数の値がオンザフライで計算されるようになり、この変数内に書かれた一切の値は無視されます。
UNITY_GI マクロは非推奨となりましたので、今後の使用はお控えください。
Unity 5.5 では、バックグラウンドで DX9 半ピクセルオフセット・ラスタライゼーションの処理が行われます。つまり、シェーダー内でもコード内でも DX9 の半ピクセル問題の修正を行う必要がなくなりました。詳細はこちらのブログ記事でご確認ください。以下のチェックのどれかをコード内で使用すれば問題を解消できるようになっています。
現時点でのこの問題に対する Unity の解決方法は、コンパイルされているすべての頂点シェーダー内に半ピクセル調整コードを挿入することです。結果、頂点シェーダー定数レジスター c255 が Unity により確保され、2 つの命令がすべてのシェーダーに追加され、一時レジスターがもう 1 つ使用されます。これは、使用可能なすべての資源（定数/一時レジスターおよび命令スロット）を頂点シェーダーが完全に使い切ってしまわない限りは問題にはならないはずです。
Z バッファ（デプスバッファ）の方向が反転されました。つまり、Z バッファの値がニアのクリッピング平面で 1.0、ファーのクリッピング平面で 0.0 になります。これが浮動小数点デプスバッファと組み合わさることでデプスバッファの精度が著しく高まり、その結果 Z ファイティングが削減されシャドウの質が向上します。これは特に、小さなニアのクリッピング平面と大きなファーのクリッピング平面を使用する場合に顕著です。
Graphics API に関する変更
次のマクロ/関数によって、追加の手順無しでリバース Z のケースを処理できます。シェーダーですでにこれらを使用している場合は、何の変更も加える必要はありません。
ただし、Z バッファの値を手動でフェッチしている場合は、以下のようなコードの記述が必要になります、
float z = tex2D(_CameraDepthTexture, uv);
#if defined(UNITY_REVERSED_Z)
z = 1.0f - z;
#endif
クリップスペースのデプスには次のマクロを使用できます。（注） このマクロは OpenGL／ES プラットフォームでクリップスペースに変更を加えることはなく、[-near, far] として残ります。
float clipSpaceRange01 = UNITY_Z_0_FAR_FROM_CLIPSPACE(rawClipSpace);
_ZBufferParams がリバースのデプスバッファがあるプラットフォームで 3 つの値を含むようになりました。詳細はドキュメントのプラットフォーム特有のレンダリングの違いに関するページをご覧ください。
x = -1+far/near
y = 1
z = x/far
w = 1/far
Z バイアスは Unity によって自動で処理されますが、ネイティブコードのレンダリングプラグインをご使用の場合は、対応プラットフォームの C/C++ コード内でそれを無効化する必要があります。
“Editor” という名前のフォルダーのサブフォルダーはすべてビルドから除外され、Unity エディターの再生モードで読み込まれなくなります。以前は “Resources” という名前のサブフォルダーのアセットがビルドに含まれていました。これらのアセットは今後も、エディタースクリプト内で Resources.Load() を呼び出すことで読み込むことができます。
例えば、下記のファイルはビルドから除外され、エディターの再生モードでは__読み込まれません__が、スクリプトから呼び出せば__読み込まれます__。
下記のアセットは、すべての状況において読み込まれます。
これまでは、ライトマップパラメーター 内の ‘Backface Tolerance’ パラメーターはベイク済 GI にファイナルギャザーを使用している場合には適用されませんでしたが、これが正しく適用されるようになりました。このパラメーターは、リアルタイム GI およびベイク済 GI の両方の段階（ファイナルギャザーを含む）に影響を与えるようになりました。
これによって主に影響を受けるシーンは、片面のジオメトリ（ビルボードなど）があって、そのようなジオメトリの裏面にあるテクセルが無効化されてしまうのを避けるために ‘Backface Tolerance’ の調整が必要になるようなシーンです。ビルボードとファイナルギャザーを使用しているシーンでは ‘Backface Tolerance’ を調整することでライトマップの質をより高められるようになりました。ただし、デフォルトでない ‘Backface Tolerance’ が適用されている場合は、現在これはファイナルギャザーの段階に正しく割り当てられているため、他のシーンにも影響を及ぼす可能性があります。
BRDF2 はモバイルプラットフォームでのデフォルトに設定されている標準のシェーダータイプです。このタイプのシェーダーが Blinn-Phong ではなく GGX 近似を使用するように変更されました。これにより、見た目が BRDF1（デスクトップ用のデフォルト）により近くなり、ビジュアルの品質が向上されます。
レガシーの近似計算を保持する必要がある場合は、#if UNITY_BRDF_GGX 命令文内に新しい実装を持つ UnityStandardBRDF.cginc 内で、BRDF2 コードを修正してください。（これは BRDF1 も GGX の選択のために使用しています）。BRDF2_Unity_PBS 関数内で、UnityStandardConfig.cginc 内の定義を変更するか、#if UNITY_BRDF_GGX を #if 0 に変更してください。
Android 向けビルドに Gradle が使用可能になりました。
Gradle は既存の Unity Android ビルドシステムと比較して、エラーの検知基準が緩くなっています。このため、一部の既存のプロジェクトでは Gradle への変換が難しい場合があります。このようなビルド障害の特定と解決方法については、Gradle のトラブルシューティングをご覧ください。
Instantiate 関数の特定のオーバーロード（デフォルトで元々のゲームオブジェクトのパラメーター 1 つと親 Transform のパラメータ―を 1 つ取るもの）の挙動が変更されました。元々のゲームオブジェクトの位置・角度をワールド空間での位置・角度として認識しなくなったため、指定された親 Transform の位置・角度を無視します。
現在はデフォルトで、位置・角度を、指定の親 Transform 内のスペース内におけるローカルの位置・角度として認識するようになっています。これはエディター内の挙動と一致しています。スクリプトは自動では更新されません。したがって、この Instantiate のオーバーロードへの呼び出しを含む、今回の変更に対応した更新の行われていないスクリプトを実行すると、予期せぬ挙動が発生する可能性があります。
LOD Group コンポーネントを無効化しても、それにアタッチされたレンダラーは無効化されなくなりました。LOD Group の設定がレンダラーに適用されるのは、LOD Group コンポーネントが有効になっている場合のみです。この変更は、プロジェクトのアップグレード時に Unity によって自動的に適用され、一度変更すると元に戻すことができません。