この記事は KLab Creative Advent Calendar 2019 の 24日目の記事になります。
こんにちは。クリエイティブR&Dグループ所属、みにーと申します。
私は現在、駆け出しTA(テクニカルアーティスト)としてシェーダー開発を行ったり、グループ内の開発環境整備などを行っております。
まず、「駆け出し」TAというところや、記事のタイトルから予測できるように、私はベースが完全アーティスト出身のTAとなります。
ジェネラリストとして、2D・3D両方とも幅広くやってきたことから、一つの技術に特化した踏み込んだ内容は書けないため、今回どのような内容の記事を書いたら一番興味深い内容になるのか、しばし悩みました。
思い返すと、私自身TAにジョブチェンジする際に、あまりアーティスト目線での参考資料が見当たらず苦労した記憶があったため、今回はそのような「アーティストだけど、ちょっとテクニカルなことに興味ある」方向けに、私がどのようにシェーダーについて勉強したかを、近年様々な箇所で活用されて来ているノードベースのビジュアルシェーダーエディタの紹介を交えてご紹介させていただければと思います。
(エンジニア出身でないがゆえに、フローがスマートではなかったり、主観的なところや我流の理解もあると思いますが、温かい目で見守っていただけますと幸いです...!)
アーティストだけど、ちょっとテクニカルなことに興味ある
ノードベースのビジュアルシェーダーエディタを触ってみたい
Unity上でシェーダーを作ってみたいが、コーディングできない
エンジニアさんの手を通さずとも、気軽にルックデブしたい
ビジュアルシェーダーエディタは、コードを書く必要なくエディタ上でノードを作成し、コネクションを作ることで視覚的にシェーダーを構築できるツールのことを指します。
今回はUnityベースで解説したいと思っているので、
上記の2つのツールを使ってご説明させていただきます。
勉強を始めた当初の私は「とりあえずツールをインストールして触ってみたら分かるかも!」と安易な考えを持っていました。しかし、実際に触ってみたところ、概念も用語も何も知らない状態だと、やはり作業途中で躓く回数が非常に多く、ものづくりがスムーズにできるような形でツールを触りきれませんでした。
ビジュアルシェーダーエディタも結局のところ、シェーダーのコードをノード(Node)構造で作っているツールです。なので、最低限のUnity上でのシェーダーの仕組みは知っておかないと上手くノードを扱えなくなると感じました。
そこで、Unityのシェーダーについて解説されている、先人の方々の初心者向け資料を一通り読ませていただきました。
元々私がコーディング経験皆無という点から、上記の資料を読むだけではすぐさま「シェーダー作れるぞ!」というような理解まで追いつくことはもちろんなかったのですが、これだけは頑張って理解したいと思い集中的に読ませていただいたのは、「シェーダーの中身はどのような構造になっているのか?」です。
ざっくり説明すると、シェーダーについて全く何も知らない私が、一番知りたかった部分は以下のようなものでした。
どこが実際自分がシェーダーを書く部分なのか?
どこをいじれば、シェーダーの見た目に影響がでるのか?
作られているシェーダーのプロパティはどこにあって、 パラメータは
どのような風に入れ込まれているのか?
なぜ上記を知りたかったかと言うと、
どこが実際自分がシェーダーを書く部分なのか?
→ 既存のシェーダー類をある程度参考できるようになれる
どこをいじれば、シェーダーの見た目に影響がでるのか?
→ アーティストとして、一番シェーダーに求めていることは、
どういう「絵」を表現しているかである
作られているシェーダーのプロパティはどこにあって、 パラメータは
どのような風に入れ込まれているのか?
→ アーティストが実際与えられたシェーダーをマテリアルにアサイン
した際に、一番触ることになる部分である(UI/UX的な影響)
上記がある程度認知ぐらいはできる!というレベルまで来たら、
実際にビジュアルシェーダーエディタで、どのような「値」「命名」「形」でシェーダーを作れば良いのかイメージが湧いてきました。
先述したように、私はこの時点ではまだシェーダー仕組みに関して100%理解がついて来ていません。しかし、ビジュアルシェーダーエディタの思想が「視認できる形でシェーダーを作る」という点から、ある程度のシェーダーに対する最低限の知識がついてきたこのタイミングだと作れるイメージが浮かんできたため、一旦SRP環境であれば無償で使える、UnityのShader Graphから試すことにしました。
しかし私はまた躓くことになります。
\\\ノードの挙動が文字とコードでしか説明されていない...!///
そうです。数学とおさらばして数年...
いつの間にか私の脳は、図面がないと理解度が絶望的に進まないようになっていたのです。
また、Shader Graph自体、SRPという環境下でしか使えない分、当時参考にできるチュートリアルもそこまで見当たらず、このツールを使用しながらノードについても慣れて行く...そうするためには思った以上に時間がかかりそうだと感じました。
ビジュアルシェーダーエディタの思想と同じように、「視覚的」に各ノードの挙動が分かるようなマニュアル...挙動を可視化させている資料を私は探し求めるようになってきました。
その時、私はAmplify Shader Editor(ASE)と出会います。
親切なチュートリアル動画!
親切な図面(Gif)+活用例付きのマニュアル!
活発な公式サポートコミュニティー!
なんとレガシー環境からSRPまで対応!!
\\\これだー!!!///
これこそが私が望んでた可視化されたマニュアル!
公式のチュートリアル、マニュアル、そして公式コミュニティでのサポートバフのおかげで、私はASEを使い始めてわずか3日目で、自作トゥーンシェーダーを組めるようになってました。
ツールの仕様や、ノードの挙動を一つずつ熟知していったら、あとは簡単で、トゥーンシェーダーのみならずエフェクトにも使えそうなシェーダーとかもみるみると作れるようになってきてました。
ここまでいうと、「ではShader GraphよりASEを使ったほうが良いの?」「ASEが優れているの?」というと疑問が出ると思うのですが、シェーダーを一から勉強している立場としてはリファレンスが充実していたASEの方が有り難かったというだけで、最終的には使用者のスキルセット・開発環境によってもどちらがマッチしているかが変わってくると思ってます。
私も現在は、プロジェクト環境や都合などを配慮して最終的にShader Graphを使用していますが、ASEの可視化されたマニュアルに触れたことによってノードたちの挙動の知見が得られ、今は特にツール自体につまずくことなくShaderGraphでも問題なくシェーダーが作れるようになりました。
ただ、現段階でどちらも使用したことがあるイチユーザーとしての感想は、Shader Graph自体、比較新しいツールのため、最適化部分や、使い勝手面でASEと比べてまだまだ改善できる点が多くあると感じました。
締めくくりとして、自分が使用して感じたShader GraphとASEの差や、
良かったところを簡単にご紹介させていただければと思います。
チュートリアル資料など初心者がすんなり入れるような参考資料が豊富。
操作が快適。
色分けされたグルーピングやメモなど、視認性良くノード類を整理しやすい。
Property Name(ShaderGraphで言うReference)もノード名を変えるだけで
自動的に合わせて変換してくれる。(ShaderGraphは手動)
レガシーでもSRPでも特に劇的な差を感じることなく、コンパイル時間に
とらわれずストレスフリーに作業できる。
レガシー環境・SRP環境関係なく使用することが可能。
レガシー環境で作ったシェーダーをそのままSRP環境に持っていき、ちょっと
ノード調整してあげるだけである程度流用できるようになる(互換性がある)
ASEで作成されたシェーダーはコードの状態で出力され、かつ出力されたコードは
その状態のままASEエディタ上で開ける仕様になっているため、コードが分かる人
にレビューしてもらったあとにそのまま調整することも可能。
ShaderGraphの場合、MasterNodeでShow Generated Code押して変換して
あげないと、コードの状態が見れない。かつ一度コードにしたファイルでは、
エディタに戻れない。
Unity自体に入っているため、無料で誰でも使用できる。
ASEは有料 : $60
チーム内でUnityを持っているエンジニアさんとかにデータなどを直接渡して
質問・レビューしてもらうことも可能(ASEの場合、基本1Seat 1Licenseの
ため、使用する人数により購入が必要)
UnityのSRP環境下であれば、どのUnityバージョンでも使用できる。
ASEはUnityで公式リリースしたバージョンでしかサポートしていない。
Unity公式で出ているツールなので、今後に期待できる。
Unity新バージョンに追加される機能面とつながるノードなど、一番早く
対応してもらえる。
サードパーティツールと比べて、公式ツールなのでサポート体制に関する
リスクが低い。
アーティストの方々に是非オススメしたいこと
私は自分の記憶力を基本的にあまり信じてません。なので、なにか新しいものに触れる際は後から読み返しても分かるような形でとにかくメモ・ログを取っておくようにしてます。そうすることで、「以前この問題をどう解決したっけ?」と思い出せない時に、すぐ検索して遡ることができるからです。
また、このログを適度に社内の技術交流が活発なグループチャットなどで上げたりすることで、興味を持ってくれている方々のアドバイスも頂戴することができ、もっと勉強が捗りました。
以前作成したシェーダーのグラフ全体図のスクショを撮り、一つのレファレンスファイルとして扱うようにしてます。一度組んだことある仕組みを思い出す時にすごく助かっています。(私はPureRefと言うレファレンスツールをよく使ってます。)
TAは割と技術的な面に対してスポットライトが当たることが多いですが、
個人的にTAの本質的な役目は、いかにアーティストが居心地良く作業してもらえる環境を作れるかだと感じております。
シェーダー開発時にも、アーティストが追求したい表現に対して、デザイナー目線で物事を理解し提示できることが、アーティスト出身TAの強みだなと再認識するきっかけにも繋がりました。
今回の記事は、技術的な内容にフォーカスしているのではなく、結構長めの個人ログみたいな記事となってしまったため、あまり参考にならなかったかも知れません。
ですが、私のようにシェーダー作ってみたいけど、なかなかハードルが高くて挑戦できなかったアーティスト方々に少しでも役立てたのなら何よりです。
最後まで読んでいただきありがとうございました。
KLabのクリエイターがゲームを制作・運営で培った技術やノウハウを発信します。
合わせて読みたい
KLabのクリエイターがゲームを制作・運営で培った技術やノウハウを発信します。