Unityのレンダーパイプラインについて調べてみたことについて調べていきます。
レンダリングパイプライン（HDRP、URP)
Unityで利用できるレンダリングパイプラインは、現時点で3つあります。
・コアエンジンに含まれるビルトインパイプライン
・HDRP
・URP
レンダリングパイプラインとはメッシュ、シェーダーなど情報から、ゲーム画面に描画するプログラム集団の事
レンダリングパイプラインとは、3D CGの処理において頂点やジオメトリ、ラスタライズやピクセルといった各処理の繋がりと流れについて定義したものです。これらの処理にはGPUハードウェアのシェーダー、ミドルのライブラリなどが関連し、ユーザプログラムでカスタマイズできる仕組みもあります。詳細についてはDirectXかOpenGLのドキュメントを読むとわかりやすいです。
DirectXのグラフィックスレンダリングパイプラインのドキュメント
Shader graphが使える
これはSRP(HDRP、URP)でしか使えません。
ShaderGraphのパッケージにある説明文では「今は」と書かれているので、将来に期待が持てます。
Currently, both the High Definition Rendering Pipeline and the Universal Rendering Pipeline support Shader Graph.
ノードを使って誰でも簡単にシェーダーが描ける
ShaderGraphを使ったからといって、必ずしも簡単にシェーダーが描けるとは限りません。コードで書くやり方がわかっていないと、ノードベースでどのようにロジックを組み立てればいいのかを理解するのは難易度が上がります。
シェーダーを描くには数学、プログラミング、3D CGといった広範なCSの知識が求められます。たいていの物事には、銀の弾丸は存在しません。
HDRPは、グラフィックがとても綺麗で、コンピューターゲーム向け。
HDRPはハイエンドなグラフィックを実現するために用意されました。Unity社はHDRPが自動車、製造業、映像産業、ゲーム用途などで利用されることを想定しています。
Getting started with ray tracing
URPは、従来のパイプラインに比べ、軽いので、モバイル向け。軽いにもかかわらず、グラフィックの違いはよく見ないと分からないぐらいでしかないです。
重いか軽いかはどのようにコンテンツを作ったかに依存する部分が多く、パイプラインの違いをのみこの理由にするのは望ましくありません。複雑なメッシュ、計算量の多いシェーダーやレイトレース、パーティクルなど、重くなる要因は様々です。また、モバイルベースのVRデバイスではハイエンドなPCと比較すると非力なため、アプリケーションの作り方次第では容易に重くなるという、採用したプラットフォームの要因もあります。
このため、いかにパフォーマンスチューニングするか、またルックや体験の質を落とすことなくコンテンツから重い要因を取り除くことは、デベロッパーにとって重要な仕事です。
HDRPやURPはSRP(スクリプタブルレンダーパイプライン)が使われているので、改造出来ます。
これによって、Shader graphなどで、描画したものを加工したり、独自のポストエフェクトを使えます。
パイプラインをカスタマイズできるということは、文字通りパイプラインに手を入れることが可能になっているということであり、単一のシェーダーをノードベースで作成できるShaderGraphが使えるということと直接的な関連はありません。
ビジュアルの加工についても、独自のポストエフェクトについても従来から可能なことです。
繰り返しますがパイプラインに手を加えることと、挙げられたメリットに関連はありません。
最近出来たものだし、使い勝手が悪いので、情報が少ないです。
Unity公式がマニュアルを公開していることと、利用ガイド的なUnityブログがあり、情報が少ないとは言い切れません。日本語で読めるブログが少ないというならあっています。
また、この文に「使い勝手が悪い」と挿入された箇所について前後の繋がりが理解できません。
SRPでは色々な理由で、シェーダーをプログラムで書くのがとても難しいです。
私はずっとプログラムで書くために、たくさん調べてきましたが、SRPに伴い、シェーダーを書くコードがShader labでなくなったみたい？で、まだ書けていません。
他のプログラミング言語と比較した場合に、シェーダー言語にはハードルがあることは確かです。ここに余計なことをさらに付け加えると、そもそもプログラミング言語をはじめるということにもハードルがあります。
本題に戻ると、SRPではHLSL言語でシェーダーを記述することが可能で、これはカスタムポストプロセスやShaderGraphでのカスタムファンクションノードにテキストで書いて使います。また、いわゆる従来のShaderLABで使用する言語はCg/HLSL言語であり、書法、書式としては共通するところが多いものとなっています。
つまり、ここでロジックを整理してみると、もしもShaderLABでHLSLを描いてきたのであれば、SRPでもHLSLを描くことができます。
念のため逆についても書いておくと、SRPでHLSLを描けないのであれば、おそらくShaderLABでHLSLを描くことができないと推測できます。
従来のシェーダーが使えない
既存のアセットの一部が使えない、使いにくい
アプリケーションのバージョンが上がったり、新しい概念での何らかの仕組みが登場した時に互換性の問題はつきものですが、ものづくりをする立場であれば選択肢はふたつかとは思います。
・自力でセットアップする
・対応したものが出てくるのを待つ
マテリアルで前者のやり方は、URPであればシェーダーの変換について扱った日本語のブログ記事が存在します。HDRPについてはそもそも物理ベースで扱うという概念に変わっているので、自分がやりたい表現にHDRPが最適かどうかを先に考慮するべきです。
従来のシェーダーが違うために、GaiaやAura2などグラフィック系のアセットが使えないです。
SRPではVolumeという機能が追加されているので、まずはそれをどう使うのかを調べるべきでしょう。これはつまり、サードパーティに追加の費用を支払うことなく、標準の機能で実現できる可能性が増えたということであり、エンジンが進化したことを喜ぶべきです。
これら従来のアセットは今後、エンジンの標準機能をサポートする役割としてバージョンアップするか、または役割を終えたと判断して開発を終了するかのどちらかになることでしょう。
結論から言うと使うべきではないと思います。
世界はたいへんに複雑であり、〇〇である、〇〇ではないといった断言できることはそれほど多くありません。
私はテキストを書く時に文末を断定で終わらせることは多くありますが、実のところ常に迷ってます。果たして、私にとって正しいと思うことが、他者にとってもそうであるかという疑問です。
完全にこれは個人の思いではありますが、他者に対してべからずの結論を伝えるよりも前に、何かもっと考慮するべきことがあるように感じられてならないのです。