フラグメントシェーダー芸

　フラグメントシェーダーの小技を集めてみました。

円を描く

最低限のコードで動かすとやってることはほとんど同じ
- 色が違うのと、VanillaGLで書き換えているくらい（驚きの見通しのよさ）
- ポイントの位置を頂点シェーダーで決め打ちしていて頂点バッファがないので、drawArraysはVanillaGLProgramのものではなく、WebGLRenderingContextの素のdrawArraysである点に注意
if文が増えている: if (...) discard
- 条件が成立したら点を「捨てろ」という意味
- ポイントスプライトの座標系は縦横とも0〜1なので、0.5を引くとスプライト中心が (0, 0) になり、±0.5の範囲になる
- これをlengthすると、現在描画しているピクセルがポイントスプライトの中心からどれくらい離れているかが分かる
- 単位はポイントスプライトの大きさを1とした大きさ
- したがって、中心から0.5以上離れた点を捨ててしまえば円になる
フラグメントシェーダーによる円の特徴はどんなに拡大しても真円になること
- 頂点シェーダーでは円周を頂点で表現するので、拡大すると角が分かるようになる
- フラグメントシェーダーの場合、ポリゴンを使っても頂点4つで真円が描ける
- ポイントスプライトの場合はアスペクト比の影響を受けない（パースが付けられない）
- 簡単な方程式で表現できる図形しか書けない（楕円は大丈夫）
余談: ポイントスプライトのサイズはgl.getParameter(ALIASED_POINT_SIZE_RANGE)で分かるが、GLの仕様ではサイズ1だけ書ければよいことになっているので、実はきちんと描画できないかもしれない
- でもよく使われる芸なので、ある程度の大きさまでは大丈夫（どの程度かはよく分からないけど）
- M3 MacBook Proでは最大511だった
ポリゴンでもできる
- テクスチャ座標を流用すればよい
- というか、テクスチャを引かないので、もはやテクスチャ座標ですらない
- ポリゴンの場合はアスペクト比（というか、元のポリゴンの投影座標変換）の影響を受ける

discardの効果

discardではなく、アルファを使っても見た目は同じにできる
深度テストを使うと結果が違ってくる
とりあえずVanillaGL.initを少し拡張する
```
init(opt) {
	...
	if (opt?.useDepth) {
		this.enable(this.DEPTH_TEST);
		this.clearMask |= this.DEPTH_BUFFER_BIT;
	}
},
```
- opt引数を追加し、useDepthがtrueならば、深度テストを有効にして、initCanvas時に深度バッファもクリアするように設定
promise_allもprepareという別名を作ってある
- promise_allはPromise.allに合わせて引数がプロミスの配列だが、prepareはプロミスを直接指定する
```
const ready = prepare(...);
...
ready.then((...) => {
	...
});
```
  のように使う（prepare→ready→then）
discardによる円とアルファによる円を描いてから、キャンバス全体を覆う四角形を描く
Zの値を調整して、円が前、四角形が後ろになるようにする
- 円のZは-0.5、四角形は何も指定していないが0になる
- GL（右手系）のZ座標は手前がプラス、奥がマイナスだが、ここで指定しているZは深度値であり、デフォルトでは小さいほど手前、大きいほど奥、つまりZ座標とは符号が逆なので注意
- この挙動はgl.depthFuncで変えられる
描く順序も大事

アルファによる円はポイントスプライトがある部分で上書き描画されていないことが分かる
つまり、discardするとフラグメントシェーダーの呼び出しがなかったが如く、カラーバッファだけではなく、深度バッファへも出力が行われない
結果として、discardした部分は、背後にあるものを後に描いても描画される
この例で四角形を先に描けば見た目上の結果は同じになる

枠を描く

　中を抜けば枠になる。

all(lessThan(abs(vTex - 0.5), vec2(0.45))))
- 残念ながら黒魔術ではない
- vTex - 0.5: テクスチャ座標vTexの各成分から0.5を引く、結果は±0.5になる
- abs(...): 絶対値をとる、結果はポリゴン中央の時が (0, 0) で一番外側はどちらに行っても0.5
- vec2(0.45): x, yとも0.45のvec2を作る
- lessThan(...): vec2の各成分を比較して、第1引数の方が小さければ対応する成分をtrueとしたboolのvec2、つまりbvec2を返す
- all(...): 引数のbvec2の成分がすべてtrueならばtrue
結局、テクスチャ座標のxあるいはyが中央から0.4より内側にあれば条件が成立してピクセルが破棄される
結果、穴が開く
テクスチャ座標なのでパースが付く
マウス（タッチ）で回せるようにしてみた

VanillaGL.pers0を定義している
- キャンバスサイズを拾ってVanillaMat4.pers0を呼んでくれる
- アスペクトモードと角度の単位は現在VanillaMat4に設定されているものが使われる
- アスペクトモードはmodeでも指定できる
VanillaMat4のtoRadianをデフォルトから変更するとVanillaGLTouchDragで問題が起きるので修正
```
	setupTouchDrag(canvas, ev => {
		Mat4.pushToRadian?.();
		...
		Mat4.popToRadian?.();
		this.draw();
	});
```
toRadianがない古いVanillaMat4でも動くようになっている
「円を描く」と組み合わせると角を丸くできる

長方形にしてみる
テクスチャ座標の縦と横で縮尺が異なる
長方形の横:縦が1:2ならば、Y方向のテクスチャ座標はX方向の倍
Y方向の太さと半径を、X方向の半分に設定すると表示上は同じ量になる
フラグメントシェーダーのuBorderは.xyがボーダーの太さ（X方向・Y方向）で.zwが角の半径（X方向・Y方向）
まず、テクスチャ座標系を角が原点、中央が (0.5, 0.5) という座標系に変換
- p = 0.5 - abs(vTex.xy - 0.5)
p.xyのいずれかが半径より大きかった場合はボーダーの太さよりも大きい（内側にある）点をdiscard（else節）
p.xyの両方が角の半径より小さければ角の部分を書く
円の書き方: 実際には楕円になる
\begin{align*} \frac{x^2}{a^2}+\frac{y^2}{b^2}=1 \end{align*}
左辺が1より小さければ楕円の内側、大きければ楕円の外側
両辺に\(a^2b^2\)をかけて分母を払うと
\begin{align*} x^2b^2+y^2a^2=a^2b^2 \end{align*}
左辺の方が小さければ楕円の内側、大きければ楕円の外側
\(a\)をz、\(b\)をwとして、楕円より外側ならdiscard
それよりボーダーの太さだけ細い楕円、つまり\(a\)をz-x、\(b\)をw-yとして、楕円より内側ならdiscard
座標系をさらに変換し、楕円中心を (0, 0) に
- p = uBorder.zw - p
角の半径からボーダー太さを引いて、内側の半径を求める
- r.xy = max(vec2(0), r.zw - r.xy)
- ボーダー太さが角の半径より大きくなった場合は引き算の結果が負になるが、0に押さえ込む
- つまり、内側の半径を0に押さえ込むことで、楕円内部すべてを塗りつぶすように仕向ける（この説明には少しごまかしがあるが、各自で考えられたし）
- この時点でr.xyが内側、r.zwが外側の半径になっている
あらかじめp *= pのように各成分を2乗しておけば、\(x^2b^2+y^2a^2\)はdot関数（内積を求める関数）で求められる
- たすきがけになるので注意（スイズル一発）
あとは数式のとおり

角を落とす

　テクスチャの角を落とすこともできる。

VanillaGL.loadTextureは意外にも作ってなかったので作っておく（glUtil.loadTextureを呼び出す）
setTextureはsetUniformと並べた時に第1引数がUniformの型を示す文字列の方がコード全体の座りがいいため、第1引数が文字列だった場合は第2引数と順序を逆にしてglUtil.setTextureを呼び出す
CSSも結構同じことを何回も書いているので、gl-sample.cssに追い出した
今回のテクスチャはJPEG画像なのでアルファチャンネルがない
別にアルファ画像を用意する方法もあるが、フラグメントシェーダーで角を落としてみる
テクスチャ座標の.xyから0.5を引くと、テクスチャ座標の原点が (0.5, 0.5) に移り、座標の範囲は (-0.5, -0.5)〜(+0.5, +0.5)になる
さらにabsをとると、マイナス側にはみ出した部分がX軸・Y軸と対称な位置に「折り返す」
- 座標範囲は (0, 0)〜(0.5, 0.5) になる
- ちょうど折り紙を四つ折りにした感じで、角が (0.5, 0.5) の位置に揃う
ここでさらに0.5を引くと角が原点に来てテクスチャ全体がマイナス側にはみ出すが、ボーダー半径分だけプラス方向に動かせば、楕円の中心が原点にくる
残りの部分は最小値を0にすると、大体の点は原点、悪くて楕円内の軸上に集まる
- maxで0と座標値の大きい方を取るので、座標が0未満になると0を返す、つまり、最小値が0
あとは前節の楕円の式に照らし合わせて、いらない部分をdiscardすればよい
uRadiusの.a成分が最終結果のアルファ成分に設定される 31 Aug 2024
.zは使われていない

太さのある線、みたび

　フラグメントシェーダーで円が描けるのだから、いわゆるラウンドキャップの直線（角が丸いやつ）が描けるのではないか？

入力頂点仕様

uMatは投影変換行列
uThicknessは.xyにキャンパスサイズ（幅と高さ）を、.zに線の太さを入れる
線の太さは基本的にはピクセル単位で、この例ではパースがつくので、Z=-1の位置にある場合のピクセル数
p1とp2は直線の始点と終点
uvは直線および接合部のテクスチャ座標っぽいもので、どの位置の頂点かを示し、.zが0ならば直線、1ならば接合部の頂点であることを示す
直線部分でトライアングルをふたつ、接合部でふたつ描くので、直線セグメントひとつにつき4つのトライアングルを描く
ただし、直線部分と接合部分の頂点が離れているため、普通のトライアングルストリップでは描けない
縮退三角形を含む頂点列にする必要があるが、この例では指定する頂点数が変わらないため、普通にトライアングルを4つ描いている。
したがって入力頂点は直線セグメントひとつにつき12個になる
どの点を指定しているかをuvで示し、p1とp2は12回すべて同じ値を指定し、uvだけを8通り（指定する頂点数は12個だが、そのうち4個は重複しているので全部で8通り）指定する

uv.xyzの指定の仕方は以下のようになる

直線部三角形1	`[ 0, 1, 0 ], [ 0, 0, 0 ], [ 1, 1, 0 ]`
直線部三角形2	`[ 1, 1, 0 ], [ 0, 0, 0 ], [ 1, 0, 0 ]`
接合部三角形1	`[ 0, 1, 1 ], [ 0, 0, 1 ], [ 1, 1, 1 ]`
接合部三角形2	`[ 1, 1, 1 ], [ 0, 0, 1 ], [ 1, 0, 1 ]`

頂点シェーダーの詳細
- p1・p2を投影変換行列で斉次座標に変換、さらに.wで割ってスクリーン座標を求める
- offsetはuv.xyが (0, 0) - (1, 1) なのに対し、(-1, -1) - (1, 1) になる
- kは直線太さをキャンバスサイズで割ったもので、直線の太さをスクリーン座標系で表していることになる
- 太さをキャンバスサイズと同じにするとkが1になるが、スクリーン座標系は-1〜+1なので、実際には画面の半分にしかならず、直線の太さの半分に相当する
- uv.zが正の場合（通常は1を指定）は接合部なのでuv.xyをテクスチャ座標としてそのまま流す
- そうでない場合（通常は0を指定）は直線部分なので、方向ベクトルを求め、スクリーン座標系からキャンバス座標系に戻し（縦と横の縮尺をそろえる）、法線ベクトルを求める
- p1とp2のスクリーン座標が一致する場合は法線ベクトルの長さが0になるが、ゼロ除算を避けるため、長さの最小を1/1,000,000に押さえ込む
- uv.xによって始点と終点のどちらかを選び、uv.yで直線の上側と下側のどちらの頂点なのかを決定し、kをかけて始点もしくは終点に足すことで頂点座標を作る
- kは直線の太さの半分なので、上下に半分ずつ描くことで、できあがりの直線の幅は指定どおりになる
- 直線部分は単純に塗りつぶすだけなので、テクスチャ座標としては (0.5, 0.5) 、つまり円の中央を設定する
- これで直線部分は必ず塗りつぶされる
- フラグメントシェーダーはポリゴンで円を描いた時のものと同じ
赤道と、X軸正方向の直線を描画している 31 Aug 2024
prepareRoundCapLineが線を用意してくれる
- pointlistには点列を渡すが、次元は問わない
  - デフォルトでは1次元で0→1の直線を返すので、座標変換で好きな位置に移動する
- closedはfalseならば点列は閉じていない、trueならば点列は閉じている
  - 閉じていなければ最後の頂点にラウンドキャップが付加される
  - 閉じていれば最後の頂点から最初の頂点への直線が付加される
drawRoundCapLineで線を描く
- 太さの指定は太さのある線、再びと同じ
- attrはprepareRoundCapLineに渡した点列の型を頂点属性の形で示す
  - 変数名はつけず、f3の部分だけ指定する
  - 内部でp1:f3, p2:f3のように展開される
  - デフォルトではf1で、prepareRoundCapLineで生成した直線を描画できる
prepareEquatorRoundCapはprepareRoundCapLineに2次元の点列を渡し、drawEquatorRoundCapはdrawRoundCapLineにf2を渡している
メリット
- 円には方向性がないので、頂点変換後の直線セグメントがスクリーン上で長さ0になってもその場所に円をひとつ描いておけばいい
  - PostScript言語でもそんな仕様になっていて（明記されていて）、PostScript言語で丸い点を打つときに使える
  - というか、むしろPostScript言語のこの仕様を知っていたので思いついた
- この例では方向ベクトル・法線ベクトルの長さが0になり、長さ・太さとも0の直線を描こうとするが、GL側で勝手に捨ててくれる
制限
- この例では分かりやすく半透明にしているが、ポリゴンの重なっている枚数が一定ではないので、半透明にすると濃さに差が出る
- 角の部分はふたつの直線がある角度を持って接しており（そりゃ角だもん）、直線の表示上の幅は同じだが、ジョイントの円に対する直径の方向が異なっているため、ジョイントの円にパースを付けてしまうと、どちらかの直線の端が飛び出す
- ジョイントが真円で表示されるようにした場合、今度は直線側にパースがあると表示がちょっと崩れる: 直線が手前に伸びていれば直線の端の部分にくびれができ、直線が奥に伸びていれば直線と円周が交わるところでくびれができる
- 太い・4分割・半透明にするとわかりやすい
- 線が太いほど目立つので、太い線には向かない

裏表のある話

　ポリゴンの表と裏で表示を変えることができる。

gl.pers

VanillaMat4.pers（クラスメソッド版）を呼び出す
wとhはthis.canvasから自動で埋めてくれる

表の決まり方

gl.TRIANGLESの場合、の絵のように三角形の頂点を結び、それを視点から見た場合に反時計回りに見えるなら、ポリゴンの表が見えている
ということは、時計回りなら裏
gl.TRIANGLE_STRIPの場合、最初の三角形はgl.TRIANGLESと同じになるが、ふたつ目の三角形は逆になる
ひとつ目の三角形の最後の辺がふたつ目の三角形の最初の辺になるが、通常、残りの頂点はこの辺を挟んで反対側になる
3D空間で棒状にするの絵のように、この辺をたどる方向は同じだから、残りの頂点へ行き着く方向はお互いに逆回りになる
このため、gl.TRIANGLE_STRIPの場合、最初の三角形は反時計回りに見える場合が表、次の三角形は時計回りに見える場合が表、その次の三角形は反時計回りに見える場合が表、のように、表に見える回転方向が交互に入れ替わる
今までの説明では出てきていないが、縮退三角形を使う場合に気をつける必要がある

表（おもて）かどうか調べる

フラグメントシェーダーの組み込み変数gl_FrontFacingで分かる
trueならば表が見えている、falseならば裏が見えている
ここでは表ならテクスチャを表示、裏なら固定色で塗りつぶし
マウス（タッチ）で回せるようにしてあるので、めくってみるとよい
普通はテクスチャが裏返しで見える
裏にテクスチャを貼ることもできる

ifの代わりにmix

一般的にシェーダープログラムではifは避けるべきと言われている
gl_FrontFacingをfloatにキャストすると0か1になるため、mix関数の第3引数に渡せば、表が見えている時に第2引数の値が、裏が見えている時に第1引数の値が得られる
なぜifを避けるか？
- シェーダーは複数の頂点やフラグメント（ピクセル）を同時に（並列で）計算している（1024個とか）
- 同時に計算できる数だけシェーダーユニットがあり、基本的にレジスタは独立しているがプログラムとプログラムカウンタは全ユニットで共通
- あるユニットでは条件がtrueだが、隣のユニットではfalseといった場合を考えると、実際にはジャンプできないことが分かる
- ではどうするかというと、then節の後にelse節を並べて書き、ジャンプせずに全部の命令を条件付き実行する
- if節の結果で（ユニットごとに）どちらの節を実際に実行するかが決まり、もう一方は空読み（いわゆるNOP）になる
- if文をネストした場合、外側のif節のフラグを保存しておく必要があり、このフラグは他の制御構造と共用のため、制御構造のネスト深さに制限がある（シェーダー黎明期はアセンブラの仕様も公開されていた、これはGLではなくてMSのHLSLだけれど）
- このため、then節とelse節にちょっとだけ異なる巨大なブロックを書いてしまうと、ふたつのブロックのうち片方はNOP扱いで全部実行するハメになる
- なるべく処理を共通にすればthen節とelse節が小さくなるので、総実行ステップが減る
- ステップ数が減った分だけパフォーマンスが上がる
- 表は複雑な描画、裏は単純な塗りつぶしなら、シェーダー内でgl_FrontFacingで分岐して1回実行するよりも、これまた説明していないが、カリングを設定して裏と表を別々のシェーダーで描画した方が性能が出るんじゃなかろうか（やってないからじっさいのところはわかんない）
- 昔の話だから今の常識は違うかもしれないし、コンパイラが最適化してくれることもあるかもしれない

※次回はいよいよ北はこっち！の予定

09 Sep 2024: applyをaffectに変更

20 Aug 2024: 本編

15 Aug 2024: 予告編