three.jsで遊んでみる（19）

今回は、
輪郭線を見直してみました。

輪郭線を描画するには
Sobelフィルターによる手法や、
頂点を法線方向に少し引き伸ばして裏面描画による手法、
とかがあります。

MMDでは後者の手法を用います。
袖やスカートの内側などのポリゴンが貼られてない部分が
自動的に指定色で描画されることになるので都合が良いのです。

fragmentシェーダでは指定された輪郭色を出力するだけなので、
以降の説明ではvertexシェーダについてのみ、要点を記述します。
thickWeightは輪郭線の太さを調整するためのパラメータです。
GLSLなコードは以下のようになります。
あらかじめ gl.cullFace( gl.FRONT ) しておくことに注意してください。

gl_Position = projectionMatrix * modelViewMatrix * vec4( objectPosition + objectNormal * thickWeight, 1.0 );

上記の実装では、
モデルのobject座標系で頂点を引き伸ばすので、
視点から遠いと輪郭線は細く、近いと太くスケールされます。

一つのやり方としてこれはこれでアリかと思いますが、
視点からの距離に関係なく輪郭線の太さを固定してみたくなったので、
今回やってみた次第です。

ということで、
投影変換後のclip座標系で引き伸ばせば、
たぶんどうにかなるだろうとやってみたんですが、
なんかうまく行かない(^_^;)

ということでググってみたら
こちらを見つけました。
輪郭線描画は「outline shader」って言うようですね。
投影変換後の法線のxとyを使い、
頂点のZ値を乗算することで太さを固定させるようです。
ふむ、なるほど。
GLSLなコードは以下のようになります

varying vec3 vNormal;
vNormal = normalize( normalMatrix * objectNormal );
gl_Position = projectionMatrix * modelViewMatrix * vec4( objectPosition, 1.0 );
vec2 offset;
offset.x = projectionMatrix[0][0] * vNormal.x;
offset.y = projectionMatrix[1][1] * vNormal.y;
gl_Position.xy += offset * gl_Position.z * thickWeight;

がしかし、
モデルを視点から遠近移動させてみると
何故か輪郭線の太さが固定されない。
う～む、何か間違っているのか・・・？

さらにググって調べていたら、こちらを見つけました。
eye座標系でのZ値で太さ補正しないとダメでした(^_^;)
clip座標系でのZ値だと変化がリニアにならないっぽい。

ということでGLSLコードは以下のようになります。

varying vec3 vNormal;
vNormal = normalize( normalMatrix * objectNormal );
gl_Position = modelViewMatrix * vec4( objectPosition, 1.0 );
float depth = -gl_Position.z; // right-handed
gl_Position = projectionMatrix * gl_Position;
vec2 offset;
offset.x = projectionMatrix[0][0] * vNormal.x;
offset.y = projectionMatrix[1][1] * vNormal.y;
gl_Position.xy += offset * depth * thickWeight;

よく調べたら、eye座標系での -z は
clip座標系での w と一致することに気が付きました。
ということで更に以下のように最適化できそうです。

varying vec3 vNormal;
vNormal = normalize( normalMatrix * objectNormal );
gl_Position = projectionMatrix * modelViewMatrix * vec4( objectPosition, 1.0 );
vec2 offset;
offset.x = projectionMatrix[0][0] * vNormal.x;
offset.y = projectionMatrix[1][1] * vNormal.y;
gl_Position.xy += offset * gl_Position.w * thickWeight;

おや？
はじめの z が w になっただけですね。
z を w と間違ったのだろうか？
ん～、これで正しいのかちょっと自信が無くなって来ました(^_^;)
合ってると信じましょう(^_^;)

ところで、
gl_Position は同次座標系での位置 (x,y,z,w) を示しており、
-w ≦ x ≦ w, -w ≦ y ≦ w, -w ≦ z ≦ w という関係になっています。
これを w で割ると、
-1 ≦ x’ ≦ 1, -1 ≦ y’ ≦ 1, -1 ≦ z’ ≦ 1 となり、
１辺の大きさが２の立方体な３次元空間に整理されます。
ちなみにこれを正規化デバイス座標系
（NDC: Normalized Device Coordinates）と呼びます。
clip座標系において w で掛け算しておけば、
NDCにおいて w で割り算されるので、変化ないことになります。
つまり太さ固定という観点ではこれで合っていそうな気がします。

残念ながら、これでもまだ不十分でした
画角(fov)が変わると太さも変化してしまうことが分かりました。
Perspectiveカメラの画角を fov、aspect比を a とします。
さらに tan(fov/2) = V とおくと、
ProjectionMatrix[0][0] = 1/aV
ProjectionMatrix[1][1] = 1/V
となります。
細かい計算については割愛しますが、
こちらやこちらを参考にしています。
したがって画角によらず太さを固定するには、
以下のようにやれば良さそうです。

varying vec3 vNormal;
vNormal = normalize( normalMatrix * objectNormal );
gl_Position = projectionMatrix * modelViewMatrix * vec4( objectPosition, 1.0 );
vec2 offset;
offset.x = vNormal.x * projectionMatrix[0][0];
offset.y = vNormal.y * projectionMatrix[1][1];
gl_Position.xy += offset * gl_Position.w * thickWeight / projectionMatrix[1][1];

さらに以下のように整理できます。

varying vec3 vNormal;
vNormal = normalize( normalMatrix * objectNormal );
gl_Position = projectionMatrix * modelViewMatrix * vec4( objectPosition, 1.0 );
vec2 offset;
offset.x = vNormal.x * projectionMatrix[0][0] / projectionMatrix[1][1];
offset.y = vNormal.y;
gl_Position.xy += offset * gl_Position.w * thickWeight;

ようやく最終形に辿りつけたようです(^_^;)

さて、
最後に thickWeight の決め方ですが・・・

とか以前は書いていたりしましたが、
これは間違っていたようです(^_^;)
NDCにおける大きさ２の高さに対してVHが対応するので、
thickWeight = thickness * 2/VH;
が正しいことになります。
なんか思い違いして逆数の0.5にしてしまっていたようです。
以前と比べたら４倍も違うことになってしまいますね。
なんで気づかなかったんだろ(^_^;)

ということで、
輪郭線の太さを固定させた結果はこちらです。
太さは２ピクセルに設定してみました。
輪郭線の太さが変わらないので、
モデルを視点に対して遠近移動させると、
相対的に輪郭線の太さが変わったように感じますが、
それは錯覚です(^_^;)

ところで、
いまだに十分うまく行ってない影の件ですが、
bias値というのをいじってみたら少し改善したような気がします。
このパラメータの存在には気づいていたのですが、
影響はないんじゃないかと思い込んでしまっていました。

カリング無しで深度マップを作るのは、
裏面描画にくらべて描画量が増えることもあり、
好ましくないのではと思っていましたが、
こちらを見るとそうでもないようです。
「両面シャドウ」とか言うっぽい。
実はbiasの方がより重要だったのかも・・・。
う～む、まだ理解不足ですね。

ちなみに、
biasを掛けないとこちらにあるようなモアレみたいのが出てしまうようです。
ただ適正なbias値を求める手法は調べても見つからなかったので、
（そもそも無いのかも？）
手動で調整するしかないようです。