はじめに
こんにちは！代表の堂前です。
前回の記事に引き続きUnite Tokyo 2019の話題ですが、ありがたくも講演の機会を設けていただきました。自分自身はUnite 2016でも登壇させてもらったのですが、その時と同様、非常に刺激を受けて面白かったです。この場を借りて、改めて御礼申し上げます。
では早速本題ですが、今回は講演内容の補足をお送りします。
講演について
「SRPで一から描画フローを作ってみた！ ～Unity描画フローからの脱却～」という演目でお話しさせてもらいました。こちらにスライドと動画が上がってますので、ご覧いただけると嬉しいです。
https://learning.unity3d.jp/3284/
当初は講演時にはサンプルプロジェクトを用意していてすぐ見れるようにしたかったのですが、時間が無く間に合わず。。。
「それなら動画やスライド上がったタイミングに合わせよう！」と思ったのですが、思いのほか早くてｗ
急ぎでサンプルプロジェクトを仕上げました。
（今回のUniteは凄く良かったという声を多く聞きますが、運営事務局様の力が大きかったと思います。本当にありがとうございます）
サンプルプロジェクト
GitHubにサンプルを上げました！
https://github.com/lb-YoshikiDomae/Unite2019_SRP/
なるべくシンプルに、かつ説明を多くするように心掛けました。
講演の時に上げたブレンドバッファ描画周りをベースにしていて、そこからシャドウやライティング周りも作ってみました。
シャドウは投影テクスチャシャドウです。長年の夢が叶った瞬間です。
更に調子に乗って、パーティクルシャドウも実装しました。これは投影テクスチャシャドウならではの表現とも言えます。
プロジェクトの概要についてはGitHub側のReadmeをご覧いただくとして、本ブログではもう少し補足を入れていきます。
補足事項
UI描画について
講演内で「SRPDefaultUnlit」を用いると描画されるという話をしました。
で、実際にそれでGameビューには描画されるようになりましたが、Sceneビューでは出てきません。。
LWRPではSceneビューでもキチンと表示されていたので、何か設定が足りていない気がします。
 |  |
UIシェーダ内の処理について
講演内でUIシェーダが重いと言いましたが、それはこちらの件が根拠として残っていたからの発言でした。
が、最新のビルトインシェーダのUIシェーダ見たら、UnityGet2DClipping()もキーワード分離されているのに気付きました。
ここが懸念点としてあったのですが、デフォルトUIシェーダでほぼ問題ないと感じます。
ですので負荷削減用途では用意せず、UIでトリッキーなことをしたい場合は独自で用意する、くらいでいいと思います。
カリング＆フィルタリングの結果を先に知りたい
これは今後への要望です。
カリングやフィルタリングした結果、どれだけのRendererが描かれるかを先に知りたいです。
というのも、これはブレンドバッファ法に関わります。
ブレンドバッファの処理の大まかな流れは以下の通りです。
縮小バッファにデプスをコピー＆カラークリア
↓
パーティクル等を描画
↓
メインバッファに縮小バッファをフィードバック
ここでもしパーティクル描画が行われないとしたら、コピーとフィードバック処理が全くの無駄になってしまいます。
ですのでブレンドバッファに描くものが無いと判断した場合、負荷削減のためにコピーもフィードバックもキャンセルしたいです。
今はテスト結果だけ受け取れるような関数が恐らく無いと思うので、今後実装されると非常に嬉しいです。
Receive Shadows設定
投影テクスチャシャドウを採用している兼ね合いで、影を受けるのはPlane（床）だけにしたいです。
本来ならRendererに「Receive Shadows」にあり、それを設定することでシェーダのキーワードが有効or無効になり、描き分けているようです。
本プロジェクトもそれを目指していたのですが、LWRPを見るとRendererから「Receive Shadows」が排除され、Material側に移ってました。
それに倣う形でMaterial側に設定を追加しましたが、Rendererからは排除できていません。
分かりやすくするため排除するのがいいのは分かっていますが、ここはどうしているのか引き続き調査の必要がありそうです。
Qualityから項目が消える
独自SRPに切り替えると、Quality周りから各種項目が排除されます。
LWRPではRenderPipelineAsset側に設定項目を持っているようです。
 |  |
本プロジェクトはこの辺りは全く何もしていません。
というのも、例えばコンシューマー向けならばQualityを複数持つ意義が薄いだろうというのが一点目。
あとSRPを触るプログラマがスクリプト側で設定しやすいようにしていたら、無理にGUI側に移さなくても、、、と思うのが二点目。
この二つから、個人的にはパラメータを外部に出すのはそこまで優先度が高くないように考えたためです。
しかししっかりしたシステムを作るならば対応しないとなので、その時はまたLWRP（時期的にURPですかね）を見ることになるかなと思います。
まとめ
エンジンを触っていると既存の描画フローにもどかしく感じることが多く、たまに諦め、たまに泥臭く対処していたのですが、SRPが出てきたことで状況が大きく変わったと言えます。
自分にとっては悲願と言える機能なので、触っていて非常に楽しかったです。
ただやはり情報が無かったり、LWRPも高機能が故に追いづらいところもありますので、これでSRP自作しようという人が増えて、それに伴って情報が増えると嬉しいです。
【免責事項】
本サイトでの情報を利用することによる損害等に対し、
株式会社ロジカルビートは一切の責任を負いません。
