より良い見た目、より速いスピード、そしてより良い柔軟性…私たちがUnityの機能をより良くしようと試みるとき、古い例外処理対応や古いハードのもつ制約への対応が大きな障害になることがあります。基本方針としては、私たちはUnityのバージョンが上がってもすべてが問題なく動作するように努力をしていますが、時には古い制約への対応をやめることで得られるメリットが大きすぎ、またそれによって影響をうける人たちが少ないという状況が発生します。
それではさっそく、グラフィックスについて「将来動作しなくなる」機能のリストを見ていきましょう!ちなみにこれらの内容はあくまでプランであって、主にこれから取り組む変更です。なので、もしあなたがこの中の機能について、本当に、本当に…ほんっとぉーーにずっとその機能が必要がだというならば!ぜひお知らせ下さい!
プリコンパイル済シェーダーというのは要するに「ソースコードのない」シェーダーアセットのことです。可読性のあるHLSLのコードのかわりにコンパイル済のシェーダーアセンブリもしくはマイクロコード、もしくは複数のプラットフォームに向けた変換済シェーダーコードが含まれています。
プリコンパイル済シェーダーの問題は、(もしあなたが何処かでこれを手に入れて使っているならば)これらのシェーダーは将来追加されるプラットフォームでは動かない、ということです。例えば、あるシェーダーがDirectX 9、OpenGLとOpenGL ES 2.0 用にプリコンパイルされているとしましょう。このシェーダーはコンソールプラットフォームでは動きませんし、MetalやDirectX 11でも動作しません。もうこの理由だけで、プリコンパイル済シェーダーを使うというのは良くない方針と言えます。
もう一つのプリコンパイル済シェーダー対応を削除したい理由は、シェーダーのシリアライズフォーマットを改善して、ディスクスペース、ロード時間およびランタイムでのメモリ消費量をいまより大幅に改善したいからです。現在私たちが使っているシェーダーフォーマットは、まぁ正直に言ってあまり効率のよろしくないテキストベースのフォーマットで、シェーダーのロード時間の観点からもメモリ使用量の観点からも優秀とは言いがたいです。私たちがより効率のよい新しいフォーマットを作って実験してみたところでは、シェーダーバリアントの複雑度によっては数メガバイトから数十メガバイトのレベルでメモリ使用量が大幅に、さらにロード時間も削減されました。しかしながら、この変更を入れると古いUnityがサポートしていたプリコンパイル済シェーダーはもう動作しなくなります。しかし、私たちはこのトレードオフは良いものだと考えています。
この変更のメリット:
この変更のデメリット:
影響する人々:シェーダーをプリコンパイルする人々、さらにその人達からプリコンパイル済シェーダーを提供されて使っている人々。
実施予定: 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ではサポートし続けます。
この変更のメリット:
この変更のデメリット:
影響する人々:Windows PC向けにゲームを開発している開発者。
実施予定:Unity 5.4 (2016年3月)
ほとんどすべてのWindowsストアアプリ対応デバイスは少なくともDirectX11 機能レベル9.3に対応しています(Windows Phoneデバイスは全てが対応)。しかしながら、過去に機能レベル 9.1 のデバイスが1つか2つリリースされており、それが私たちの必要対応最低スペックを押し下げています。
この変更のメリット:
この変更のデメリット:
影響する人々:Windows Storeアプリ開発者。
実施予定:Unity 5.4 (2016年3月)
シャドウマップの処理は大きく分けて2つの方法があります。「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 デバイスでマニュアル方式を採用するほうがよいと考えます。
この変更のメリット:
この変更のデメリット:
影響する人々:OpenGL ES 2.0 デバイスをターゲットにしているAndroid アプリ開発者。
実施予定:Unity 5.4 (2016年3月)
Is this article helpful for you?
Thank you for your feedback!