タグ: サーフェイス

LightWaveで二次元キャラ系人物モデリング奮闘記 ―視線コントロール編―

最終更新：2017/01/13

視線コントロールには、一般には目の中心軸の延長線上に視線用ターゲット・オブジェクトを配置し、両目からそれを参照させてIKを用いて視線をコントロールする。IKを使いたい場合は目を球状のオブジェクトとしてモデリングする必要があり、扁平な顔が基本の二次元イラストやアニメ調の作風にはなかなか合わせにくい傾向がある。劇画調を目指している場合を除き、IKを使いたいがために眼球がちゃんとはまるようにするには、顔のモデリングに必要な工夫の労力が釣り合わないことが多い。

そこで、瞳の動きにはモーフを使いながら、擬似的にIKのような視線コントロールを実現する方法を考える。

瞳の後退モーフによるカメラ目線

カメラ目線を実現するには、MMDなどでよく使われている方法を使う。MMD方式のカメラ目線は簡単に言うと、目の位置を後退させて、三次元的に瞳の中心をずらすことによって擬似的にカメラ目線になっているように見せる。

これまでは白目を自己発光させて陰影が出ないように設定していたけど、まぶたに白目が透けてしまったりする問題があったため、自己発光度を0%に変更し、拡散レベルを400%という非常に大きい値にすることで陰影を極力落とす。

目を後退させると、眼窩の内側が見えてしまうので、内側を白に染めて目の後退がわかりにくいような仕組みを作る。内側を自己発光度の設定してある白に染めてしまうと、目を閉じても内側が透けて見えてしまう。上のサーフェース設定はその対策でもある。

逆に、瞳の中心は目を後退させることでライトの光線が届かなくなり、徐々に暗くなっていってしまうので、自己発光度を「40%」に設定する。拡散レベルは「60%」に設定し、自己発光度と拡散レベルの合計が100%になるように設定すると、自己発光度を設定していなかった場合と色合いがあまり変わらないようにできる。

目の後退によるカメラ目線の例が次の画像。白目と眼窩の内側の境界がわからないようにunReal Xtreme2のToon Tracerピクセルフィルター・プラグインの設定を変更しておく。

上の画像だけではカメラ目線になっているかどうかが少しわかりにくいので、俯瞰構図と仰視構図も示しておく。いずれもモーフ量は同じで、瞳の位置を後ろに下げただけ。カメラの位置を上下に動かしても瞳はカメラの方を向いているように見える。

エクスプレッションによる視線コントロール

眼を独立した球状オブジェクトとして作成しなかったので、視線の制御にIKを使えない。二次元キャラクターの目を球体として作成しようとする場合に発生しうる問題は以前にも述べたとおりで、瞳は水平、垂直の二軸のみで動くようにデザインしている。

モーフを使っている場合でも、グラフ編集に用意されていている「Channel Follower」モディファイヤを使用すれば、ターゲット・オブジェクトの特定のチャンネルの値の変動にモーフを連動させる簡易的な視線コントロールはできる。ただ、ターゲットの距離などを考慮して左右のモーフ量を個別に制御できないので、両目をひとつのターゲットで制御するのは容易くない。

ただし、Channel Followerをモーフのグラフ（エンベロープ）に適用する場合に限り、X、Y、Zの座標系チャンネルだけにしか追随させられない。H、P、Bの回転系チャンネルに追随させようとしても不可解な値が返されてしまい（特定のチャンネルだけまともな数値が出ることもあるけど、ほとんどの場合、0に限りなく近い極小の値になる）、サインカーブのような動きをさせることはできない。モーフは線形補間なので、ある意味当たり前と言えば当たり前なんだけど、Channel Followerで連動する要素に回転系のチャンネルを指定してもエラーも警告も出ないので、設定か計算の間違いだと勘違いしやすい。

そうかと言って、どこか一点を注視するような視線をモーフのスライダーだけで実現するのは楽ではない。アニメーションさせることを考えに入れたりすると、キーフレームごとにモーフ量を計算するか、その都度目分量で調整しなければならず、かなり労力がかかりそうなことは想像に難くない。

そこで、注視している場所を大雑把に指示するターゲット・オブジェクトを用意して、モーフ適用量を計算させる。視線コントロールの基本的な考え方は次の図のとおり。IKでも考え方そのものは同じ。

この図から、目の正面方向と注視点に対する方向がなす角度 $\theta$ についてのタンジェントは次のとおりに求められる。

$\begin{align*} \tan \theta&=\frac{X_{sight} - X_{eye}}{Z_{sight} - Z_{eye}} \end{align*}$

タンジェントの逆関数インバース・タンジェント（又はアークタンジェント）を用いて $\theta$ を求める。

$\begin{align*} \theta &= \tan^{-1} \frac{X_{sight} - X_{eye}}{Z_{sight} - Z_{eye}} \end{align*}$

これをLightWaveで受け付けられるエクスプレッションに置き換える。プログラミング言語ではインバース・タンジェント（アークタンジェント）を「atan」などと記述することが多い。次の式は左目のエクスプレッションの例。名称は左右の区別がつきやすく、わかりやすければなんでもいい。

式の出力はラジアンではなく、関数電卓などで「DEG」と表される円周360°の角度なので、 $0^\circ \leq \theta \leq 90^\circ$ の範囲の値をとる。必要であれば、これに定数を掛けて調整する。

atan(([Null_EyeSight.Position.X] - [Null_Eye_L.Position.X]) / ([Null_Eye_L.Position.Z] - [Null_EyeSight.Position.Z]))

エクスプレッションと、グラフで表されるチャンネルはそれぞれ独立していて、一義に定まる名称で識別されるエクスプレッションを複数のチャンネルに割り当てられるようになっている。そのため、最初は左目用のエクスプレッションを右目のチャンネルにも割り当ててしまったり、重複したエクスプレッションの除去に手間取ったり、インターフェースにとっつきにくさを感じるかもしれない。

同じく次の式は右目のエクスプレッションの例。右目のX座標は左目の正負反転なので、参照するチャンネルが異なるだけで式はほぼ同じ。両目とも瞳を顔の外側に動かすほうをモーフ量のプラスにしている場合は、全体をマイナスで正負を反転する。

atan(([Null_EyeSight.Position.X] - [Null_Eye_R.Position.X]) / ([Null_Eye_R.Position.Z] - [Null_EyeSight.Position.Z]))

それぞれの目のモーフにエクスプレッションを適用（アタッチ）し、両目のグラフを同時に表示させると次の画像のようになる。注視ターゲット・オブジェクトは $-1m \leq X_{sight} \leq 1m$ の範囲で行ったり来たりさせているだけ。Z軸座標は目から約1m先に固定で、注視距離によって必要があれば移動させる。 $Z_{sight}$ を移動させるとグラフの振幅が変動する。

ターゲット・オブジェクトを注視させた場合と、スライダーで視線を手動設定した場合の比較。ターゲット・オブジェクトとは言うものの、上の式では精密に注視させることはできないので、あくまでも擬似的な制御。IKではないのでモーフ量と視線の角度を完全に同期させるにはエクスプレッションを更に作り込む必要がある。

morph038 — 両目ともモーフ適用量「100%」。視線は交わらずに平行になっている。

morph037 — エクスプレッションで視線コントロールをしたもの。左目のモーフ量は「88.78%」、右目は「66.20%」。

今回は水平方向のモーフしか使っていないけど、同様に上下方向のモーフを作っておけば、理屈はまったく同じで瞳の上下運動も可能。

LightWaveで二次元キャラ系人物モデリング奮闘記 ―プリーツスカート編―

最終更新：2017/01/13

今回はプリーツスカートがテーマ。なんとなくそれらしい形のものを作るのは簡単なので、学生の制服やアイドルユニットのお揃いの衣装などでお馴染みのチェック柄のスカートを作る。チェック柄なんて珍しくもないけど、チェック柄を甘く見てはいけない。

3DCG隆盛の昨今でも、チェック柄のスカートを身にまとった美少女キャラクターの3Dモデルというのは驚くほど見かけない。まず考えられる理由としては、UVマップに格子状に展開したチェック柄を歪ませないように維持したままスカートをモデリングするのが難しいからというのが挙げられる。単純に裾を広く、ウェストを細くすると上に行くほど柄が細くなってしまい、不自然になってしまう。

仮に、モデルを単純化してテクスチャの描き方を工夫するにしても、放射状に広がる裾に合わせてチェック柄を描くのは、柄の連続性をどうやって担保するのかといった問題も含め、控えめに言っても労力がかかる。立体化を前提、想定、又は期待してキャラクターデザインをする場合、チェック柄のスカートは全般的に避けられる傾向にある。現実世界では街に出ればチェック柄のスカートばかりが目立つのに、二次元世界では学園物の作品でも制服のプリーツスカートにチェック柄を採用している学校のほうが珍しい。もっとも、立体化の前にアニメ化やコミカライズといった二次元化があり、単純に描くのが面倒という現実的な問題もある。

また、プリーツスカートの縫製の特殊性にも理由がある。縫い目を切り離して展開してみると、大抵の人が想像するような扇形や台形の生地ではなく、実は長方形の布1枚でできている。それを末広がりの独特のラインに仕立てるために、「曲線折り」という特殊な折り方を採用している。ウェストが細くなるようにまっすぐに折るといずれチェック柄が斜めに傾いていってしまうのを避けられない。

本物の布や折り紙であれば基本的に伸び縮みはないので、順序よく折り目をつけていけば自然にプリーツスカートの形になっていくんだけど、3Dモデリングの場合、ポイントを移動させるとエッジがいくらでも伸縮してしまう特性があるため、エッジの長さを固定したまま折り畳むという操作がそもそも難しい。

そのプリーツスカートを現実のものとほぼ同様の発想でモデリングすることにあえて挑戦する。挑戦しないのであれば、わざわざ記事にする必要はない。例によって拡張プラスと移動ツールでモデリングしていく方法を今更紹介されても「またその組み合わせ？」と言われかねない。

基礎を作る

それでも、3DCGソフトウェアの制限には逆らえないので、まずはセオリーどおり円筒から作る。ディスク（Disc）ツールで原点に直径1m、高さ1mの標準的な大きさの筒を作る。これからややこしい計算をすることになるので、初期座標くらいは単純にしておきたい。

ひだの数があまり多いと作業が大変だし、逆に少なすぎるとプリーツスカートとは呼べなくなるので、15個とした。折り返し分を計算に入れて30面の円筒を作る。15という数字は、1周分の360°を割り切れるから。ついでに言うと、UVは幅が100%（LightWaveの内部では1.0 = 1m = 100%は等価）なので、100と360の公約数だと更に計算しやすい。とは言うものの、100と360の公約数は1、2、4、5、10、20の6つしかなく、実質10か20しか選択肢がない。

上面と底面は必要ないので、削除する。大抵要らなくなるので、「上面と底面をふさがない」というオプションがあれば便利なんだけど、些細なことなので文句を言っていても始まらない。

サーフェースがデフォルトのままだと何かと不便なので、次の画像のように「Skirt_Check」というサーフェースを割り当てておく。

とりあえず、スムージングはかけないでおく。

早々にUVマップを作成する。極めて単純な形状のオブジェクトなので、標準機能の新規UVテクスチャ（New UV Map）ツールで円柱状に展開する。今回の目標はUVマップを基準にしてモデリングのほうを工夫することなので、手芸店などで計り売りされている1枚布のようなマップが必要。

なお、プリーツの数が4で割り切れるのであれば、4分の1だけモデリングしてあとは90°ずつ回転させて複製し、境界線をつなぎ合わせればモデリングの労力をほぼ4分の1にできる。ただ、その場合のUVは4箇所とも同じ位置に重複してマッピングされることになるので、UVの扱いに慣れていて混乱しない自信があれば試してみてもいいかもしれない。それから、モデリングを済ませてしまってからUVを展開してももちろんいいんだけど、plg_Make_UV_Editなどによる自動展開は多少なりとも歪むので、UVの調整にそれなりに時間を要する。プリーツを折り畳んでしまってからLightWaveの標準機能によるUV展開は使えないと思っていい。

次の画像のような簾状のマップを作る。

更に、作成したUVにチェック柄のテクスチャを割り当てる。モデリングの説明が思いのほか長くなりそうなので、チェック柄のテクスチャの作り方はまた今度説明する。Adobe Photoshopのスマートオブジェクトはチェック柄の変更や修正に柔軟に対応できて便利なので一番おすすめではあるんだけど、レイヤーが扱えて標準的なレイヤーモードを備えている画像編集ソフトウェアであれば簡単に作れる。

次の画像の状態が基準になる。以後、この模様が歪まないように工夫を凝らしていく。

すべての面の幅が一定ではプリーツスカートにならないので、折り返す部分を短くする。次の画像のようにUVマップのビューでひとつおきにポイントを選択する。三面図の上面からのビューで選択しても同じだけど、チェック柄の連続性を維持するためにはマップの左右端にあたるポイントは間違っても動かせないので、UVマップ内で選択したほうが結果的には手早く済む。

スカートのデザインにもよるんだけど、ひだの表側に見えている部分と折り返し部分の比率は4:1にすることにした。ひだの数は15個で、現在5:5になっている比率を8:2にしたいので、 $100 \div 15 \times 0.3 = 2 \, [\%]$ だけUVのU成分をずらす。UV値の変換（Transform UV）ツールで次の画像のとおりに入力する。

「OK」ボタンを押すと、次の画像のようにUVマップが変換される。

UVマップを変換しただけなので、三次元空間の筒の形状には変化がないけど、チェック柄が歪んでいるのが確認できる。

ポイントの選択を解除しないようにして、今度は三次元空間のポイントを $360 \div 15 \times 0.3 = 7.2 \, [^\circ]$ だけ回転させる。正負の方向はUVの歪みを見て判断する。

正しい方向に回転させられれば、テクスチャの見た目上は最初の状態に戻る。これでプリーツスカートを作る準備ができた。チェック柄のパターンは15×15なので縦方向が圧縮されて縦横比が一致していないけど、この段階では横方向の模様が歪んでいなければいい。

アポロニウスの円

ここからが本題。ひとつのひだを4:1に分割したまでは良かったんだけど、その比率を維持しながら折り返すのが結構難しい。比率さえ維持できていればUVを歪ませずに済むので、この際長さは変わってしまってもいい。

ここで久しぶりに数学らしい数学を利用する。

2つの点 $A$ と $B$ からの距離の比が $m:n\; (m \neq n)$ で一定である点 $P$ が描く軌跡を求めたい。結論から先に言うと、その軌跡 $P$ は円になるんだけど、その円の中心点を $C$ とする。各点はXとYの成分を持っているので、それぞれ $A(\alpha), B(\beta), C(\gamma)$ とする。

$C$ 点の座標 $\gamma$ は、次の式で求める。要は、X座標とY座標をそれぞれ別に同じ式で計算するということ。

$\begin{align*} \gamma=\frac{\displaystyle -n^2\alpha+m^2\beta}{\displaystyle m^2-n^2} \end{align*}$

$C$ 点の座標が求まれば $A$ 点と $B$ 点との距離は三平方の定理で求められるけど、今は試験問題を解いているわけではないので、ポイントの計測（Measure Points）ツールを使って簡単に求める。

線分 $AC$ と $BC$ の距離が求まれば、点 $C$ を中心とする円 $P$ の半径 $r$ は次の式で求められる。

$\begin{align*} r=\sqrt{{AC} \cdot {BC}} \end{align*}$

計算と作図がしやすいように、 $B$ 点が $(X,Z)=(-0.5,0)$ の位置にあるところを選んだ。これらの式から求めた数値をディスクツールの数値入力ウィンドウに入力する。座標を参照するだけなので高さは0でいい。サイドが36なのは言うまでもなく、10°刻みにするため。

計算が合っていれば4:1の折り目で分割しているポイントを通過する円が描けるはず。実際に作図してみると思ったより半径は小さかった。精度としては4.006:1～3.995:1くらいだから誤差±0.16%前後。

このような円をアポロニウスの円と言う。一般的には次の画像のような図で表される。図は $m:n = 3:2$ になっている。 $A$ 点と $B$ 点が水平に一列になっていたほうが理解しやすいのでこのように描くけど、二次元的に斜めにずれていても円の位置と半径は求められる。図を見るとわかるように、比率が一定になるだけで長さまでは一定にならないことに注意。

なんでこのような式になるのかまでは省略。ネットで「アポロニウスの円」を検索すれば高校の先生が詳しく証明してくれているページがたくさんある。つまり、まったく憶えてはいないけど高校の数学で習ったはずで、センター試験にも出題されるポピュラーな平面幾何学の定理。更に発展させた複素数平面を使った解法は2004年（平成16年）を最後に今の高校では教えていないらしいけど、コンピュータの発達した21世紀に生きる私がすぐには思いつかなかった方法を紀元前の数学者が既に考案していたというのだからまったく皮肉なことだ。

ある平面上で線分 $AP$ と $BP$ の比率を一定にしたまま分割点 $P$ を移動させたいという要求はありそうだけど、Adobe Illustratorのようなベクター画像編集ソフトウェアのツールにも意外と備えられていない。少し調べたところでは、Illustratorでもアポロニウスの円を描いてその円の外縁にスナップするようにパスの制御点を移動させるという方法が採られているようだ。

こんな手間のかかる計算までしなくてもいいのでは、と言われそうだけど、アポロニウスの円は平面上にある2点についてしか通用しないものなので、今使わないと使う機会がなくなる。それに、いつも「適当に、感覚で」と繰り返すのでは何の参考にもならない。それほど厳密でなくても良ければ、ひだの角度を直角と仮定して三角関数の正接（ $\tan \theta$ ）が0.25になるおおよその位置を求める方法もある（あくまでも仮定なので、実際に操作すると直角にはならないため、無視できないほどの誤差が出る）。

$A$ 点と $B$ 点の間の分割点を選択し、スナップドラッグ（Snap Drag）ツール（Shift+G）でアポロニウスの円上にある任意の点にスナップさせる。この時、「操作ビューに沿う」にチェックを入れておかないと水平に動いてくれないので注意。

次の画像のように、4:1の比率を維持したまま折り返すことができた。

15個あるひだの数だけアポロニウスの円を作るのはさすがに大変なので、スカート全体を15分の1、つまり24°ずつ回転させて、スナップドラッグを繰り返す。原点を中心にしてアポロニウスの円をスカートの外縁を周回させても同じだけど、円周率が無理数であるために回転は誤差が蓄積しやすいツールなので、変形の基準にするものはできるだけ移動させたくない。

15個のひだを折り返し終わった状態が次の画像。ここでウェスト部分を絞ってしまうと、冒頭でも書いたようにチェック柄が先細りしてしまう。

縦横の模様を合わせる

ここでチェック柄の縦の模様を横の模様に一致させる。ひとつのひだの長さは既にわかっているので、それを15倍すると裾の周囲の長さが求められる。結果、4.4306205mと求まり、スカートの丈の長さは1mなので、裾の周囲に対する割合は $22.5702 \dots \, [\%]$ となる。

上端のポイントを選択し、これをUV値の設定（Set UV Value）ツールでUVのV成分に入力する。

上を下に移動させたほうが計算が楽なのでそうしたけど、下を上に移動させても結果は同じ。

上の画像と見比べてもらえば、チェック柄の縦横比が合っているのがわかると思う。

曲線折りの模擬

次はいよいよ曲線折りを行っていく。まず、ウェストに向かって絞りたい部分を分割する。全体を半分に分割し、上半分をさらに半分に分割する。

この時、必ずバンドソープロ（Band Saw Pro）を使う。まだ単純な形状なのでナイフツールを使ってもいいような気もするし、一見すると似たような動作ではあるけど、ナイフツールはUVを壊してしまうことがある。バンドソープロが優れているところは、どんなに入り組んでいようと、ポリゴンが連続さえしていれば正確に分割できることばかりではなく、UVを破損させることがない点。

次の画像のように3分割した。

分割点をひとつのひだの10%分だけ左にずらしていく。ひとつのひだのUVにおける幅は15分の1、つまり $6.666 \dots \, [\%]$ なので、その10分の1をUV値の変換ウィンドウに入力する。

裾側から順に、 $8:2(=4:1)$ 、 $7:3$ 、 $6:4(=3:2)$ 、 $5:5(=1:1)$ になっている。

すべての段の折り目について、アポロニウスの円を作図するのがもっとも正確な方法なんだけど、 $(x_A,y_A)=(0,0)$ 、 $(x_B,y_B)=(1,0)$ として単純化してみて気が付いたことがある。

分割点が $A$ 点と $B$ 点からの距離の比が $8:2$ の時、アポロニウスの円の半径は次のように求められる。

$\begin{align*} x_C&=\frac{\displaystyle -2^2x_A+8^2x_B}{\displaystyle 8^2-2^2}=\frac{\displaystyle 16}{\displaystyle 15}\\ r&=\sqrt{x_C \times (x_C - x_B)}=\sqrt{\frac{\displaystyle 16}{\displaystyle 15} \times \left(\frac{\displaystyle 16}{\displaystyle 15}-1\right)}\\ &=\sqrt{\frac{\displaystyle 16}{\displaystyle 15}}=0.2666 \dots \end{align*}$

同様に、 $7:3$ の場合は次のとおり。

$\begin{align*} x_C&=\frac{\displaystyle -3^2x_A+7^2x_B}{\displaystyle 7^2-3^2}=\frac{\displaystyle 49}{\displaystyle 40}\\ r&=\sqrt{x_C \times (x_C - x_B)}=\sqrt{\frac{\displaystyle 49}{\displaystyle 40} \times \left(\frac{\displaystyle 49}{\displaystyle 40}-1\right)}\\ &=\sqrt{\frac{\displaystyle 441}{\displaystyle 1600}}=0.525 \end{align*}$

同、 $6:4$ の場合は次のとおり。

$\begin{align*} x_C&=\frac{\displaystyle -4^2x_A+6^2x_B}{\displaystyle 6^2-4^2}=\frac{\displaystyle 9}{\displaystyle 5}\\ r&=\sqrt{x_C \times (x_C - x_B)}=\sqrt{\frac{\displaystyle 9}{\displaystyle 5} \times \left(\frac{\displaystyle 9}{\displaystyle 5}-1\right)}\\ &=\sqrt{\frac{\displaystyle 36}{\displaystyle 25}}=1.2 \end{align*}$

つまり、ものすごくざっくりではあるけど、比率が1割変動するたびに半径は約2倍になっている。半径の計算に平方根を使っていることに多分関係がある。円の中心点 $C$ は移動するので単純に2倍では本当はダメなんだけど、同じ作業を60回繰り返すのはちょっと辛いので、ある程度は近似できるということも併記しておく。

なお、 $5:5$ の場合は $m=n$ なので、 $m^2-n^2$ は0になってしまい、計算できなくなる。分割点がちょうど中間の場合は、点 $A$ 、点 $B$ 及び点 $P$ をつなぐ三角形は二等辺三角形になり、点 $P$ の軌跡は直線になる。つまり、アポロニウスの円の半径は無限大になり、円にならないということ。とは言え、計算できないと座標が求められないので、 $6:4$ の場合の更に2倍と仮定して求める。

ひだの短いほうのエッジを選択し、ストレッチ（Stretch）ツール（Hキー）の中心点は $(X,Z)=(-0.5,0)$ に固定、下から順に200%、400%、800%まで内側に向かって拡大する。

ウェストの絞り込み

最後に、ウェストに向かって細くなるように各段のエッジを1周分選択して縮小する。冒頭で「ウェストに向かって絞ったらプリーツスカートの意味がない」と言っていたことと矛盾するように感じるかもしれないけど、これまでの操作で上の段に行くほどプリーツの幅は広くなっているので、最後に帳尻合わせのために縮小しなければならない。エッジの長さを固定して折り畳めないならば、一度広げてから縮小して元のスケールに戻すという発想。

裾から数えて2段目の設定。裾のひだの長いほうのエッジが8に対して7なので87.5%と求めた。

裾から数えて3段目の設定。裾のひだの長いほうのエッジが8に対して6なので75.0%と求めた。

裾から数えて4段目、つまり上端の設定。裾のひだの長いほうのエッジが8に対して5なので62.5%と求めた。

拡大してよく見てもらえればわかると思うけど、折り返し部分も含めた裾の長さの総計に対し、上の段の長さは必ずしも一定ではない。プリーツの表側と折り返し部分の比率はほぼ計算どおりなので、折り返しの角度が深すぎるために長くなってしまっている。

基本版完成

以上の操作がすべて完了してできあがったのが次の画像のようなモデル。水車のような形にはなっているけど、とてもではないけどお世辞にもスカートのようには見えない。

ところが、これにサブパッチ（キャトマル）をかけると、不思議なことにかなりそれらしいプリーツスカートに早変わりする。チェック柄もそれほど大きくは歪んでいない。見直す余地はまだあるけど、方向性は間違っていないことが確認できた。

最後に、アポロニウスの円を各段ごとに作成したという証拠物件。後でどうしても正確を期したくなった場合に再利用する。これらの円を使って作業している途中で円の半径が比率の2乗にほぼ比例することに気が付いた。

途中経過

作業のしやすさを重視して単位長（1メートル）の範囲内でモデリングしていたので、実際のモデルに着せるには大きさを全体的に拡大し、ウェストの位置とサイズに合うように調整する。あとは、多少脚がはみ出していても、物理演算でなんとかできる。

ClothFXを次の画像のように設定する。構造維持（Hold Structure）は「100」くらいにしておかないと体のラインに合うように変形してくれないのであまり上げすぎないほうがいい。一方、粘性（Viscosity）と抵抗（Resistance）をそこそこの数値にしておかないと、スカートの形状がなかなか落ち着いてくれないし、わざわざ計算までして比率を揃えたプリーツが不規則に歪むのを抑制できない。

ちょっと短かったけど、いつものモデルに着せてみるとこんな感じ。

チェック柄を解除して無地にするとこんな感じ。ウェストの余裕を厳しくしすぎたために、スカート右側の一部のプリーツがモデルに貫通してしまっている。上の画像でも同様の現象は起きているんだけど、柄がなくなったので目立ってしまった。

参考記事

「プリーツスカートの展開面は長方形」という驚きの事実を再確認すべく、プリーツスカート折り紙を作る。曲線折紙はほんと面白い（まんがは「制服の幾何学」より） pic.twitter.com/lDPrQN6ApY

— こーわ (@kowa) 2016年5月4日

LightWaveで二次元キャラ系人物モデリング奮闘記 ―まつ毛編―

最終更新：2016/09/06

今回はまつ毛のモデリング。まつ毛の話は最初のほうの顔のモデリングで少ししたけど、最終的にモデリングで作るのか、テクスチャで描くのかを決めずに仮設のまま放置していた。大幅に順序が前後するけど、瞳をすり鉢状にしてディテールを改善したことだし、まつ毛もモデリングで作ることに決め、ここで詰めていくことにする。

ボーン・ウェイトの記事でも少し触れたけど、ここでウェイト・マップを応用したサーフェースのパラメータ調整にも挑戦してみる。

頭の連続したポリゴンだけを取り出すと、現状は次の画像のようになっている。ちなみに、頬の紫色と首の赤色のスケッチ色は「法線の折り目」検出を使わずに顎のラインの境界線をunReal Xtreme2に確実に認識させるためのもの。

まつ毛のモデリング

まずは仮設のまつ毛の黒いポリゴンをすべて削除し、次の画像のようにまつ毛の裏打ちとして残しておいた眼窩の周囲のポリゴンを選択する。細かい部分なのでサブパッチは一時解除しておいたほうが作業しやすい。対称モード（Shift+Y）にしておくと左目のモデリングと同時に右目のモデリングも同時に進む。後頭部がガタガタなのはこの際気にしないで欲しい。

例によって拡張プラス（Eキー）でポリゴンを追加し、次の画像のように必要な分だけ前に押し出す。具体的には16mmだったけど、顔のスケールが1m以上あるのでほんの1～2%程度の範囲。

まつ毛用のサーフェースは既に作成済みなので、どこからどこまでがまつ毛なのかわかりやすいように仮設のまつ毛に使っていた色を着けておく。

まつ毛を伸ばしたい側面のポリゴンを選択し、拡張プラスと移動ツールで拡張する。この時点でまつ毛の先端は顔から離れることになる。

拡張したポリゴンの上下、前後のポイントを次の画像のように中央の1点に集約させる。スナップドラッグツール（Shift+G）を使ってもいいし、目標のポイントを中心にして拡大縮小ツール（Shift+H）を使って0%まで縮小してもいいし、ポイント情報で座標を直接入力してもいい。ポイントを結合してしまうとまつ毛の先が尖らなくなってしまうので、例によってポイントは結合しない。

ポイントを結合しないと気持ち悪いということであれば、サブパッチの場合はサブパッチ・ウェイト、キャトマルの場合はエッジ・ウェイトを使って尖らせる。ポイントを結合した場合は線ポリゴンが一定数できるので、忘れずに削除しておく。なお、ポイント結合時に限り対称モードを解除しておかないと左右のまつ毛がつながってしまうのでその点だけ注意。髪の毛と異なり、まつ毛の場合は尖らせたい箇所が数えられるほどしかないので、ウェイトを使うのも手ではある。

まつ毛の目尻側の下端が眼窩の外側のポリゴンのエッジにも接続していると目を綺麗に囲んでくれないことが判明したので、ポイントの結合を解除（Ctrl+U）し、眼窩の内側に接続し直した。その際、まつ毛の裏側にあたる顔側のポリゴンがひとつ不足するため、ポリゴン作成（Pキー）で三角形のポリゴンを追加した。

対称モードを適切に使用してモデリングしていれば、左目のまつ毛が完成する頃には右目のまつ毛も概ねできあがっているはず。まつ毛の眼窩の内側への接続し直しとポリゴンの追加だけは左右を個別にやらないといけないので若干効率が悪いけど、テクスチャを使わないことに決めたのだから、そのくらいの手間は惜しんではいけないのかもしれない。

ウェイト・マップを応用した色調調整

これで終わってしまうとただの作業記録になってしまうので（ブログだから別にそれでもいいのかもしれないけど）、ちょっと新しいことをする。

まつ毛の目頭側の下端がくっきりしすぎているので、少しぼかしたい。モデリングで短くすることも考えたんだけど、パッチ単位でしか短くできないので、大幅に短くなってしまう。そこで、ボーン・ウェイトとは無関係のウェイト・マップを活用する。

新規ウェイト（Weight Map）で「Cilia_Weight」という名称のウェイト・マップを追加する。

目頭側のポイントに外側から順に「100%」、「50%」のウェイト値を設定する。

モデラーのプレビューではウェイト・マップの効果を確認できないので、レイアウトでサーフェースの詳細を設定する。色のテクスチャ設定でグラディエント・マップを選択し、次の画像のように50%のキーから100%に向かって肌色になるようにグラデーションを設定する。

かなり微妙ではあるけど、目頭側の色調が若干ぼやけた。もう少し研究が必要そうだけど、やろうとしたことはわかるのではないかと思う。

途中経過

遠景にするとウェイト・マップによる色調調整はほとんどわからなくなってしまうけど、まつ毛が増量されて目力が更に増し、顔の情報量が増えてきた。そうすると、今度は首から下の情報量の少なさが気になってくる。

LightWaveで二次元キャラ系人物モデリング奮闘記 ―瞳編―

最終更新：2016/09/06

ここでちょっと脱線。これまで瞳にはUVを使わずに平面状にテクスチャ・マップを貼り付けていた。二次元キャラクター風の3DCGモデルを作りたい場合、目は平面か若干凹ませるくらいで造るというのは前の記事でも書いたけど、それを更に進め、瞳をすり鉢状に造型してハイライトと陰影をコントロールすると同時に視線の方向をわかりやすくする。

この手法は本来、設置されている環境の光源によって見え方に影響を受けるフィギュアの造型に関するものなんだけど、3DCGにも応用できるのではないかと思い、以前から試してみたいと思っていた。

概念図

基本的な考え方を簡単な図に示す。次の画像のような平面状の目の場合、斜めから見ても光の加減に関係なく単純に斜めに見えるだけなので、ハイライトや陰影といった視覚情報をテクスチャにあらかじめ描き込んでおく必要がある。また、視線がどこを向いているのかわかりにくい傾向がある。

一方、次の画像のようなすり鉢状の目の場合、斜めから見ると光の加減でハイライトや陰影が生じるため単色のサーフェースでも情報量が多くなる。また、瞳の中心が左右どちらかに圧縮して見えるので視線がどちらへ向いているのか想像しやすい。

なお、念のため前置きしておくけど、本記事は平面状の目に対してテクスチャ・マップを貼る手法を否定するものではない。あくまでも個人的好奇心と実験的要素が大きい。

平面状の目のテクスチャ・マップ

現状、目のモデルは次の画像のようになっている。

斜めにすると次の画像のように見える。これでも問題ないと言えば問題ないんだけど、どの方向から見ても陰影に変化がなく、立体的にも変わり映えがしない。

テクスチャ画像には次の画像を使用しており、元はInkscapeでベクター画像として作成したものをPNG画像としてエクスポートしたもの。目に落ちている影も一応描き込んであるものの、目の形状の都合でほとんど見えていない。

テクスチャ画像は円形だけど、目のサイズに合うようにX軸方向とY軸方向のスケールを調整して貼り付けている。

すり鉢状の目のモデリング

ボックスをメタフォームで細分化して球状に形成していってもいいんだけど、すり鉢状にしていくことを考えるとボールから作ったほうが良さそうだったので、ボールから作る。「サイド」は顔側の形状に合わせて8面にした。「分割数」は少し多めに12とした。多すぎる場合はバンドグル（Band Glue）で整理すればいい。

目は概ねZ軸方向を向いているので、ボールの中心軸をZ軸方向に向ける。

サブパッチを適用し、前に出っ張っているほうをZ軸に反転（Flip It）させて、瞳の前縁くらいまで移動させる。ポリゴンが裏返ってしまうので、法線を反転（Fキー）させる。黒く見える線は背景レイヤー。テクスチャ・マップで作った平面状の目の大体の位置と大きさを把握するためのもの。

瞳の内側にあたるエッジやポイントをループ選択（Select Loop）などで円環状に選択し前後に移動させ、拡大縮小（Size）ツール（Shift+H）で凸部分の大きさを調整しながら起伏を増やして造型していく。瞳の中心を一番暗くしたい場合は光が差し込まないように更にもう一段深くする。すり鉢の角度をあまり深くしすぎて瞳の中心が見えなくなってしまっては本末転倒なので、最大でも45°が限度といったところだろう。

サブパッチがかかっていると鋭角のエッジは想像よりも鈍りやすく段差の高さを調整しづらいので、折り返し箇所が苦しくなってきたら拡張プラス（Eキー）で平面の段を追加する。円形だからバンドグルによるポリゴンの再統合も容易なので、とりあえず一段分割してみてから考えてもいいと思う。

瞳の造型が大体できたら、眼窩の形に合うように白目の部分を形成する。平面状の目を先に作っていたので、それを構成するポイントを利用し、スナップドラッグ（Snap）ツール（Shift+G）で合わせた。スナップドラッグはポイントの結合はしないので、単純に既存のポイントに位置合わせをしたい時に便利。

最初からすり鉢状の目を作る場合は、ポリゴン数が単純に多いので瞳の位置や向き、白目の面積の調整に苦労するかもしれない。瞳に平面状テクスチャを使っていればレイアウトでも位置や大きさの微調整はできるけど、モデリングで瞳を作った場合はレイアウトでの調整は困難になる。

また、中心軸がZ軸方向に完全に平行なすり鉢状では横から見た時に瞳がまったく見えなかったり、不自然に出っ張っているように見えることもあるので、移動ツールで瞳の左右外縁を後ろに押して歪ませたり、瞳の正面方向を維持しつつ横からも見えるように斜体（Shear）ツール（[キー）で加工する必要がある。ニュートラルな視線を正面に向けたい場合でも、やや寄り目くらいに調整しておかないとレイアウトに持って行った時に左右の視線がヒラメのように外向きに開いて見える。

何の目安もなく感覚でモデリングするのは結構難しいので、参照用に眼窩の形や向きがわかるような適当なポリゴンを作っておいてそれを背景レイヤーに敷いてモデリングすると少し楽になる。

瞳の幅をストレッチ（Scale）ツール（Hキー）で80%くらいまで縮小し、ハイライトにあたるボックスを追加する。

ハイライトのボックスを選択し、細分化（Subdivide）ツール（Shift+D）の「メタフォーム」で分割する。1回で十分だと思うけど、もっと球状に近くしたい場合は更に分割する。

完成したすり鉢状の目が次の画像。右目は鏡面X（Mirror X）で作るけど、一般的に二次元キャラクターのハイライトは左右対称にならないので、複製後に位置を調整する。鏡面（Mirror）ツール（Shift+V）で右の瞳の正中線に位置するポイントの座標を参照して複製するとX軸方向は比較的簡単に合わせられる。

顔に移す前に頭のボーン・ウェイトを設定する。次の画像のようにビューをウェイトシェイドに変更する。

「マップ」メニューグループのMAP値指定（Set VMAP）で両目全体に100%のウェイト値を設定する。

目を頭のボーンとは独立して制御したい場合は必ずしも頭のボーン・ウェイトでなくてもいいけど、まずはモデリングの出来映えを確認しなければならないのでひとまず頭と一緒に動くものとして扱う。

コピー&ペーストで顔のあるレイヤーに複製する。モデラーでは問題なさそうではあったけどレンダリングしたら想像のとおりにはいかなかったことも考え、目は別のレイヤーに残しておく。

サーフェースの設定

目には外側から順に次のサーフェースを設定している。すべてunReal Xtreme2のEdgeTracerシェーダでグループID「4」を設定し、前髪を貫通するように設定してある。

Eye_Ball – 白目
Eye_Outline – 白目と瞳の境界部分
Eye_Pupil – 瞳の外側のすり鉢部分
Eye_Iris – 瞳の外側と中心の境界部分
Eye_Pupil_Center – 瞳の中心のすり鉢部分
Eye_Highlight – 瞳の右上にある固定ハイライト

サーフェースの設定は好みの部分も大いにあるのであくまでも参考程度に。次の画像は白目とハイライトの部分のサーフェース設定。白目とハイライトには髪の毛などの影を落としたくないので、自己発光度（Luminosity）を「100%」、拡散レベル（Diffuse）を「0%」にしている。

次の画像は瞳の外側の輪のサーフェース設定。光源に対してハイライトを生じさせたいので反射光（Specular）を「100%」にして光沢（Glossiness）を「40%」にしている。

次の画像は瞳の中心部分のサーフェース設定。光源に対してハイライトを生じるとかえって違和感があるのでサーフェース色は同じではあるものの反射光（Specular）を「0%」にしている。

引き続きノンリアリスティック・レンダリングにunReal Xtreme2を利用しているけど、目の中のサーフェースにはCelPainterシェーダを使っていない。正確には、使ってみる前にそこそこ良好なレンダリング出力を得られてしまったので細かいパラメータ調整まで試していない。なお、自己発光度を設定しているサーフェースにCelPainterシェーダを併用すると極端に暗く出力されることがある。

ToonTracerピクセルフィルターでサーフェース境界にエッジを引かせている。瞳のサーフェースの周囲にまったくエッジが引かれていないと瞳だけ浮いて見えてしまう上、瞳が小さく見えてしまうためだ。

また、モデリング手法の都合上、鋭角のエッジができやすいので、瞳の中に途切れ途切れの同心円状のラインが生じるのを防ぐ目的で境界検出に「法線の折り目」検出を使っていない。

レンダリング比較

上の設定でレンダリング出力したものが次の画像。顔が大きくなるようにカメラのズームファクターを変更したので相対的にエッジ・ラインが細くなっているように見えるけど、瞳の中だけに限って見れば余分なエッジは出力されていないし、レイトレースによるハイライトも生じていて瞳の中央にも奥行きが出ている。

細かいことを言えば、球状の固定ハイライトが瞳のすり鉢に接触している部分でやや不自然な歪みを生じているので、ハイライトは瞳から少し浮かせるくらいがちょうどいいのかもしれない。フィギュアで宙に浮いているハイライトというのはありえないけど、3DCGの場合は3Dプリンターでの出力を考慮しない限り許される。

次の画像は比較用に平面状の目にテクスチャを貼ったものをレンダリングしたもの。3DCGの場合は平面状の目でもサーフェースを自己発光させることで光源の影響を受けにくくすることはできるからフィギュアのような問題は起こりにくいし、テクスチャの描き方次第なのではないかと言われてしまうとそれまでなんだけど、瞳の印象は変えられたので当初の目的は達していると思う。

遠景にするとやや見え方が異なる。テクスチャを貼った平面状の目を長いこと見ていて見慣れすぎているのですり鉢状の目の陰影が新鮮に見えるだけかもしれない。もちろん、平面状の目にテクスチャを貼っている例は枚挙に暇がないほどで、十分実用に堪えるものなので、もはや好みの問題と言えるかもしれない。

途中経過

どっちでも大差ないと言われてしまえばそのとおりだけど、瞳のすり鉢状モデリングの効果を確認できただけでも満足。

参考記事

この凹で造る目の表現技法にはハイライトの位置をコントロールするという意味合いもあります。 pic.twitter.com/n9QOEQMeml

— 榎木ともひで (@eyewater_e) 2016年5月24日

LightWaveで二次元キャラ系人物モデリング奮闘記 ―肌の質感編―

最終更新：2016/10/01

3DCGにおける肌の質感の設定については本当に色々な方法があって、目的にも大きく影響される。アニメーションやゲームの場合はリアルタイム性が重視されるので、可能な限りレンダリング時間を短縮する目的でテクスチャのカラー・マップを最大限に利用して擬似的に肌の質感を再現する。静止画で写実的表現を重視する場合は拡散レベル（Diffuse）、反射光（Specular）、光沢（Glossiness）などのテクスチャ・マップに加えてSSSを使うこともあるけど、写実的表現を追求すると概してレンダリング時間は長くかかる傾向にある。

テクスチャのカラー・マップによる肌の質感の再現はローポリゴン・モデルなどで一般によく行われているので、ここではSSSについてとりあげる。SSSというのは、サブサーフェース・スキャタリング（Sub-Surface Scattering）の略で、透過性を持つ積層構造と見なせる物体に光が入射した時に反射と散乱を繰り返す現象を模擬する技術のこと。日本語では表面下散乱とも呼ばれる。比較的新しい技術で、2000年くらいまでは肌の質感の再現には大変な苦労があった。

他の哺乳類に比べて無視できるほど体毛が薄い人間の皮膚がそういった現象を起こす最たるもので、最も上にある表皮層（美容分野などでは一般に角質層とも呼ばれる）は実際には乳白色の半透明で表皮そのものが肌色をしているわけではない。光は一度表皮層を透過し、その下の真皮層や血管を通して見える血液の色に反射した後、再度入射した表皮層で散乱することによって肌色に見えている。人物の向こうに強い光源がある、いわゆる逆光の状態にある時、表皮層に浅く入射した光が真皮層に達しないでそのまま通過してしまい、皮膚の外縁部に回折現象を起こすことがある。他にこういった現象を起こす物として大理石や牛乳などがある。

LightWaveでSSSを実現するにはノードを使うしかない。SSSを想定したノードと一口に言っても次のような種類のノードがある。レガシー系のSSSノードは過去の作品で使っていた場合のために残してあると言ってもよく、新しく使う必要性はあまりない。

レガシーSSSノード
- Omega
- Theta
- Kappa
- Kappa2
SSSノード
- Sigma
- Sigma2
- SSS
- SSS2
人間の皮膚に特化したSSSノード
- Simple Skin
- Fast Skin

ここでは最も人間の皮膚の再現に適したSimple Skinノードを使うけど、LightWave 11でレンダーの仕様が見直されたため、同じ設定でもLW11の前後でレンダリング出力が異なるようになった。

LightWave 10.x

Simpke Skinの設定は次の画像のとおり。Diffuse Color以外はほとんど初期設定のまま。第一表皮層（Epidermis Distance）と第二表皮層（Subdermis Distance）の深さを100mmと大きく設定してあるのは、影の輪郭が鋭く出ないようにするため。本当の人間の皮膚ならこんな数値はありえないんだけど、あくまでも目指しているのは二次元イラスト風なので、表面が柔らかく見えることを重要視した。

ノードの接続については画像を示さないけど、Simpke SkinノードのMaterial出力をSurfaceのMaterialに入力するだけでいい。

サーフェースの基本設定でノードを有効にする。ノードを有効にすると他の設定は無効になるため、この画像のとおりでなくても問題ない。

Simple Skinは環境の背景色の影響を強く受ける。LW10では背景色をかなり暗くしておかないと肌の色が白く飛んでしまう。

LightWave 10によるレンダリング出力が次の画像。unReal Xtreme2のCelPainterシェーダよりは自然な感じなった。拡大しないとわかりにくいけど、unReal2のサーフェース貫通設定をしてある前髪にノイズが出ている。ノイズは気になるものの、これが基準になる。

なお、背景はアルファ・チャネルとして出力したので画像編集ソフトウェアでバージョンの違いがわかりやすいように白に変更してある。

LightWave 2015.x

LightWave 2015ではSimple Skinの設定がLW10とまったく同じではレンダリング出力を近似させられないので、第一表皮層（Epidermis Color）と第二表皮層（Subdermis Color）の色の明度を最大にしてある。

具体的には、LightWave 11から新しくなったカラーピッカーでHSVのV値を最大の255にする。また、Diffuse ColorもLW10と同じ設定だとかなり赤っぽく出るので、黄色寄りの乳白色にしている。感覚的にはLightWave 2015のほうがDiffuse Colorの影響を強く受けるように思える。

サーフェースの基本設定はLW10と同じ。ノードを有効にすると他の設定は無視される。「Vスタックから除外」のチェックは必ず外しておく。

背景色をLW10と同じ設定にしていると次の画像のように肌の色が暗く出る。

この問題を回避するため、特殊効果ウィンドウで背景色を白に設定する。

次の左の画像がLightWave 2015によるレンダリング出力。右のLW10のレンダリング出力と比較して右足と顔のハイライトの面積が狭くなったけど、スカート下の影などで若干見受けられたシェーディングの不自然さがなくなった。サーフェース貫通設定がしてある前髪のノイズもまったく出ていないわけではないけど大幅に軽減された。SSSに関してだけ言えばレンダーの性能は向上していると言えそう。Simple Skinの設定をバージョンを超えて等価にする方法が今のところ不明のため、LW10とまったく同じ出力を得るのは難しそうだ。

「Vスタックから除外」について

LW10まではサーフェースの「Vスタックから除外」設定はしてあってもしてなくても結果に違いはなかったので無頓着だったけど、LW2015では厳格化されたようで、「Vスタックから除外」にチェックを入れているとSSSが正常に処理されなくなる。

具体的には、レンダリング出力が次の画像のようになる。手や足の露出している部分がDiffuse Colorとは関係ない灰色になり、顔にも顎のあたりに灰色のノイズが出ている。

Vスタックというのはヴォリューム・スタッキングのことで、マニュアルを読んだ限りでは片面ポリゴンで囲まれた三次元空間を風船のような何もない空間ではなく固体の塊として扱うものらしい。従来は適切に処理されていなかったSSSや透明サーフェースの屈折レイトレースが最適化されるということらしいけど、Vスタックから除外するほうが良い具体例がないので、ちゃんと理解できてはいない。

途中経過

SSSは通常のレイトレースでは得がたい良好なレンダリング出力を得られるのが長所だけど、unReal2のようにグラディエントでハイライトや影の色を明示的に指定できるわけではないので再現したい肌の色がはっきり決まっている場合にはテスト・レンダリングを繰り返す必要があり、調整に時間がかかるのが短所。

参考記事

LightwaveでPoserフィギュアの肌をリアルにする（fastskinシェーダ）（LightWave覚書）

LightWaveで二次元キャラ系人物モデリング奮闘記 ―unReal Xtreme2編―

最終更新：2016/12/14

一般に、3Dモデルを二次元イラスト風やセルアニメ調にレンダリングするためのシェーダ群を「セル・シェーダ」又は「セルルック・シェーダ」とか「トゥーン・シェーダ」などと呼ぶ。

3DCGは旧来から「フォト・リアリスティック」と呼ばれる現実のものと見紛うような写実的な表現を目指して制作されることが多いけど、イラストやアニメの世界では現実には起こりえない非写実的表現も多い。日本では写実的CGと同じくらい非写実的表現を再現するレンダリング画像の需要も高い。近年では必ずしもセル・シェーディングのみのことを指さなくなったため、非写実的表現に「アンリアル（unreal）」とか「ノンリアリスティック（non-realistic）」という言葉が使われるようになっている。英語としてはどちらも正しい。

LightWaveでセル・シェーダというと、昔から標準でSuper Cel Shaderが実装されているけど、パラメータが感覚的にわかにくく、所望のレンダリング出力を得るには相当な回数のテスト・レンダリングを要する。また、レイトレースに強く拘束され、曲面を曲面としてシェーディングしようとするためアニメ用語で言うところの「色トレス線」でハッキリと分かれるような境界線が出ないという特徴がある。拡散レベル（Diffuse）を利用したシェーディングであるために影が強く出やすいうえ、明るさでしか階調をつけられないので光の当たっている明るい部分と影の部分で色相を変えられないという欠点もある。

それから、セル・シェーディングには輪郭線がつきものだけど、LightWave標準のエッジ・ライン出力は様々な意味で不足が多い。LightWave 11あたりから改良はされているものの基本性能は変わっていないため不足分を補えているとまでは言い難い。

unReal Xtreme2（以下、unReal2）は、LightWaveユーザーの間では知らない人はいないと言われるくらい有名なノンフォトリアリスティック・レンダリング用外部プラグイン。当初はセルアニメ調のレンダリング出力を意図して開発されたものではあるけど、汎用性が高く他の表現にも応用できる強力なツールを提供してくれる。LightWaveには本来実装されていないレンダーレイヤーを備えているなど、もはやLightWaveの枠を脱しているような完成度の高さに目を見張るものがある。英語にも対応しているので海外でも使用実績があるそうだ。

unReal2をLightWaveに読み込ませると、大量のプラグインがインストールされるけど、大半はその機能を追加ノードで実現するためのもので、より高度な利用を想定して用意されているもの。

高機能すぎるが故にすべてを理解できていないし、理解できているものでも全部を書いているとキリがないため、ここではシェーダに絞ってもっとも簡単な使い方を書いていく。原理や詳しい使い方については公式マニュアルを参照のこと。

CelPainterシェーダ

CelPainterシェーダは、その名のとおりセル・シェーディングを実現するためのもの。エッジを検出するためのEdgeTracerシェーダとは独立していて、どちらか片方だけ使用することもできる。最新バージョンの1.51ではCelPainterシェーダを先に指定しても、EdgeTracerシェーダを先に指定しても同じ結果が出力されるように調整されている（古いバージョンでは順番によって結果が異なる場合があるという特徴があった）。

シェーダのプロパティを開くと、次の画像のような設定パネルが表示される。デフォルトではサーフェース色を単に暗くするだけの灰色のグラディエントが設定されている。基本は乗算モードでレイヤーが重ねられているので、任意のグラデーションを指定したい場合はサーフェース色を白にしてこの画面でベースカラーをミキシングしていくことになる。グラディエントのキーのインターフェースはサーフェースの基本設定で使うグラディエント・マップとほぼ同じ仕様。

スムージングを「ステップ」に設定することでアニメのようなハッキリとした色の境界線を形作ることができる。アニメ調の場合は意外なほど影の部分は少なくていいので、影に相当する色の開始位置を50%から大きく（右に）しないほうがうまくいきやすい。

ここでは特に設定していないけど、「透明度」タブで透明度の設定も可能。

「スペキュラ」タブで光沢用の色も設定可能で、ベースカラーや光源色に影響されない特殊な光沢を表現することもできる。アルファ・チャンネルも備えられているので、ベースカラーとうまくブレンドすることで幻想的なサーフェースを実現することもできるだろう。

注意点としては、基本設定の反射光（Specular）が「0%」になっていると次の画像のように真っ黒なグラディエントになり、まったく効果が現れないので、適当な数値を設定しておく必要がある。

「設定」タブは基本的には変更しなくてもいい。シェーダ出力をレガシーLWのシェーダ計算方法の特徴に合わせたものにするためのものと、いわゆる「透明」を意味する灰色の市松模様の色を変更できる。

EdgeTracerシェーダ

EdgeTracerシェーダは、モデルの輪郭線を出力させるためのシェーダだけど、サーフェースにグループIDを付加して区分することができる。グループIDの概念は最初はとっつきにくいところがあるけど、慣れてくると実に周到な設計になっていることがわかる。

普通にレンダリングさせる分にはグループIDはすべて「0」でいいんだけど、グループIDをうまく設定すると通常のレイトレースでは後ろに隠れてしまうサーフェースを強制的に手前に表示させるという「サーフェース貫通」を設定できる。アニメなどではよく前髪の上に眉が描かれていたり、前髪に隠れているはずの目が見えていたりするけど、それを実現するためのもの。CelPainterシェーダもとてもよくできているけど、unReal2の本領はEdgeTracerシェーダにあると言っても過言ではない。

次の画像は、左目のサーフェースにグループID「1」を設定したもの。目の他に、眉（Eyebrows）やまつ毛（Eyelashes）などのサーフェースにもグループIDに「1」を設定しておく。肌などのサーフェースはすべてグループID「0」に設定してある。

次に、前髪にあたる「Hair」サーフェースにグループID「2」を設定する。後ろ髪にあたる「Hair_Back」サーフェースはグループID「0」等、グループID「1」及びグループID「2」以外にしておく。

続けて「Surface Piercing」ボタンをクリックすると、グループID一覧が表示される。ここで、目や眉に設定したグループID「1」にチェックを入れる。すると、グループID「2」の前髪の上に強制的にグループID「1」の目や眉が出力されるようになる。この例では、普通は「0」→「1」→「2」の順番に重なっているものを「0」→「2」→「1」の順に重なっているように見せる。

最初はイメージを掴みづらいかもしれないけど、貫通する側ではなく、貫通される側のサーフェースに貫通設定をするということを覚えておくと理解しやすい。

言葉で説明するとわかりにくいので、次のふたつのレンダリング出力を見比べてもらったほうが早い。前髪にサーフェース貫通設定をしていないほうは目や眉が隠れてしまっていて視線や表情が読み取りにくくなっているけど、サーフェース貫通設定をしてあるほうは前髪を無視して目や眉が見えている。

ただ、便利だけどサーフェース貫通設定は使い方が難しいところもあって、前髪に裏表や厚さがあってCelPainterシェーダが設定されていると前髪の裏側のエッジも貫通して表示されてしまって正しく出力されないことがある。前髪の裏と表のサーフェースを別にしたり、ノードをうまく使えば回避できるのかもしれないけど、現時点では研究不足で確実な方法はわからない。少なくとも、サーフェース貫通設定を使わないという選択肢はないので、前髪のサーフェースを工夫することになるだろう。（最近原因と改善方法がわかった。「サーフェース貫通設定時の出力の改善」節を参照）

Scene EditorによるグループID一覧表示

多数のサーフェースにグループIDを割り当てているとどのサーフェースに何番のIDを割り当てたのかわからなくなってしまうことがある。そういった場合は、Scene Editorの「サーフェース」タブのプロパティでEdgeTracerを選択すると次の画像のように一覧表示できる。

UVテクスチャの区分のみでサーフェースを分割している人にとっては管理できなくなるほどの数のサーフェースを使用するということ自体が考えられないかもしれないけど、unReal2を使う上では奥行きを考慮しながらサーフェースを割り当てていく必要が少なからず発生する。

なお、Ver. 1.51ではLightWave 2015での日本語対応は不十分で、サーフェースノーマル設定の日本語表記が文字化けを起こす。

ToonTracerピクセルフィルター

ToonTracerピクセルフィルターは、EdgeTracerシェーダで検出した輪郭線をどのように出力させるのかを決定するためのプラグイン。これが設定されていないとEdgeTracerシェーダは機能しないし、EdgeTracerシェーダが設定されていないとToonTracerピクセルフィルターは機能しないのでエッジはレンダリングされない。特殊効果ウィンドウで追加するため、EdgeTracerシェーダが追加されているすべてのサーフェースに影響する。

ToonTracerピクセルフィルターのプロパティを開くと次の画像のような設定パネルが表示される。「ブラシ設定」タブではエッジをどのように描画するかを指定できる。単色のラインはもちろん、任意の画像からラインにテクスチャを貼り付けることができるなど多くの機能を備えている。

パネルの左領域でエッジ描画用のレイヤーを追加でき、グループIDごとにエッジ・ラインの色を個別に管理できる他、レイヤーごとにエッジをあえて表示させないサーフェースをグループID単位で指定することもできる。

「境界設定1」タブではエッジ・ラインを引くべき境界判定をどこで行うかを設定できる。オブジェクトの境界はもちろん、グループIDをうまく設定すればIDの切り替わりを境界に指定することもできる。

ここで秀逸なのは「クラスタ境界」で「スケッチ色」を指定できること。スケッチ色は本来レンダリング出力には影響しないものだけど、立体を平面に捉えた時にスケッチ色が異なるピクセル同士が隣り合った場合はそこを境界と判定する。

これは、他の3DCGソフトウェアでカラー頂点マップなどを利用して境界と判定させたいものを極彩色に着色し、それだけをレンダリングさせてAdobe AfterEffectsなどでソーベル・フィルターやキルシュ・フィルターといった輪郭検出アルゴリズムを使って輝度の差を輪郭として検出させていた方式をLightWaveのみで実現するものだ。

役に立たないものまで活用する、まさに発想の転換。LightWaveの開発陣もスケッチ色をこういう風に利用されるとは予想していなかったに違いない。

具体的には、同一サーフェースが設定されている手の指や髪の毛が三次元的に至近距離で重なっている部分をレンダリングで平面に投影した場合にエッジが検出されない問題を回避できる。

次の画像は右手の例だけど、灰色の部分はスケッチ色は「なし」に設定されている。スケッチ色「なし」と隣り合っている場合は境界とは判定されない。

また、異なるスケッチ色を隣り合わせておくことで意図的に境界線を引かせることもできる。例えば、次の画像のような上着の袖や胸側と背中側の縫い目などだ。パッチの境界線上に制限されるのが短所と言えば短所だけど、最初から縫い目がどの辺になるか考えながらモデリングしていけばそれほど大きな問題にはならない。利用目的にもよるだろうけど、テクスチャに縫い目を描かなくていいメリットのほうがむしろ大きいと感じる。

上着にはひとつのサーフェースしか設定していないので、前の合わせが互い違いになっている部分にはエッジが綺麗に出ないことがある。そこで、右側と左側の生地のスケッチ色を変え、前に垂れている襟のスケッチ色も変えておくことによって確実にエッジが引かれるようにしている。

クラスタ境界に「スケッチ色」を指定していないものと指定したものの比較。ちょっとわかりにくいかもしれないけど、手と上着の合わせ部分に注目してほしい。結果の違いをわかりやすくするために「法線の折り目」検出はオフにしている。

モデリングの都合上、鋭角にできなくてエッジを検出させづらい鼻のラインを表示させたい場合などにも活用できる。角度によっては口の輪郭も出づらいことがあるので、口の外側と内側の境界にもスケッチ色を設定している。

スカートの縫い目も同様に設定している。このような境界設定をカラー頂点マップを使って実現しようとすると、どの方向から見た時でも同じ色が隣り合わないように工夫して塗り分けなければならず、少なからずパズル状態になる。確実に輪郭検出をさせるためには明確な輝度の差が必要になるため、それほど多くの色も使えない。そのような労力を一挙に解消できる。

蛇足ながら、Blenderは無料ながら標準でレンダーレイヤーを備えていて、カラー頂点マップのみのレンダリング出力を別に用意し、輪郭検出をさせた後、コンポジットで通常レンダリング出力と合成できる能力があるけど、スケッチ色による色分けの手軽さはちょっと手放しがたい。もっとも、Blenderの最大の魅力は無料であるが故に世界中にユーザーがいて、新しい使い方が次々に考案されているので情報量が豊富という点なんだけど。

「境界設定2」タブでは隣り合うポリゴンの「法線の折り目」をエッジ検出に利用することができる。標準機能の「鋭角の折り目」エッジ検出よりも強力で、山折り谷折りの区別もある。180°を指定するとすべてのポリゴンのエッジが対象となり、ワイヤーフレームが表示されることになる。0°を指定すればすべてのエッジが無視される。

サーフェース貫通設定時の出力の改善

前髪などのサーフェースにEdgeTracerシェーダで貫通設定をしている場合に、そのサーフェースに重ねてCelPainterシェーダを設定すると後ろにあるはずのサーフェースの境界線も貫通して見えてしまったり、ノイズが大量に出力されるという問題があった。長らく原因不明だったけど、最近ようやく原因が判った。

これまでは、次の画像のように、髪の毛のサーフェースが属するレイヤーの「グループ境界」にチェックを入れていた。

同様に、髪の毛の輪郭を出しやすいという理由から、「法線の折り目」検出にもチェックを入れていた。

ところが、上の2つの画像のような設定でレンダリングすると、次の画像のようにエッジ・ラインが必要以上に出力されたり、無視できないほど大量のノイズが出力されたりする。

この現象を回避するもっとも簡単な方法はCelPainterシェーダを髪の毛に使用しないこと、あるいは肌のサーフェースにSSSを使用しないことだった。肌の質感の観点から言えばSSSを使用しないという選択肢はなかったので、髪の毛の質感を犠牲にしていた。

色々試行錯誤しているうちに、「グループ境界」と「法線の折り目」のチェックを外すと出力が大幅に改善されることが判明した。「法線の折り目」は出力されるエッジの量を制御するのに有効なのはかなり早いうちに気付いていたけど、「グループ境界」検出をOFFにすることでノイズ低減につながることにはほぼ偶然気が付いた。連続して隣り合っているポリゴンのグループIDの境界ばかりでなく、三次元的に重なっているグループIDも計算に入るようだった。

「グループ境界」と「法線の折り目」のチェックを外す前と後の比較。不必要なエッジ・ラインは出力されなくなり、ノイズも大幅に低減した。前髪に多少はノイズが出ているけど、顔の肌に使っているSSSがEdgeTracerシェーダのサーフェース貫通設定と相性があまり良くないためのようだ。

また、unReal Xtreme2は、クラシック・カメラでの使用を前提として設計されているため、パースペクティブ・カメラ等の新型カメラを使用するとノイズが出やすくなる。もっとも、クラシック・カメラにするとノイズをほぼ無視できるくらいまで少なくでき、エッジ・ラインも滑らかなになるので綺麗な出力を得られる代わりに、レンダリング時間が大幅に長くなる傾向にあるという欠点がある。クラシック・カメラを使うのは最終レンダリングだけにするか、多少のノイズには目をつぶってパースペクティブ・カメラの高速レンダリングを使うかの選択になる。

クラシック・カメラでレンダリングしたもの。ノイズは目視ではわからないくらいになり、エッジ・ラインも滑らかになっている。

途中経過

ひとまず、ほとんどのサーフェースにunReal2を適用してみた。概ね問題ないんだけど、肌の質感があまりにも平面的なので、もう少し手を加える。もし、EdgeTracerシェーダとCelPainterシェーダが独立していなかったら、ほとんど工夫の余地がなかったところだ。

参考記事

D-Creation
unReal Xtreme2公式マニュアル
検証：3Dアニメに輪郭線は必要か？その３（榊正宗の電子日和 – 電子書籍と3DとアニメとiPhone）

MMDモデル「らぶ式ミク」をLightWaveで再現する

最終更新：2016/09/06

MMDモデル「らぶ式ミク」は、ボーカロイド「初音ミク」のMikuMikuDance用ユーザーモデルのひとつ。初音ミクのモデルは数多くあるけど、その中でも個人的にとても気に入っているばかりでなく、二次元キャラクター風の3DCG人物モデルとしての完成度も高いと思っていて、人物モデリングの参考にもさせてもらっている。

分析のために分解してみたりもするんだけど、綿密に計算して展開されたUVマップや精緻に描かれたテクスチャー画像、豊かな表情を可能にする100にものぼるモーフ・マップなど、どこをとっても感嘆するばかり。MikuMikuDanceで表示させた時に見栄えがするようにと考えられた工夫も随所に織り込まれていて、一言で言い表す賞賛の言葉も見当たらないくらい。

自社の製品開発の一環として研究のために購入してきた競合の自動車メーカーの高性能車両を分解してみたら、その設計や構造は言うに及ばず、普通に運転する分にはまず目に触れるはずもないエンジン内部の部品も綺麗に磨かれていたのを見て二度驚いたといった逸話を思い出してしまった。

そんな「らぶ式ミク」の制作に熱意を傾けた諸氏に尊敬を捧げ、敬意を払うとともに、参考にさせてもらっている恩返しという意味もこめてLightWaveでらぶ式ミクをMMD風に再現する方法を考えてみた。LightWaveでアニメ調のレンダリング出力をさせるためのマテリアル研究も兼ねている。

モデラーでサーフェースを設定する

PMD形式ファイル・ローダーを使って「らぶ式ミク」を読み込むと、最初は次の画像のような真っ白なモデルが出てくる。単純なモデルの場合はテクスチャーもUVマップと併せてロードされるのだけど、人物モデルのような複雑なモデルの場合はUVマップとテクスチャーの対応がちゃんととれていないことがある。

レイヤーが大量に読み込まれるけど、ほとんどがモーフ用で実際のモデルが保存されているのは2番レイヤーなので、フルキーの「2」キーを押してモデル本体を表示させる。

共通設定

「らぶ式ミク」は、surf000からsurf007までの8つの部分のサーフェースに色分けされている。まず、すべてのサーフェースに対して次のとおりに設定する。色はすべてテクスチャーで再現されるため、すべて初期値の白のままにしておく。

「自己発光度」を「100%」
「拡散レベル」を「0%」
「透明度」を「0%」

なお、透明度が設定されているとポリゴンの表裏が反転しているように見えることがある。実は上の画像もインポート直後のものではなく、透明度を0%に設定してからスクリーン・ショットを撮ったもの。本当にインポート直後だと色々透けて見えてしまうので…。

自己発光度を100%、拡散レベルを0%にするのはエッジ・ラインの抽出でも使った手法なんだけど、モデル自身の陰影を打ち消すための設定であって、別に全身を発光させたいわけではない。MMD風にレンダリングさせるにはレイトレースがむしろ問題になる。陰影にあたる部分はテクスチャーに直接描かれているので、問題にならない。

テクスチャーを割り当てる

次に、サーフェースの「色」に割り当てるテクスチャーとUVマップを対応させる。簡単にまとめると次の表のとおり。

**らぶ式ミクのサーフェースとテクスチャーの対応**
サーフェース名	主な部位	テクスチャー画像
surf000	ヘッドセット	Lm_jac.bmp
surf001	顔・体	Lm_body.bmp
surf002	目の周囲・口・眉毛など	Lm_body.bmp
surf003	服・靴・袖	Lmtex.bmp
surf004	瞳（標準）	Lm_eyes.bmp
surf005	瞳（表情用）	Lm_star.tga
surf006	表情用	yyk_tpo.tga
surf007	髪	Lmhair.tga

インポート直後はいずれのサーフェースにも定数（Value）のプロシージャル・マップのレイヤーが仮に割り当てられているので、それらを消去し、残ったひとつのレイヤーを「画像マップ」に切り替える。「投影」は「UV」、「UVマップ」は「Texture」をそれぞれ選択する。MMDモデルは仕様上UVマップをひとつしか持てないため、すべてのサーフェースのためのUVをひとつのUVマップに保持している。

具体的なテクスチャーの設定は次のとおり。

surf000

surf001

surf002

surf003

surf004

surf005

「らぶ式ミク」では目が手前と奥にひとつずつ、左右で合計4つあり、モーフによって入れ換えている。surf005は奥にある目のテクスチャーを設定するためのもの。

surf006

モーフによって目や口や眉に出ない様々な表情を実現するためのテクスチャーを設定する。モーフが適用されていない時は表面に出てこないようになっている。モデラーの右下にあるマップ選択で「M」ボタンをクリックし、モーフ・マップを選択すると効果を確認できる。

surf007

髪の毛のテクスチャーのTGA画像には毛先に向かってアルファ・チャンネルが設定されているのを確認してはいるんだけど、アルファ・チャンネルを透明度のマップに設定してもうまく透過されなかったので、ひとまずグラディエント・マップで代替する。「入力パラメータ」に「Slope」を選択し、パラメータ「0」を値「0%」に設定し、パラメータ「0.8」付近のところに値「0%」のキーを作り、更にパラメータ「1.0」で「20%」になるようにキーを設定する。これで前髪で目が隠れてしまっても瞳が透けて見えるようになる。

髪の毛にはお好みで「反射光」を「100%」、「光沢」を「40%」くらいに設定するとハイライトが綺麗に出るようになる。

保存

サーフェースの設定が完了すると次の画像のようになる。オブジェクトに名前をつけてLightWave形式で保存する。LightWaveでは日本語等のマルチバイト文字への対応がいまいちですぐに文字化けするので、できれば半角の英数字・記号でファイル名をつけるほうが無難。

レイアウトに読み込む

保存した「らぶ式ミク」のオブジェクトをレイアウトに読み込む。ひとまず2番レイヤーの「Model」を読み込む。オブジェクトの「アイテムプロパティ」を開き、「輪郭」タブでラインレンダーによって出力させるエッジを選択する。「シルエットエッジ」と「鋭角の折り目」だけにチェックする。

なお、モデルの作り方の都合上、顔や体の途中でパーツやサーフェースが区切られているため、「共有しないエッジ」や「サーフェイス境界」を選択してしまうと予期しないところに線が出力されてしまう。

モーフ・ミキサーで表情を制御

次に、オブジェクトの「アイテムプロパティ」の「変形」タブで変位プラグインの「Morph Mixer」を追加する。複数のモーフ・マップを文字通り混合してオブジェクトを任意に変形させることができる。MMDの表情選択や適用量のスライダーとほぼ同じ機能を持つもの。

「Morph Mixer」の「プロパティ」を選ぶと、モーフ・マップの一覧と変位量のスライダーが表示される。「1_」で始まるモーフ・マップ名が眉、「2_」で始まるモーフ名が目、「3_」で始まるモーフ名が口（及び舌や歯や顎）、「4_」で始まるモーフ名がその他の表情、髪の毛の量、袖の大きさなどに割り当てられている。

モーフ・ミキサーを閉じるとオブジェクトにモーフが適用され、表情などが変わっている。レンダリングすると次のような画像が出力される。MMDのレンダリング出力に比べると全体的にやや明るい感じになるけど、概ね再現できているように思う。

スケルゴン（ボーン）については今回まったく手をつけていないので、アニメーションまでは確認できていない。MMDでは、直接他のボーンに接続されていない宙に浮いたボーンを設定できるけど、すべてのボーンが直接接続されていて親子関係で連続している必要があるLightWaveのスケルゴンとは互換性がない。つながっていないボーンを適宜補間する必要があり、そのままでは動かすことはできない。

ウェイト・マップはインポートされているようなので、理論上はボーンの問題さえクリアできればLightWaveでも「らぶ式ミク」を動かせると思われるけど、ポリゴンの数が多くスケルゴンの動きをテストするにも時間がかかるため実際に動かそうとするにはかなりの労力が必要になる。

LightWave用MMDモデルPMD形式ファイル・インポーター

BRDFシェーダ

最終更新：2016/09/06

BRDFは、Bidirectional Reflectance Distribution Functionの略で、日本語では双方向反射分布関数という。数学的なことはあまりよくわからないんだけど、LightWaveにおけるBRDFシェーダは簡単に言ってしまうと、特定の光源に対して反射する面のハイライトに変更を加えることができるもの。異方性反射に似たようなこともできる。

異方性反射に関する記事ではAnisotropicノードやAni-Reflectionsノードを使ってSpecular ShadingとReflection Shadingを実現し、Diffuse Shadingを使って金属表面のヘアライン加工の質感の再現を試みた。しかし、サーフェースや光源の色にレンダリング結果が影響を受けなくなるなどの制約もあることも書いた。BRDFシェーダは、厳密な意味での異方性反射を再現することはできないけど、ハイライトに色を着けることが可能で、光源に特殊な設定をすることなく比較的手軽な設定でハイライトの形状等を制御できる。

まず、次の画像のような球状のオブジェクトを用意する。もっとも単純な白色のスポットライトをひとつ配置しただけの簡単なシーンで、ハイライトは円形になる。これにBRDFシェーダを適用していく。

Regularモード

最初に、「Regular」モード。ハイライトの色（Color）、反射光（Specular）、光沢（Glossiness）を指定できるのみで、ハイライトの形状は通常と同様になる。

上の画像の設定でレンダリングすると次の画像のようになる。光源の色とは無関係に、ハイライトに黄色が適用され、光沢を弱めに設定したためぼんやりとした輪郭になる。ハイライトの位置が同じというところが重要で、BRDFシェーダは特定点における光の反射のみに適用されるものであることがわかる。

Anisotropicモード

次に、「Anisotropic」モード。ハイライトの色、反射光、光沢に加えて、「Anisotropy」と「Direction」を角度で指定できる。Anisotropyは異方性反射のことだけど、できることはかなり限定的で、放射状の異方性反射はある程度模擬できるものの、同心円状の異方性反射を模擬することまではできない。「Anisotropy」と「Direction」を設定するとハイライトの形状をずらすように互い違いに歪ませることができ、「Anisotropy」を「90°」、「Direction」を「0°」に設定するとハイライトの中心点で交差する扇状の反射になる。

上の画像の設定でレンダリングすると次の画像のようになる。ハイライトが緑色になり、異方性反射風の扇状の反射になっていることがわかる。「Anisotropic」モードでもハイライトの中心点は同じで、光を当てる方向やカメラの視点を変えなくてもBRDFシェーダの効果を得られる場所には変化がないことがわかる。

AnisotropicⅡモード

最後に、「AnisotropicⅡ」モード。「Anisotropic」モードの設定項目に加えて「Mapping」を指定できる。マッピングに「Cylindrical」を指定し、X、YまたはZのいずれかの軸を指定するとオブジェクトの軸に沿ったハイライトを生じる。「Anisotropy」と「Direction」の挙動は「Anisotropic」モードとは異なり、「Anisotropy」と「Direction」の両方を「90°」に設定するとハイライトの中心点で交差する扇状の反射になる。

上の画像の設定でレンダリングすると次の画像のようになる。ハイライトが赤色になり、異方性反射風の扇状になっているのは「Anisotropic」モードと同様だけど、ハイライトの中心点がオブジェクトのY軸に移動している。3つのモードのうち、動作としてはもっともAnisotropicノードに近いけど、同心円状の異方性反射の模擬が難しい（少なくとも、試した範囲では実現できなかった）上に、Anisotropicノードと異なり、異方性反射の中心点を任意の位置に移動させられないため制御が難しい。UVマップを指定することもできるけど、更に高度な設定になるので、そこまでする必要があるかどうかは判断の分かれるところ。

ティーポットで実験

それぞれのモード単体でできることはそれほど大したことはないけど、ひとつのBRDFシェーダに3つまでのレイヤーを設定できるので、自動車の塗装のように何層かの塗装面におけるハイライトを制御したい時に有効。

例えば、何の変哲もないティーポットのモデルを配置したシーン（左の画像）にBRDFシェーダの「Anisotropic」モードを二層にわたって適用することで、ハイライトにヒステリシス曲線のような歪みを生じさせ、表情を持たせることができる（右の画像）。

BRDFシェーダはその特性上、平面よりはハイライトが出やすい曲面のほうが効果がはっきりとわかるけど、光源の方向やモデルの角度などによって立体感が薄いと感じられる場合などに光源に依存しない反射を生じさせることで立体感を増すこともできる。

作品への応用

実験だけでは効果がわかりにくいと思うので、更に進めて実際の作品に反映したらどうなるか試してみた。次の画像はBRDFシェーダ適用前のもの。左右の白い斜線の入った青い部品は機首を中心にして山なりに角度がついているんだけど、光源の都合などで立体感がわかりにくい。

次の画像はBRDFシェーダ適用後。白色と青色のサーフェースに全体的に水色のハイライトを入れた。機首や主翼前縁部のような曲面のほうがシェーダの効果がはっきり見えるけど、平面にもレイトレースではわかりにくかった部分にハイライトが出て立体感はやや増した。ただ、本来の光源方向がわかりにくくなって嘘っぽく見えてしまうという欠点もあるので、度を超さない程度に使うのが良いように思う。

バグについて

最後に、BRDFシェーダにはLightWave3D 10.1の時点でバグがあり、サーフェースにBRDFシェーダを適用したままモデラーでオブジェクトのファイル間、レイヤー間のコピー&ペーストを行うとクラッシュする。モデラーではシェーダの効果を確認できないのでレイアウトで最後の仕上げに適用するようにしたほうがいい。この問題は、機能を一時的にオフにするだけでは解決できないため、シェーダ適用後にモデルを修正する必要が発生したら、シェーダをサーフェースから完全に除去する必要がある。その際に、パラメータが多いので設定を忘れてしまわないようにどこかにメモしておかなければならない。そういった意味では使い勝手が良くないシェーダではある。

異方性反射（Anisotropicノード）

2024年11月
日	月	火	水	木	金	土
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30

瞳の後退モーフによるカメラ目線

エクスプレッションによる視線コントロール

関連記事

基礎を作る

アポロニウスの円

縦横の模様を合わせる

曲線折りの模擬

ウェストの絞り込み

基本版完成

途中経過

関連記事

参考記事

まつ毛のモデリング

ウェイト・マップを応用した色調調整

途中経過

関連記事

概念図

平面状の目のテクスチャ・マップ

すり鉢状の目のモデリング

サーフェースの設定

レンダリング比較

途中経過

関連記事

参考記事

LightWave 10.x

LightWave 2015.x

「Vスタックから除外」について

途中経過

関連記事

参考記事

CelPainterシェーダ

EdgeTracerシェーダ

Scene EditorによるグループID一覧表示

ToonTracerピクセルフィルター

サーフェース貫通設定時の出力の改善

途中経過

関連記事

参考記事

モデラーでサーフェースを設定する

共通設定

テクスチャーを割り当てる

surf000

surf001

surf002

surf003

surf004

surf005

surf006

surf007

保存

レイアウトに読み込む

モーフ・ミキサーで表情を制御

関連記事

Regularモード

Anisotropicモード

AnisotropicⅡモード

ティーポットで実験

作品への応用

バグについて

関連記事