一部グラフィックス機能の非推奨化(Deprecation)と削除について

より良い見た目、より速いスピード、そしてより良い柔軟性…私たちがUnityの機能をより良くしようと試みるとき、古い例外処理対応や古いハードのもつ制約への対応が大きな障害になることがあります。基本方針としては、私たちはUnityのバージョンが上がってもすべてが問題なく動作するように努力をしていますが、時には古い制約への対応をやめることで得られるメリットが大きすぎ、またそれによって影響をうける人たちが少ないという状況が発生します。

それではさっそく、グラフィックスについて「将来動作しなくなる」機能のリストを見ていきましょう！ちなみにこれらの内容はあくまでプランであって、主にこれから取り組む変更です。なので、もしあなたがこの中の機能について、本当に、本当に…ほんっとぉーーにずっとその機能が必要がだというならば！ぜひお知らせ下さい！

プリコンパイル済シェーダーというのは要するに「ソースコードのない」シェーダーアセットのことです。可読性のあるHLSLのコードのかわりにコンパイル済のシェーダーアセンブリもしくはマイクロコード、もしくは複数のプラットフォームに向けた変換済シェーダーコードが含まれています。

プリコンパイル済シェーダーの問題は、（もしあなたが何処かでこれを手に入れて使っているならば）これらのシェーダーは将来追加されるプラットフォームでは動かない、ということです。例えば、あるシェーダーがDirectX 9、OpenGLとOpenGL ES 2.0 用にプリコンパイルされているとしましょう。このシェーダーはコンソールプラットフォームでは動きませんし、MetalやDirectX 11でも動作しません。もうこの理由だけで、プリコンパイル済シェーダーを使うというのは良くない方針と言えます。

もう一つのプリコンパイル済シェーダー対応を削除したい理由は、シェーダーのシリアライズフォーマットを改善して、ディスクスペース、ロード時間およびランタイムでのメモリ消費量をいまより大幅に改善したいからです。現在私たちが使っているシェーダーフォーマットは、まぁ正直に言ってあまり効率のよろしくないテキストベースのフォーマットで、シェーダーのロード時間の観点からもメモリ使用量の観点からも優秀とは言いがたいです。私たちがより効率のよい新しいフォーマットを作って実験してみたところでは、シェーダーバリアントの複雑度によっては数メガバイトから数十メガバイトのレベルでメモリ使用量が大幅に、さらにロード時間も削減されました。しかしながら、この変更を入れると古いUnityがサポートしていたプリコンパイル済シェーダーはもう動作しなくなります。しかし、私たちはこのトレードオフは良いものだと考えています。

この変更のメリット：

• ゲームデータの中で使われるシェーダーのディスクサイズは大幅に小さくなります。（数％ではなく、数分の１になります）
• シェーダーのロード時間が全然速くなり、シェーダーの非同期ロードがメインスレッドに与える影響が大幅に小さくなります（つまり、シェーダーのロード理由でのフレーム落ちなどの問題が改善します）
• ゲームの実行中にシェーダーが締めるメモリが大幅に小さくなります。
• DX11環境では シェーダーインスペクターで “Show compiled code” を行った時に、意味不明な文字の海の代わりにちゃんとしたシェーダーディスアセンブリを表示できるようになります。

この変更のデメリット：

• シェダーのプリコンパイル（インスペクターで“show compiled code”を押すと出てくるやつです）が出来なくなります。また、それを使っていたシェーダーは動作しなくなります。

影響する人々：シェーダーをプリコンパイルする人々、さらにその人達からプリコンパイル済シェーダーを提供されて使っている人々。

実施予定: Unity 5.3から (2015年12月)

DX9 シェーダーモデル2.0 GPUは正直かなり古いので、そろそろサポートをやめようと思います！まぁ、ちょっと落ち着いて…これはどう言う意味かというと、次のモデルのようなGPUが非対応になるということです：2004年以前のNVIDIAのグラフィックスボード（GeForce 6000シリーズ以前）、2005年以前のAMDのグラフィックスボード (Radeon X1000シリーズ以前)、そして2006年以前のIntelのGPU （GMA X3000/965 以前）が対象となります。要するに10年前のGPUで動作しているコンピュータでは動かなくなるということです。我々が集めているデータによると、Intel GMA 950 (82945) GPU がたまに見つかるだけで、残りは絶滅しているようです。なので、Intel GMA 950 を使っている人たちの環境では動かなくなります。

この対応は、Unityが Direct X 9 の対応をやめるという話ではありませんよ！DX9はまだまだWindows XPのような環境では唯一の現実的なオプションですし、この環境を使っている人はまだまだ居ます。（シェーダーモデル 3.0 以降対応のGPUによる）Direct X 9 レンダリングサポートは、まだまだUnityではサポートし続けます。

この変更のメリット：

• シェーダーを書く人々の心が安まります。現在Unityでシェーダーを作成すると、Unityはデフォルトでは「最大公約数として利用可能な技術」を使ってコンパイルします（つまり今は Shader Model 2.0 です）。これを変更するにはイチイチ「#pragma target 3.0」とか書く必要がありますし、Shader Model 2.0のサポートを辞めることができれば、必要最小スペックを押し上げることができ、シェーダーを書くときの対応や心配事が減ります。
• Unityの中の我々の心が超安まります！！おそらく知りたくもないでしょう…例えば私たちがUnity 5の物理ベースシェーダーの開発において、Shader Model 2.0フォールバック対応に一体どれほどの時間と技術を詰め込んだのか… こいつさえいなければ私たちは本当に役に立つことに時間を使えるんですよ！！

この変更のデメリット：

• Unityで開発されたゲームが Intel GMA 950 / 82945 GPU で動作しなくなります。

影響する人々：Windows PC向けにゲームを開発している開発者。

実施予定：Unity 5.4 (2016年3月)

ほとんどすべてのWindowsストアアプリ対応デバイスは少なくともDirectX11 機能レベル9.3に対応しています（Windows Phoneデバイスは全てが対応）。しかしながら、過去に機能レベル 9.1 のデバイスが１つか２つリリースされており、それが私たちの必要対応最低スペックを押し下げています。

この変更のメリット：

• すべてのWSA/WP8 シェーダーは機能レベル9.1の代わりに9.3でコンパイルされます。これにより複数レンダーターゲット(multiple render target)、ピクセルシェーダーの差分命令（derivative instructions, ddx()やddy()など）のような、以前は動作しなかったいくつかの機能が使えるようになります。
• 9.1対応のために必要だったプログラムを大幅にUnityから削除出来ます。

この変更のデメリット：

• あなたが開発したWindows Storeアプリは9.1対応デバイスでは動作しなくなります。これはまぁ別の言い方をすると「Surface RT タブレットで動作しなくなります」と大体同じ意味です。すべてのWindows Phoneは9.3対応以上なので、Windows Phoneへの影響はありません。

影響する人々：Windows Storeアプリ開発者。

実施予定：Unity 5.4 (2016年3月)

シャドウマップの処理は大きく分けて２つの方法があります。「GPUの機能で対応する（ネイティブ方式）」と「自分で処理する（マニュアル方式）」です。GPUの機能で対応する方式では、シャドウマップのサンプリングを行うと直接「影の値」が返ってきます。その際にハードウェアによるPCFフィルタリングが利用できることがあります。自分で行う場合は、主にシャドウマップのデプスをサンプリングして、サーフェイスのデプスと比較して対象が影の外か中かをチェックします。

この2つの方式では多くのGPUが「コストなしで使える」2x2のPCFフィルタリングを提供しているので、大体の環境においては最初のやりかたが望ましいのですが、AndroidのOpen GL ES 2.0はちょっと違う状況ににありまして、いくつかのデバイスは EXT_shadow_samplers 拡張による「ネイティブシャドウマップ」方式に対応しているものの、対応していないデバイスも結構あるのです。これがどういう事を意味するかというと、Android ES 2.0 向けのシェーダーはこの2つのケースを両方対応するために、両方のバリエーションをコンパイルしてゲームに含めるようにしている、ということです。

しかしながら、実際にまた現実のデータを見てみますとEXT_shadow_samplers 拡張をサポートしているAndroidというのは極めてレアで、すべてのデバイスのうち精々1~2 % しかないことが分かりました。これなら、私たちはこの対応をいっそ削除してしまってすべてのAndroid ES 2.0 デバイスでマニュアル方式を採用するほうがよいと考えます。

この変更のメリット：

• Android ES 2.0対応デバイスに向けたシェーダーではシェーダーバリアントが減り、コンパイル、ディスク、ランタイムでのロードが改善します。

この変更のデメリット：

• おおむね1% のAndroid ES 2.0 デバイスでハードウェアによる影処理とPCFサンプリングが出来なくなり、かわりにそれよりほんのちょっとだけ遅いデプス比較のためのシェーダーコードで対応されるようになります。ちなみに全てのこれら1%に該当するデバイスはビルトインPCFが利用可能なOpenGL ES 3.0に対応しているので、そちらの対応を含める方が得策です！

影響する人々：OpenGL ES 2.0 デバイスをターゲットにしているAndroid アプリ開発者。

実施予定：Unity 5.4 (2016年3月)