(大小に関わらず) 0–1 空間を埋めない UV の焼き付けについて、UV のパッキング処理を修正。他のオブジェクトと重なるような UV を持ったオブジェクトが発生させていた数々の問題を解消しました。オブジェクトの UV アンラップが0–1空間を埋めず、かつサイズが2のべき乗でもないものについての解像度の割り当てが改善されました。焼き込まれたライトマップの解像度を確認してください。
Shader variant stripping was fixed for realtime lightmaps. Now each lightmaps mode (non-directional, directional and directional specular) variant can be picked for baked and Enlighten realtime GI separately. Please review your settings if you previously selected a specific lightmaps mode variant in the Graphics window to make that mode work for realtime lightmaps.
Bounce スケールが 0.7 の任意の値から 1.0 へと変更されています。バウンスは、アルベドとバウンス スケールの結果となります。アーティストは実際のアルベド値(最も明るい非金属は 0.9 で雪になります)を設定する必要があります。PBS についての詳細は http://forum.unity3d.com/threads/official–5–0-pbr-calibration-charts.289416/ を参照してください。
物理的に正しいアルベドを作成しなければいけないので、スケール値を 1 に近づけることは理にかなっています。meta pass ですでにアルベド値は制限されており、バウンス スケールはちょうど 1.0f にしなければいけません。
クランプ機能無しでカスタム meta pass でアルベドを 1.0 に設定することを選択した場合は、シーンがライトで爆発しているようなものにみえることに注意してください。
「固定関数(Fixed Function)」スタイルのシェーダー―(SetTexture, Lighting On などを使用するもの)は、現在、シェーダーのインポート時に実際のシェーダーへと内部的に変えられます。メリットは、より一貫性を持ちながらすべてのプラットフォーム上で動作するということです(以前は console上で動作)。また、レンダリングが少しでも早くなるように、ランタイムから多くのコードと固定関数に関する非能率な部分を削除しました。一方、デメリットは、ランタイム時に new Material(fixedFunctionShaderString)
を使用しての固定関数の作成は、もう動作しないことです。 つまり、コンストラクターは Unity 5.1 で非推奨でしたが、Unity 5.2 では固定関数シェーダー用の動作を実際に停止しました。
将来的に “Screen Space Refrection” を可能にするために Deferred Shading を使用するときに、リフレクションプローブがレンダリングされる方法へと変更されました。要するに、Deferred Shading ではリフレクションプローブは、オブジェクトごとではなくピクセルごとになったということです。
以下の画像は、現在の動作と比較(オブジェクトごとのリフレクションプローブ。これでは大きなオブジェクト間での反射の遷移が過酷で回避は厳しい)と、ピクセルごとのリフレクションプローブ(遷移が見えにくくなっており、オブジェクトの境界ではなく、プローブの境界で遷移が発生しています)
以前(5.0 と 5.1)
リフレクションプローブは、Forward Rendering と同じ方法で、G-buffer パス間でサンプリングを行います。ライトプローブ と ライトマップ と エミッシブマテリアルの部分と共に “emission” バッファに書き込まれます。
これは、オブジェクトごとに 1つ(プローブのブレンディングが有効であれば2つ)のリフレクションプローブの取得を意味しています。
同じバッファに エミッション/ライトマップがある状態のリフレクションは、「正確に」SSRR をすることが難しいことを意味します。SSRR は、それ自体がリフレクションを提供(そうすることができないシーンでリフレクションプローブを参照する)しますが、「エミッションバッファ」カラーのどの部分がリフレクションプローブから生成されたのかが分かりません。
現在(5.2)
deferred shading を利用する場合、G-buffer パスの間リフレクションプローブのサンプリングは行いません。
その代わり G-buffer が行われた後に、スクリーン空間にボックスの形状をした、リフレクション情報を別々にレンダーターゲットへと出力するリフレクションプローブを描画する、別の “deferred reflection” パスを作成します。
[今後: SSRR エフェクトは、独立したリフレクションバッファを利用します]
終了時リフレクションバッファとエミッションバッファを結合します。
これは何を意味しているのかというと、以下に示す項目のみ deferred shading に影響します。
リフレクションプローブの Renderer のフラグ(プローブ間のブレンディング、他)は無視されます。(現在は、スクリーンスペース上で発生するので)すべてが同じようにリフレクションプローブに影響を受けます。これは、deferred shading で “receive shadow” フラグがどのように無視されるのかと非常に類似しています。
パーティクルは現在ワールド座標で生成されます。それはどんなカスタム バーテックス シェーダーに対してもアップデートが求められることもあります。これは VR 向けの各眼球の間のパーティクルバッファの再利用ができるようにするために変更されました。
メッシュパーティクルは、現在 Texture Sheet Animation モジュールをサポートしています。すでに作成されているエフェクトでこのモジュールが有効になっていないかチェックしてください。チェックが付いている場合はユーザーにとって想定外の動作をする可能性があります。
以前は、Limit Velocity Over Lifetime モジュールの Dampen パラメーターは、より高いフレームレートに対し、より強い効果を発していました。これが修正されたので、ゲームで 30FPS をターゲットにしている場合、旧効果はフレームレートの違いに左右されません。ただし、異なる FPS をターゲットにしている場合、以下の式を使用して Dampen 値を更新し、5.2 で効果が変わらないように気を付けてください。
newDampen = 1.0f - pow(1.0f - oldDampen, targetFPS / 30.0f);
Material.CopyPropertiesFromMaterial
は、シェーダー キーワード と レンダーキューもコピーします。これらのコピーを行いたくないときは、コードを変更しなければいけません。
SpeedTree ビルトイン シェーダーが変更されたので、SpeedTree マテリアルは再生成しなくてはならなくなりました。これを行うには、プロジェクトの SpeedTree プレハブを選択し、Apply & Generate Materials ボタンを押します。これを行うことによって、マテリアル アセットの生成のカスタマイズが (存在する場合は) 上書きされることに注意してください。
5.2 では、テキストと通常の UI 要素をレンダリングするユーザーのシェーダーを組み合わせました。この副作用は 32 ビットフォーマットのマニュアルフォントテクスチャを指定した場合、カラーチャンネルが尊重されるようになります。つまり、黒のテクスチャチャンネルは、結果的に以前テキストが白(alpha 値を見たときだけ)になるところのテキストが黒のテキストになることを意味します。ゲームのフォントでシステムテクスチャを使うことを希望する場合、以下を実行してください。
Unity 5.2 でプロジェクト ID の取り扱われ方が変更されました。現在、プロジェクトは自動的に登録され、手動で ID を入力する必要はなくなりました。サービスウィンドウにマルチプレイヤーパネルがあります(ウィンドウの右上の角のクラウドのアイコンで開きます)。そこでは、ウェブサイト(ダッシュボードに行く)上のプロジェクトに直接遷移するリンクを見つけることができます。マルチプレイヤーが構成されるとき、Multiplayer configuration(マルチプレイヤー環境の構築)がここに表示されます。