これらの本のほとんどは技術同人誌で、技術書典という技術同人誌即売会に合わせて新刊が出ることが多いので著者の方々をSNSでフォローしたり技術書典をチェックするといいです。

他の環境も検索対象にする

他の環境のシェーダーもロジックやプログラム自体は参考にできるので関心を持っておくと得られる情報が増えます。
サイトで言えばshadertoyなんかが有名どころですが、レベルが高いものが目立ちます。
他には、僕の観測範囲ではtouchDesigner、openframeworks、WebGL、とかですかね。
他の環境のシェーダーは言語はGLSLが採用されている事が多いです。(Unityはシェーダーの部分はcg/HLSL)なのでGLSLについても少し勉強しておくと他環境のシェーダーも読み易くなります。UnityでもGLSLでシェーダーを書くことはできます。

挫折要因

そもそもプログラミング未経験(VRCユーザー向け)

VRCユーザーは特にこれに当てはまる人が多いと思いますが、Unityでシェーダー開発をする場合はコードを書くかノードベースのツールを使ってGUIで開発するかのどちらかです。
それぞれのメリット・デメリットについて考えてみます。

ノードベース

ノードベースのツールは下記の3つを目にすることが多いのです。

• shader forge (開発中止になって現在無料)
• amplify shader editor (有料アセット)
• shader graph (Unity公式のツール。VRC用ならこれは現状使えません)

メリット

プログラミングの経験が無くてもツールの使い方を覚えれば使える事。学習コストはコードに比べて低いと思います。
視覚的にプログラムを理解しやすい。誰かが作ったシェーダーを理解する時に、視覚的にプログラムを追えると嬉しかったりする。(但し、同じツールで作られたシェーダーでないとツール上でファイルを開けないです。)
難しいこと考えずにポチポチ作れて気楽。

デメリット

自由度はコードベースに比べれば下がるので変わった事をやる場合に出来なかったりすることもある。
開発元の動向に左右されることもある。ノードベースのシェーダー開発ツールのshader forgeは開発中止を発表したのですが、その後に別のノードベース開発ツールに移行する開発者も多く見かけます。
複雑なプログラムをノードベースで開発すると寧ろごちゃごちゃして見づらくなったり理解しづらくなったりする。ごちゃごちゃした状態をよくスパゲッティって表現してることありますよね。
コードで作られたシェーダーはツールで開けないので得られる情報はコードに比べれば少ないです。

コードベース

メリット

情報量が多い。
ノードで開発したシェーダーもコードに展開できるのでノードで作ったシェーダーも読める。ただ、ノードで作ったシェーダーはコードに展開するとめちゃくちゃ読みづらい事が頻繁にあるので読みづらい。
ノードで出来て、コードにできない事はない。

デメリット

ノードなら内部的によしなにやってくれる部分も自分で書かないといけないのでそういう意味では比較的学習コスト高いかも。

補足

プログラミング未経験でコードベースでシェーダーを作れるようになりたい場合は、以下の項目を理解しておけばとりあえず問題ないと思います。

• 型と変数
• 四則演算
• 関数
• if分岐
• for文
• 構造体

これらは細かい部分に違いはありますがシェーダーに限らず大抵のプログラミンにおいて共通の概念なので、Unity使えるわけなので一旦C#で上記の扱いを学んで見るのも良いと思います。シェーダーを通してこれらを学ぶよりC#で学んだ方が良いと思う理由は後述するシェーダーにおけるデバッグの不便さです。

ドキュメントの状況がよろしくない

シェーダーについて調べると体系的にまとまった資料は少ないように感じます。これが結構つらいなぁと思います。英語のサイトなら体系的にまとまったサイトも見つかりますが日本語情報だと微妙です。Unityのドキュメントもざっくりしていて初学者には優しくないです。
日本語の情報で丁寧に学習するなら前述した本を読むのがいいなと僕は思いました。

数学的知識が必要になることがある

シェーダーではベクトル、行列を扱う事が多いです。数学的な分野で言うなら、高校レベルのベクトルと、線形代数でしょうか。
数学が苦手な人はこれが壁になるかもしれないですが、行列はベクトルを一定のルールで別のベクトルに変換するフィルターだと思って入門解説をちゃんと読み進めれば意外とできます。
基本的にはシェーダーで扱う行列は行列の基本的な部分なので線形代数をみっちり勉強する必要はありません。
趣味でシェーダーを触るなら(VRC向けの開発をするなら)、最悪理解しきれなくても使えれば問題ないと思いますし、ノードベースならコードベースより行列を気にする事は少ないです。

デバッグの難しさ

シェーダー開発をしていて辛いのはデバッグの不便さです。
結論バグの回避策は、こまめに実行して実行結果を確認しながら開発する。拡張アセットを使う。ロジックを小分けにしてそれぞれを単体で実装して挙動を確認する。値は色で出力してみる。とかです。
VSCodeを使っているなら下記のアセットを使うのがおすすめです。
ShaderlabVSCode

シェーダーは、Debug.Log()のようなコンソール出力もないし入力補完などのサポートもデフォルトだとあまり優しくないです。
例えば、以下のようなコードを書いたとします。

float  vector  = float3(1,0,1);

一行目で3次元ベクトルを宣言したつもりですがコンストラクタはfloat3()ですが、行の先頭でfloatで宣言していてvector変数はベクトルとして機能していないです。ですが、この記述はコンパイルエラーにはならず実行出来ます。当然予想外の実行結果になります。こういう記述ミスは往々にして自分だと気づかず数時間溶けたりしますが、実装したロジックが間違っているのか記述ミスしているのか分からず辛いです。
コードだとこういうデメリットもありますね。
デバッグには気を使いましょう。。。

僕が勝手に話したい事

ここ一番書くの楽しみにしてたけど疲れてきた...

シェーダーの知識と作るもののロジックの知識は別

当然といえば当然で筆と絵の具の使い方を知っていれば誰でも絵師になれるなんて事はないのと同じでシェーダーも書き方知ってれば良いモノ作れるってこともないです。
色々なロジックを知っている事が大事だと思っているんすが
個人的に気にしてるキーワードは

• シミュレーション
• CG
• 数学
• ジェネラティブアート
• モーショングラフィック
• デモシーン

とかです。元々ジェネをしていたのでほぼジェネが中心になってますが。
これらの分野のロジックや現象をシェーダーで実装するなどすると面白いもの出来たり完成度上がったりすると思ってます。

SNSやらで見かけたキーワードを逐一メモしておくと良いです。僕は気になったツイートをそのままツイッター上の自分のDMに送信して貯めています。
SNSでシェーダーデベロッパーをフォローするのも刺激にもなりますし、作例や解説を公開してくださっている方もいらっしゃるので得られるものは多くあります。

更に勉強する為にできそうなこと

ある程度慣れてくるともっと面白いモノを知りたいと思ってきますが、個人的に高品質な情報源として気にしているのは、海外のデベロッパーのSNSとカンファレンスです。
海外のデベロッパーをSNSで追ってみると日本語で調べてた時には出てこなかったテクニックが出てきて興味深いです。twitterでgame devとかunity3dとかで検索するとデベロッパーを見つけられると思います。pixiv fanboxのようなサービスでシェーダーの解説を公開していたりもするので土下座しながら読んでます。
Unite、GDC、CEDECなどのカンファレンスの講演も実践的な内容があって興味深いです。アーカイブやスライドが公開されている事も多いのでチェックすると良いと思います。

おわり

なんか実際のシェーダーの解説とか全く書いてなくて面白くない内容になっちゃいましたが、去年の自分、勉強し始めた頃の自分に伝えたい事を書きました。来年の技術書典で記事の最初に貼った作例の解説本を書いてみようにゃん。
情報を公開して下さっている皆さんに土下座しながらこれからも勉強します。ありがとうございます。

明日は、@LinaTsukusu さんの記事になります。