LightWaveでメカの多重関節を作る

最終更新:2017/02/10

以前はメカの関節についてはモデラーの中心点移動ツールを使って中心点を関節の駆動部分に指定することで実現していた。今でもこの方法は有効だけど、すべてのパーツを別のレイヤーかオブジェクトとしてあらかじめ分割しておく必要があった。

この方法は、煩雑な設定が不要で簡便なのが長所で、簡単なモデルの場合はいいんだけど、人型ロボットのように見栄えがするようにスタイリングやポージングを懲りたい場合はバランスの調整が難しいという欠点があった。現在はメカにもボーンを組み込んでウェイト・マップを使って関節を動かすのが主流になりつつあるので、単純に今風な方法でないとも言える。

LightWaveでのメカの多関節化についてはノウハウがあまり貯まっていなかったので、人型ロボットのような本格的なメカに取り組む前に数本程度のボーンで構成される簡単な多関節モデルで試してみることにした。

モデラー

今回は、次の画像のようなモデルを用意した。すべての部分が1レイヤー上に配置されている。このうち盾のような部分を三軸で回転させられる可動モデルとしたい。

難しいことはやってないので作り方は省略するけど、5ポイント以上のポリゴンがあるとボーンの旋回に綺麗に追随してくれないことがあり、悪くするとレンダリングした時に無視できないくらいの誤差が生じ、共有しているはずのエッジが分離してしまう不具合を起こすので、極力4ポイント以下のポリゴンに整理しておく。

スケルゴンの構成

モデルには次の画像のような構造の5本のスケルゴンを組み込んである。実際の動作に必要なスケルゴンはCenter、Arm及びShieldのみ。Rootは母機であるパワーユニットを固定するために存在する。Null_BoneはCenterスケルゴンとArmスケルゴンの回転軸のほんのわずかなズレを補うためにあり、動作には直接関係ない。繰り返しになるけど、Rootスケルゴンを最初に作る時だけドラッグで引き切らないと長さがゼロのスケルゴンができてしまうので注意。

モデルの座標情報を参照してスケルゴンの位置を回転の中心軸に可能な限り精密に合わせておく。中心軸になりそうなところにポイントができるように平均統合(Weld Average)ツールなどを利用すると座標を取得しやすい。

Shieldスケルゴンを最終的にはバンク(スケルゴンのヘッドからテイル方向を軸とする回転)で制御したい関係上、他のスケルゴンもすべてバンクで制御することになってしまった。ロボットの腕や脚などを作りたい場合はジンバルロックを避けるためにも極力ピッチで制御するのが常套手段ではある。

画像を示す必要があるかどうかは微妙だけど、スケルゴンツリーは次の画像のとおり。左右の区別の必要があるかもしれないと思って接尾辞に「_L」を付けてあるけど、同じレイヤー上に左右のスケルゴンを置かない場合は必要なかった(上の画像では接尾辞を省略している)。表示上、Null_Boneのウェイト・マップ名も出ているけど、実際のマップは作成していない。

バンクハンドルの設定

これは後でもいいんだけど、レイアウトに移した時にボーンのバンク角に中途半端な値が入ってしまって操作しづらくなることがあるので、スケルゴン回転(Rotate Skelegons)でバンクハンドル(Bank Handle/Pitch Plane)をキリの良い値に設定しておく。3つの値のうち、いずれかひとつを1.000にすればいいんだけど、今回のようにスケルゴンが三次元的に直角に連なっている場合はどっちが前か後ろかはっきりしないので、どこをその値にすればいいのかはスケルゴンにより異なり、これといった決まりがない。レイアウトに移してみないとどうなるかわからないのが実際のところで、こういったところがLightWaveのわかりにくいところ。

スケルゴン編集(Edit Skelegons)でも同様のことはできるけど、数値入力ウィンドウがなく、どうしても誤差が入るので、スケルゴン編集で視覚的に大体整えたらスケルゴン回転で一番大きい値を1.000にするのが一番確実。

ウェイト・マップの作成

各所のウェイト・マップを作成する。ウェイト・マップ名はレイアウトでの作業を簡略化するために、スケルゴンと同じ名前にしておく。メカは基本的に100%か0%かの2値しかないので、MAP値指定(Set Map Value)で割り当てていく。

次の画像は、前後(垂直)方向へ回転させるためのCenterスケルゴンに対応する部分をウェイトシェイドで表示したもの。

同じく、左右(水平)方向へ回転させるためのArmスケルゴンに対応する部分。なお、Centerスケルゴンに対応する部分とはポイントを共有しないように一度分割しておかないと、スケルゴンを回転させた時にねじれてしまう。

最後に、盾の部分をひねり方向へ回転させるためのShieldスケルゴンに対応する部分。

残りの部分にはウェイト・マップを設定しなくても特に問題ないけど、気になるようならRootスケルゴンに対応するウェイト・マップに設定しておくとよい。

スケルゴン回転でチェック

次に、スケルゴン回転(Rotate Skelegons)でうまくスケルゴンとウェイト・マップが連動しているかをテストする。関節になるはずの部分がつながっていたりするようなモデリングのミスに気付くこともある。ここでは、バンク角のみを使用する。

ちなみに、スケルゴン回転でチェックできるのは、ウェイト・マップによる変形のみで、レイアウトにおけるボーンからの距離のフォールオフによる変形の影響をチェックすることはできない。

次の画像は、Centerスケルゴンを指定しての垂直方向の回転のチェック(入力はバンク)。Centerスケルゴンの子スケルゴン以下のすべてのスケルゴンが旋回に追従しているのがわかる。

一度スケルゴンの回転をリセットしてから、Armスケルゴンの水平方向の回転チェック(同じく入力はバンク)。次の画像のように、水平方向にのみ旋回している。

次の画像は、Shieldスケルゴンのひねり方向の回転チェック。同スケルゴンはアームの蝶つがい部分を中心に引いてあるので盾の部分は180°で裏表が反転するように動く。

レイアウト

モデラーで問題ないようであれば、レイアウトに移る。モデルをアイテムの追加で呼び出し、スケルゴン変換かSkelegon Readerプラグインでボーンを組み込む。スケルゴン・エディタを使わなかった場合は、どちらでもほぼ同じ結果になると思う。Skelegon Readerは、スケルゴン・エディタでのバンクの整列などが反映されるけど、スケルゴン変換は反映されないという違いがある。

そのままの状態で、各所のボーンを旋回させると次の画像のようにモデルが大きく歪む。特に、Centerボーンを旋回させた時の歪み具合がひどいけど、場所によってはボーンからモデルが離れてしまっている。ワイヤーフレームで表示させてみると、細かいところであちこち歪んでいるのが確認できる。

これは、ウェイト・マップ以外にもボーンからの距離のフォールオフで変形してしまっているのが原因。オブジェクトの頂点は、接続している一連のボーンによる変形にも影響を受けるので、更に歪みがひどくなる。ウェイト・マップとフォールオフの併用は、モデラーとレイアウトが独立していて二者間を行ったり来たりしなければならないという難点を克服しようと試みたものであり、生物系モデルのアニメーションの場合などはワークフローを改善する。ウェイトの設定が多少雑でもなんとかなるLightWaveの特徴でもあるんだけど、メカの場合はかえって邪魔になる。

そこで、Root、Center、Arm及びShieldの各ボーンのプロパティを次の画像のように変更する。「ウェイトのみ使用(Use Weight Map Only)」にチェックを入れるとボーンのフォールオフの影響をまったく受けなくなる。ただし、無効にも関わらずフォールオフ種はグレーアウトされないので、非常に紛らわしい。

「ウェイト正規化(Weight Normalization)」はデフォルトでチェックが入っているけど、ひとつの頂点のウェイトの合計値が100%を超えないようにするためのもので、今回は100%と0%以外は使っていないので、チェックを入れても外しても変化はない。「固定長の強さで乗算(Multiply Strength by Rest Length)」のチェックは外しておく。

ちなみに、「高速ボーン(Faster Bones)」は影響を受けるボーンを近いものから4本までに限定するもの。ボーンが多くて変形に時間がかかりすぎる場合に使うもので、ここではあまり関係ない。

Null_Boneについては、次の画像のように「ボーン有効(Bone Active)」のチェックを外してボーンそのものを無効にしておく。有効なままにしておくと、モデラーのスケルゴン回転では想定していなかった変形を生じたり、ウェイト・マップを割り当てていない部分全体が回転してしまったり何かしらの影響を与えてしまうことがある。

ボーンの設定が終わると、初期状態で生じていた歪みは解消され、モデラーのスケルゴン回転でチェックしたとおりの旋回を行えるようになる。旋回角度が大きければ大きいほど歪みがひどくなる傾向にあるので、少し回転させて問題ないようなら、デザイン上の制限はともかく180°くらいまで一気に回転させてテストしてみる。これで歪みが解消されているかどうか最終確認ができる。

なお、Shieldボーンが二重になっているように見えるのは、盾を内側と外側に分割して個別に動くように後で改善したため。

完成

以上の方法で多重関節化したモデルが次の画像。大きく前に旋回させても歪みは生じていない。これでLightWaveでも1レイヤー上にデザインした多関節メカのモデルをボーンとウェイト・マップで動かすことができるようになった。

参考記事


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

最終更新:2017/01/13

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

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

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

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

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

morph031

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

morph032

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

morph033 morph034

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

morph035

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

morph041
俯瞰
morph042
仰視

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

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

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

morph030

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

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

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

morph040

この図から、目の正面方向と注視点に対する方向がなす角度\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}を移動させるとグラフの振幅が変動する。

morph036

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

morph038
両目ともモーフ適用量「100%」。視線は交わらずに平行になっている。
morph037
エクスプレッションで視線コントロールをしたもの。左目のモーフ量は「88.78%」、右目は「66.20%」。


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

関連記事


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

最終更新:2016/10/14

モーフィングも昔は高度な技術のひとつだったけど、今では安価な3DCGソフトウェアでも比較的手軽に利用できるようになった。

LightWaveでは、サブパッチやキャトマルといったリアルタイムに編集可能なサブディビジョン技術を備えたことによって、モデル全体のポリゴンを実際に細分化して固定させなくてもローポリゴンのまま、ハイポリゴン状態のモーフィングを実現できるようになった。また、それがモーフであるかどうかをあまり意識しないでモーフ・マップを作成及び編集できる機能を備えている。

ただ、勘違いされがちなんだけど、モーフィングは線形補間なので、ベース・モデルからモーフターゲット(LightWaveでは「エンドモーフ(Endomorph)」と呼んでいる)までは直線的に変形され、何らかの曲線を経由させるような変形や、捻りといった回転系の変形は難しい。よって、関節の旋回を伴う指などに使うことは稀なんだけど、デザイン上、指が少なかったり関節があってもないと見なせるようなデフォルメ風キャラクターなどの場合はボーンを節約してリグを簡略化したい場合は指にモーフを使うこともある。普通は顔の各所の表情や、息を吸ったり吐いたりすることによって胸や腹が規則的に膨らんだり縮んだりするモーションに用いられるのが一般的。

目を閉じるモーフの作成

「マップ」メニューグループにある新規モーフ(New Endomorph)で新しいモーフ・マップを作成する。モーフ・マップ名には、ファイル名やサーフェース名と同様に日本語全角文字(マルチバイト文字)を避けて命名する。

また、マップ名をピリオドで区切ることでモーフ・マップをグループ化することができる。グループ数にはメモリの許す限り特に上限がないので、左右を別々に管理したり、顔のパーツごとではなく「笑い」「怒り」「泣き」など表情ごとに一括管理したければそのようにすることも可能。

ここでは、左右の区別なく、目に関するモーフをすべて「EYE」グループに分類する。左右を区別する時はボーンのように「_L」や「_R」といった接尾辞をつけることで管理する。

morph000

モーフ・マップの種別を「相対」に設定し、「作成」ボタンを押す。なお、モデラーウィンドウの右下に並んでいるボタンから「M」を選択して「(新規)」を選択しても同じ結果になる。ちなみに、「絶対」モーフ・マップというのはベース・モデルの形状に関係なく固定の形状にモーフィングするために使うものだけど、キネマティック・アートやモーション・グラフィックスのようなケースを除くとそんなに使う機会はないかもしれない。

モーフ・マップを作成すると、同時にモーフ・マップ編集モードに移される。LightWave 11から表示が改善され、HUD(ヘッド・アップ・ディスプレイ)が表示されるようになった。すべてのビューの左上に編集中のモーフ・マップ名とその種別、現在編集中を意味するビューを囲む枠が表示されるようになったため、誤ってベースや意図しないモーフを編集してしまうといったミスを未然に防止できる。

morph001

表情に関係ない部分をすべて隠し(Shift+-:「=」キー)、左目が閉じるようにポイントをひたすら調整する。ちょっと顔側のパッチの数が足りなくてまぶたが伸びきってしまったけど、まだなんとかなるレベル。ここでいったんオブジェクトを保存する。

morph002

今度は右目のモーフを作る。左目のモーフを先に作ってしまってから左右対称になるようにモデリングするのは困難だし、そうかと言って両目を対称モードで一度にモデリングしてしまうとウィンクができなくなってしまうので、左目のモーフを複製して作成する。まずは、頂点マップのコピー(Copy Vertex Map)で左目のモーフを単純に複製して「EYE.CLOSE_R」モーフ・マップを作成する。

morph003

このままだと両方のモーフ・マップが左目を閉じるモーフになってしまうので、「EYE.CLOSE_R」モーフ・マップ上の左目のモーフを右目側に反転して複製する。

「ユーティリティ」メニューグループからMMorphプラグインを選択する。「Keep Original Map Value」にチェックを入れると、元になったモーフをそのまま残して複製する。身近なところで言い換えると「コピー&ペースト」に似たような動作になる。チェックを外すと、元のモーフを残さない「カット&ペースト」と似たような動作になる。

morph004

反転して複製してみたところ、右目の閉じ方が左目と同じようにならなかった。原因としては、まつ毛の先端の非常に近い距離に6個ほどあるポイント群を結合していなかったために、ポイントにモーフを適用する順番が狂ってしまったことが考えられる。

morph005

ポイントの位置そのものは左右対称なのでモーフで問題になるとは想定していなかったんだけど、解決策はある。とりあえず、左右ともまつ毛の先端のポイントをひとつに結合してしまう。結合してしまうと先端が尖らなくなるので、先端のポイントをひとつ選択し、「詳細」メニューグループにあるCCシャープネス設定(Set CC Sharpness)を選択する。

morph006

値はいくつでもいいけど、結合前と大体同じくらいの尖鋭度になるように「80%」とした。ここで設定したシャープネス値は「エッジ・ウェイト」とも呼ばれるけど、必ずしもエッジを選択しないと設定できないわけではない。LightWaveに限ったことではないけど、マップ類はすべてポイントで管理されているので、エッジ単位でなければエッジ・ウェイトを設定できないなんてことはない、というのは勘の良い人ならすぐ気付くはず。

再度、左目を閉じるモーフを右目に反転複製する。今度は次の画像のとおり左右対称になった。両目ができたらオブジェクト・ファイルを保存する。

morph006a

レイアウトに移り、アイテムプロパティウィンドウの「変形タブ」を選択し、変位プラグイン追加から「Morph Mixer」を選択する。オブジェクト・ファイルをちゃんと保存していれば、自動的にエンドモーフ(モーフ・マップ)が読み込まれ、レイアウト内のオブジェクトにも反映される。以後、オブジェクト・ファイルを更新する度に自動的にモーフ・マップの増減と変更が反映されるようになるけど、たまにクラッシュするので適宜シーン・ファイルも保存しておく。

morph007

モーフミキサーのプロパティを選択すると、次の画像のような設定パネルが表示される。グループ化した部位が階層化されて表示される。

morph008

パネル左下の「オプション」を選択すると「スライダー範囲を設定」を選択できる。

morph009

モデラーでのモーフ・マップは適用量「100%」の状態を編集しているわけだけど、レイアウトでは適用量を任意の範囲に拡大又は制限できる。極端な話、「1000%」や「-300%」なんていう指定も可能なんだけど、アニメーションとして動かしてみたら思っていたより変位量が足りなかったとか、海外アニメのカートゥーンのようにもっと大袈裟にしたいといったケースに対応するためのもので、動きの範囲が限られている人間の表情モーフを作る上では使う機会はほぼないと言って良い。最低値を「0」にしておいてもいい。

morph010

両目のモーフ適用量を100%にしてテスト・レンダリングしてみたところ、まぶたの裏にあるはずの目が見えてしまい、寝ている人にマジックで目を落書きされてしまったみたいになってしまった。理由は明快で、SSSの深度を100mmとありえないくらいの値にしているために、皮膚の表皮にあたる半透明部分が想定よりも深くなっていて、目が透けて見えている。

morph011

SSSの設定を見直すのが一番いいんだけど、一応悪あがきとして目の位置をモーフ・マップを利用して頭の中まで後退させるという方法を使ってみた。次の画像のように、まぶたに目は映らなくはなったんだけど、眼窩にぽっかりと穴が開いているのは変わらないため、結局眼窩の影がまぶたに映り込んでしまうという結果になった。

morph012

遠景なのであまり目立たないけど、顔をアップにすると細かいところに問題が起きているので、いずれにせよSSSの設定は近いうちに見直さなければならなかった。

ひとまず、Epidermis DistanceとSubdermis Distanceを「10mm」に修正した。

morph013

SSSを修正してレンダリングしたのが次の画像。影の境界線がやや鋭くなって肌がマットな感じになってしまったけど、モーフで問題が起きるのを回避するにはこのくらいにする必要がある。また、影が鋭くなってしまう問題についてはライティングの方向を見直すことで少し改善できる。

morph014

口を閉じるモーフの作成

同様にして、口を閉じる「MOUTH.CLOSE」モーフ・マップを作成していく。まぶたは筋肉と皮膚だけでできていて骨は入っていないので顔の輪郭には影響しないんだけど、口の場合は開閉によって顎の骨が動くため、顔の輪郭にも影響が出る。

最初は強引に下唇を引き上げて口を閉じようとしてみたけど、全体的に位置が高く、不自然になってしまった。

morph015

そこで、口を全体的に下げてみた。多少は顔のパーツの配置のバランスは改善したけど、顎が長く面長に見えるのはあまり改善しなかった。二次元アニメでは口と顎が必ずしも連動しているわけではないので、輪郭をいじらないようにモデリングする方法もないことはないけど、口が開いている状態を先にモデリングしてしまったので輪郭をいじらないほうが無理がきてしまった。

morph016

更に、口が完全に閉じるまでモーフ・マップを調整し、下顎を少し上げて顔の輪郭を整えた。しかし、今度は口が完全に閉じてしまったことでどこに口があるのか判りにくくなってしまった。

morph017

口が開いている状態を基準にしていたスケッチ色の配置を見直し、上唇と下唇を色分けする。その際、異なるスケッチ色が隣り合わないように注意する。スケッチ色が隣り合っていると想定外のところに境界線が引かれてしまう原因になる。

morph018

スケッチ色の再塗り分けが終わったら、次の画像のようにモーフ・マップで口を閉じてみて、唇の上下のスケッチ色が隣り合っていることを確認する。

morph019

再びレイアウトに戻り、unReal Xtreme2のToon Tracerピクセルフィルター・プラグインのパラメータを調整する。口を閉じている状態を基準にスケッチ色を塗り分けたので、今度は口が開いていると輪郭線が引かれなくなる。そこで、境界設定で「深度境界」を追加し、「深度しきい値」をひとまず「50mm」とした。

morph020

「MOUTH.CLOSE」モーフ・マップの適用量100%でレンダリングしてみたのが次の画像。口が閉じていても輪郭線が引かれているのがわかる。口の位置が判りやすくなった。

morph021

次の画像は「MOUTH.CLOSE」モーフ・マップの適用量90%のもの。輪郭線は引かれなくなるものの、口の中の影が赤く見えるようになるので、口が行方不明になったりはしない。

morph022

次の画像は「MOUTH.CLOSE」モーフ・マップの適用量50%のもの。

morph023

次の画像は「MOUTH.CLOSE」モーフ・マップの適用量0%、つまりベース・モデルのもの。これまでは口の向かって右側に輪郭線が引かれていたけど、深度境界を指定したことによって向かって左側に輪郭線が引かれるようになっている。若干口元の印象が変わった気もしないでもないけれど、特に不自然なところはないので、Toon Tracerの設定はこれで仮決めとする。

morph024

表情集

morph026
視線右
morph027
視線左

 

morph028
怒りの表情
morph029
悲しみの表情(要見直し)

関連記事


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しか選択肢がない。

Skirt000

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

Skirt001

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

Skirt002

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

Skirt003

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

Skirt004

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

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

Skirt005

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

Skirt006

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

Skirt007

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

Skirt008

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

Skirt009

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

Skirt010

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

Skirt011

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

Skirt012

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

Skirt013

アポロニウスの円

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

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

2つの点ABからの距離の比が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)ツールを使って簡単に求める。

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

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

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

Skirt015

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

Skirt016

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

Skirt014

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

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

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

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

Skirt017

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

Skirt018

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

Skirt019

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

Skirt020

縦横の模様を合わせる

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

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

Skirt021

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

Skirt022

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

Skirt023

曲線折りの模擬

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

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

Skirt024

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

Skirt025

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

Skirt026

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

Skirt027

すべての段の折り目について、アポロニウスの円を作図するのがもっとも正確な方法なんだけど、(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%まで内側に向かって拡大する。

Skirt028

ウェストの絞り込み

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

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

Skirt029

Skirt029a

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

Skirt030

Skirt030a

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

Skirt031

Skirt031a

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

基本版完成

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

Skirt032

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

Skirt033

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

Skirt034

途中経過

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

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

skirt036

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

skirt037

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

skirt038

関連記事

参考記事


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

最終更新:2016/12/05

手の指にはIK(インバース・キネマティクス)を設定しないで、FK(フォワード・キネマティクス)のままにしてある。手の指はFKにすることが多いというので盲目的にそれに倣っていたわけだけど、なぜ手の指だけはFKのほうがいいのかという理由まではよくわかっていなかった。

最近ようやくその理由がわかった。まったく合理的なもので、FKなら「5本の指をひとつのコントローラで一度に操作できる」から。具体的には、5本指の全関節のボーン旋回をまとめて、ひとつのコントローラ・オブジェクトの回転に追従させるようにする。こういった設定を3DCG分野では一般にコンストレイン(Constrain = 拘束)と言う。

手は狭い範囲に関節が集中するところなのでIKを使いたくなるんだけど、IKの場合それぞれの指先にひとつずつゴールオブジェクトが必要になる。指の折り曲げ方の加減を個別に決められる反面、手を握ったり開いたりするような単純な動作をさせる場合でも単純に5本分の手間がかかる。また、IKを設定した関節の角度はゴールオブジェクトの位置から逆算的に求められるので、ある関節だけ曲げ、ある関節だけ伸ばすといった制御が難しくなる。

コンストレインをうまく利用すると、手のおおまかな握り方はコントローラで決定し、それぞれの指の調整が必要な場合は直接指定といったことができるようになる。ただ、それを実現するためには熟慮した設定が必要になるため、IKよりも手間がかかる。リグというのは本当に奥が深くて、直感的な操作を可能にしようとすればするほど設定は複雑になっていく傾向にある。

本記事ではLightWave 2015のGENOMA2を利用しているけど、標準機能のスケルゴンやボーンを利用しても設定可能。LightWaveでいつからコンストレインができるようになったかは定かではないけど、少なくともLW 9.6の頃には既に使えていた。

ボーンの二重化

単純に5本指を握ったり開いたりするだけで良ければ、既存のボーンの「回転アイテム」にコントローラ・オブジェクトを指定すれば全部の指を同時に操作できるようになる。ただ、そうした場合は文字通り回転アイテムに完全に拘束されてしまうので、個別にヘディングやピッチを直接入力してもその値は無効となり、コントローラ以外の方法で指を操作できなくなる。

そこで、コンストレイン用のボーンを作成し、ボーンを二重化する。次の画像は初期状態。

HandFK000

いずれかのボーンを選択し、Ctrl+Cでコピーし、Ctrl+Vで同じ場所にペーストする。次の画像は中指の根元のボーンを選択した状態。

HandFK001

選択を解除しないで拡大縮小ツール(Shift+H)で適度な大きさまで縮小する。アクションの中心は「選択範囲モード」を使用する。

HandFK002

どのボーンがコンストレイン用なのか判別できればいいので、大きさは任意。あまり目立たないようにと思い、だいぶ小さくしてしまって後で選択しにくくなってしまったので、50%前後がちょうどいいかもしれない。

HandFK003

コンストレイン用のボーンを選択し、スナップドラッグ(Snap)ツール(Shift+G)の数値入力ウィンドウで「全ポイント」を指定する。

HandFK004

本来のボーンの根元にスナップさせる。スナップドラッグではポイントの結合はしないので、浮動スケルゴンになっているけど、理論上はこのままでもコンストレイン用のボーンとして機能する。もののついでなので、指の関節の長さを調節した。指の第3関節の長さを100%とした時、第2関節はその75%、第1関節は更にその75%(つまり、第3関節の56.25%)にすると美しく見えるそうだ。

HandFK005

同様にして、5本指のすべてのボーンに対してコンストレイン用のボーンを作成する。手間のかかる作業だけど、リギング作業というのは究極的にはこういう地味な作業の繰り返しなので、目的に対して作業のコストがかかりすぎると思う場合は省略してもいい。そういった割り切りもリギングのうちとも言える。

コンストレイン用のボーンを作成し終わったら、次の画像のように判別しやすいようなスケッチ色をつけておく。また、余裕があったらGENOMAプロパティの「アイテム」タブでアイテム色を「レッド」に設定しておくとレイアウトでも赤いボーンとして表示されるので視覚的に識別しやすくなる。

HandFK006

GENOMA2を使っている場合は、コンストレイン用のボーンに一括でコントローラを指定できる。上の画像で赤色のボーンを選択し、「GENOMA編集」のセットのドロップダウンメニューから「コントローラ」を選択する。

HandFK007

次の画像は5本指のもっとも手のひらに近いボーンのコントローラ設定。握ったり開いたりする他に、指を揃えたりジャンケンのパーのように開いた状態を実現するためにピッチもコンストレインしている。

HandFK008

次の画像はその他の指の関節に相当するボーンのコントローラ設定。指の途中からピッチ方向に旋回してしまうと骨折したようになってしまうので、ヘディング方向だけコンストレインしている。

HandFK009

GENOMA2を利用している場合は、モデラーでボーンの親子関係を変更しておく。これまで使っていたボーンをコンストレイン用のボーンの子になるように設定し、コンストレイン用のボーンをその前の節のボーンの子になるようにする。GENOMAは親子関係を特に指定してある場合はスケルゴンツリーを無視するので、従来のスケルゴンの接続を切り離す必要はない。

途中で頭が混乱してくるかもしれないけど、最悪レイアウトでGENOMAリグを組ませてみて確認してもいいので、地道に作業する。この親子関係を言葉で説明するとわかりにくいので、次のスケマティックビューを見てもらったほうが理解しやすいだろう。

HandFK027

右手への複製

右手は基本的に鏡面X(Mirror X)で左手を複製するんだけど、GENOMAスケルゴンの場合は内部的に様々な設定が入っているので、ただ複製してリネームしただけだと何かの設定が競合又は衝突するようで、レイアウトでGENOMAリグを編成する際にLightWaveがクラッシュする。

そこで、次の画像のようにいったんGENOMAのタグを消去して通常のスケルゴンに戻した。まさかクラッシュするとまでは思っていなかったので右手のボーンを全部削除してしまったんだけど、よくよく考えてみたらボーン・ウェイトの設定も消してしまったことになるので、従来のボーンは活かしておいて、コンストレイン用のボーンだけ鏡面複製するほうが賢明。もし、原因不明のクラッシュが頻発する場合はGENOMAタグの消去を試してみると改善するかもしれない。

HandFK010

右手のセットアップをほとんどやり直す羽目になったけど、右手も左手と同様に設定した状態が次の画像。

HandFK011

コンストレイン用のボーンにはボーン・ウェイトを設定してなくても大丈夫だとは思うんだけど、左手と重複するウェイトが設定してあるのはさすがに問題なので、スケルゴンツリーで確認しておく。

左手を右手に複製した時にポイントを共有するボーンがすべて結合されてしまったので、ツリーとしてはかなり不可解な状態になっている。GENOMA2を使わない場合は、このままレイアウトにもっていって、親子関係をSceneEditorなどで修正することになる。

HandFK012

スケルゴンツリーの「ウェイトマップ」欄をダブルクリックするとボーン・ウェイトの設定を変更できるので、左手のウェイトが割り当たっている場合は右手のものに変更する。

HandFK013

コンストレインの設定

手を握ったり開いたりする動作は人差し指から小指まで同じヘディングで制御するので設定は同様でいいんだけど、指を水平に開いたり閉じたりする動作はピッチ制御で行うので、中指を基準(0倍)にして外側に行くほど大きくなるように倍率を変えて設定する。次に例示する各設定はGENOMA2を利用した場合のもの。

中指

自分の手を動かしてみればわかると思うけど、指を水平方向に開いたり閉じたりしても中指はほとんど動かない。これを利用してピッチの基準にする。コントローラ・オブジェクトのピッチに影響を受けないように、「x / +」の「x」側を「0.0」にする。

なお、GENOMA2で「回転アイテム」を指定しておくこともできるけど、モデラー上に存在しないアイテム名を指定するとレイアウトでGENOMAリグの作成に失敗する。今回はレイアウトで後付けでコントローラを追加するので「NONE」のままにしている。

HandFK014

GENOMA2を使わない場合は、レイアウトで次の画像のように設定する。「回転アイテム」に指の制御用のNullオブジェクトを指定してある。他の設定は同様なので、中指だけ例示しておく。

HandFK028

薬指

薬指はコントローラのピッチの影響を通常通り受けるので、「x / +」の「x」側を「1.0」のままにしておく。水平方向に開く方をピッチのプラスにしているけど、マイナス方向にしたい場合は「-1.0」にすればいい。

HandFK015

小指

小指は薬指よりも更に外側に開くので、「x / +」の「x」側を「2.0」にし、コントローラのピッチの影響を2倍にする。

HandFK016

人差し指

人差し指は薬指とは反対方向に開くので、正負を反転させる。「x / +」の「x」側を「-1.0」にし、コントローラのピッチの影響を逆にする。

HandFK017

親指

親指が結構難問で、次の画像の設定でもうまくいっているかどうかは今のところなんとも言えない。親指は他の指とは異なり、握り方向がピッチに寄っているので、少なくとも追跡するコントローラの成分を入れ換える必要がある。ヘディングはコントローラのピッチを、ピッチはコントローラのヘディングを追跡するようになっている。右手の場合は更に正負を逆転させる必要が出てくることもあるので、予想しきれなくなったらレイアウトでテストしてみて影響量を判断する。

HandFK018

リグのテスト

レイアウトでGENOMAリグを作成した後、コントローラ用のNullオブジェクトを作成し、コンストレイン用のボーンに参照させる。コントローラの指定はSceneEditorで複数のボーンを一度に選択して右クリック、「操作」-「モーションオプション」でまとめて設定できるので、GENOMAの使用に関わらず片手ごとに1回で済むはず。

なお、コントローラ用のNullオブジェクトは手首のIK用のNullオブジェクトの位置にコンストレインしてある。コントローラはできれば手に近い場所にあったほうがいい。

次の画像はGENOMAリグを作成した直後のニュートラルの状態。赤く見えるのがコンストレイン用のボーン。

HandFK019

次の画像はコントローラのピッチを「10°」に設定した状態。水平方向に指が開いているのがわかる。

HandFK020

次の画像はコントローラのピッチを「-10°」に設定した状態。水平方向に指が揃えられているのがわかる。

HandFK021

次の画像はコントローラのヘディングを「30°」に設定した状態。5本の指が一斉に握る方向に曲がっているのがわかる。

HandFK022

次の画像はコントローラのヘディングを「30°」、ピッチを「-10°」に設定した状態。5本の指が揃えられた状態で握る方向に曲がっているのがわかる。これでコンストレインのテストは終了。

HandFK023

次に、コントローラのヘディングを「80°」、ピッチを「-10°」に設定し、ジャンケンのグーの状態にした上で、コンストレインで拘束されていない青いボーンを選択し、ヘディングを「-80°」にすることで人差し指と親指を伸ばしている。コンストレインで拘束されている赤いボーンは下を向いているけど、強制的に前を向かせているのがわかる。

HandFK024

GENOMA2での親子関係の設定が正しくできていれば、SceneEditorにおけるボーンの階層構造は次の画像のような形になっている。GENOMAを使わない場合は、このようなツリーになるように親子関係を設定する。親子関係を変更することでオブジェクトの形状が崩れてしまう場合はコンストレイン用のボーンのボーン・ウェイトを削除するか、「中心点回転記録」を有効にすると改善することがある。

HandFK025

途中経過

レイアウトでの操作を簡単にするためとは言え、リグを結構本気でやろうとすると非常に手間がかかることがよくわかった。CGアニメーションの制作会社にはリグを専門に担当する技術者がいるというのも納得できる。

ただ、手間はかかるものの、このようなリギング作業を済ませておくと、コントローラ・オブジェクトをひとつ回転させるだけで手の握り具合を簡単に制御できるようになり、指の制御を億劫に感じなくなる。一度この感覚を覚えてしまうと、指を1本ずつ操作するのが非常に面倒に思えてくる。

LightWaveの欠点ともされるボーンとモデルの変更がレイアウトに即座に同期しないという特徴も、考えようによってはボーンやNullオブジェクトの設定をまったく変更しないでモデルのレイヤーだけ入れ換えることで別の人物モデルにリグをすべて移行できるということでもあるため、大変な思いをするのは一度だけでいいという長所にもなる。

HandFK026

指の関節の長さを見直してみたけど、苦労した割にはあまり変わっていない気もする。たぶん、太さや曲がり始める箇所のウェイトの見直しも同時に必要なのだろう。

関連記事

参考記事


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

最終更新:2016/09/06

本記事はボーン下半身IK上半身IKの設定が済んでいることを前提としたものです。設定の詳細は各記事をご覧ください。


ボーンやIKの設定を済ませてしまってから、よくよく測ってみたら腕が短かった、胴体のバランスが悪かった、脚が長かったといった事態は常に起こりうる。全体のバランスを調整すると関節の位置も変動するので当然ながらボーンの位置や長さが変わる。

LightWaveの場合、モデラーとレイアウトが独立しているため、モデラーでスケルゴンを編集するだけではレイアウトには反映されないばかりか、スケルゴン変換やSkelegon Readerを使ってオブジェクトに組み込まれたスケルゴンからボーンを生成するとIKなどの設定はすべて消えてしまい、最初からやり直すことになる。できればそういった二度手間は避けたい。

そこで、LightWave 2015から実装されたGENOMA2を利用して極力レイアウトでのリグの組み直しの手間を減らす方法を考えた。

GENOMA「2」と言うからにはGENOMA「1」に相当するものがあったわけなんだけど、GENOMA2は厳密にはGENOMA1の単なるバージョンアップ版ではない。LightWave 11.5で実装されたGENOMAはプリセットとしてコンポーネント化されたリグパーツを組み合わせることで本来は熟練が必要な高度なリグを簡単な手順で導入できるようにしたもの。それに対し、GENOMA2はそういったリグパーツを根本から開発するためのプラットフォームという位置づけになっている。

最初からリグにGENOMAを使うことを前提としてモデリングしていた場合はいいけれど、既に従来のスケルゴンでリグを組んでしまったモデルには即座に応用できないという問題があった。GENOMAのプリセットには適当なスケルゴン名が付けられているため、それらに名前をつけ、ボーン・ウェイトを割り当てるところから始めなければならず、大幅に戻り作業が発生してしまう。何より、せっかく組んだリグを破棄しなければならないというのは精神的につらい。

GENOMA2を利用すれば、従来のスケルゴンを活かしつつボーン・ウェイトの再設定も発生させることなくリグを新しいものに入れ換えることができる。本来はこういった目的で使うものではないけど、リグを更新するための手段と割り切って使うことにする。

GENOMA2セットアップ

最初はモデラーで操作する。まず、モデルに組み込んであるスケルゴンを抽出し、別のレイヤーに移す。モデルにはスケルゴンを残さない。ポリゴン状態ウィンドウ(Wキー)を利用すると簡単に取り出すことができる。

GENOMA000

スケルゴンだけ取り出した状態が次の画像。これをGENOMA2用のスケルゴン(以下、GENOMAスケルゴン)に変換する。変換後は全部を元に戻すのは困難なので、どこか別のレイヤーにバックアップをとっておくといいだろう。

GENOMA001

すべてのスケルゴンを選択し、「セットアップ」メニューグループにある「GENOMA編集」サブグループの「セット」のドロップダウンメニューから「デフォルトタグ」を選択する。

GENOMA002

しばらく待ち時間があり、計算が終わると次の画像のような、いつものスケルゴンより太めのスケルゴンが生成される。

GENOMA003

従来はレイアウトで実施していたボーンに対する設定をここで行う。対象のスケルゴンを選択し、「プロパティ」を選択すると設定ウィンドウが表示される。一部の設定を除き、一度にひとつのスケルゴンしか設定できない。レイアウトで行える設定はすべて実施できると考えていい。

各所のボーンに上半身IKや下半身IKで行った設定とまったく同じ設定を施す。ここだけはどうしても二度手間が発生してしまうけど、これが最後と思えば少しはやる気にもなるだろう。

「アイテム」タブではアイテム種別(Item Type)の他、ボーンの色や見え方を設定できる。「モデラー形状を無処理(Leave Modeler Shape Intact)」という設定は標準タイプのくさび形のボーンではなく、特殊な形状のボーンとして表示させたい場合に使用する。

GENOMA004

「ギズモチャンネル有効(Active Gizmo Channels)」はレイアウトでアイテムを選択した時に当たり前のように出る移動を示す矢印、回転を示す円といった3軸のGUIコントローラを表示し有効にするかどうかの設定。ゴールオブジェクトをはじめとするコントローラ系のオブジェクトには設定しておかないと直接数値を入力することでしか制御できなくなる。逆に言えば、従来のNullオブジェクトを使ったリグで邪魔だったギズモを表示されないように制限することができるということ。

GENOMA026
位置用ギズモチャンネルの例。特定の軸だけ表示することもできる。

表示にあるとおり、Nullオブジェクトもモデラーで作ってしまえるんだけど、レイアウトでのNullオブジェクトが1点だけの方向のない座標なのに対し、2点を指定するスケルゴンとして作成する必要があり、三次元的なベクトルができる。詳しく調べていないのでなんとも言えないけど、レイアウトに移した時にXYZの3軸が入れ替わってしまうローカルな座標系になってしまい、プラス方向が上なのか下なのかわからなくなってしまってコントローラやゴールオブジェクトとして役に立たないという事態が起きた。

次の画像の「形状」タブではレイアウトでのボーンの表示のされ方を設定する。通常のボーンの場合は変更する必要はない。レイアウトで見やすいようにラベルをつけたり、特別な色を着けたりすることもできるけど、リグに熟達してから使うようにしても遅くない。

なお、上の「アイテム」タブで「モデラー形状を無処理」を選択した場合か、Nullオブジェクトを選択した場合に限り「アイテム形状」で指定した形で表示される。ボーンの場合はレイアウトでのみ形状が変わるというちょっとクセのある仕様。

GENOMA005

次の画像の「ボーン」タブでは、レイアウトでのボーンの「アイテムプロパティ」とほぼ同じ設定ができる。うっかりすると忘れてしまいそうになるウェイト関連の設定をあらかじめしておけるのは助かる。

GENOMA006

次の画像の「IK」タブではレイアウトの「モーションオプション」の「IKとモディファイヤ」タブに相当する設定ができる。ゴールオブジェクトも設定できるんだけど、上でも書いたとおりNullオブジェクトの座標系がいまひとつわかりにくく、レイアウトとは感覚が異なるので、慣れないうちはここで設定してしまわないほうがいい。存在しないゴールオブジェクトを指定するとリグ作成の際にエラーになるので、「NONE」のままにしておく。

GENOMA007

次の3つの画像の「位置」、「回転」、「スケール」タブではレイアウトの「モーションオプション」の「制御と制限」タブに相当する設定ができる。

GENOMA008

次の画像の「回転」タブは重要。IKに関係するボーンの場合は必要に応じてピッチ制御とヘディング制御に「インバースキネマティクス」を忘れずに設定しておく。

GENOMA009

シンプルな人物モデルの場合は次の画像の「スケール」タブで設定することはほとんどないだろう。

GENOMA010

次の画像の「エクスプレッション」タブでは特殊な制御を数式として登録したい場合に使用する。構文が決まっていて、ほぼプログラムと言ってもいいレベルなので、よほど難しいリグを組む場合でない限り使うことはないだろうけど、参考までに。

GENOMA011

次の画像の「スクリプト」タブではGENOMAを利用してリグを編成する際に実行させたいスクリプトを指定できる。これも高度なので利用する機会は少ないと思うけど、GENOMAが実行されている間だけ存在していて、編成が完了したら当該スケルゴンを自己消滅させてレイアウトには表示されないようにするスクリプトなんかを置いておくことができる。

GENOMA012

GENOMAスケルゴンの設定が済んだら、それをコピーしてモデルのあるレイヤーにペーストして組み込む。その後、オブジェクトを保存(Sキー)し、レイアウトに移る。

GENOMAリグの作成

「アイテム」タブの「置き換え」を利用して既存のモデルをGENOMAスケルゴンを組み込んだモデルと入れ換える。既存のボーンを綺麗に削除しておかないとGENOMAでリグを編成する際にエラーの元になる。SceneEditorを開き、Rootボーンの配下に子オブジェクトがないか確認する。

GENOMA013

Rootボーンの配下にオブジェクトがある場合はモーションオプションでモデルの直下に移動させる。上の画像の場合はスカートのオブジェクトがそれにあたる。スカートは物理演算で自然な形になるように設定してあるため、人物モデル本体とは独立している。

GENOMA014

Rootボーンの配下にボーン以外のアイテムがないことが確認できたら、Rootボーンを選択して「選択アイテム消去(-キー)」を実行する。

GENOMA015

次の画像のように確認ダイアログが表示されるので、「はい」を選択する。

GENOMA016

子階層のアイテムをどうするか更に尋ねられるので、同様に「はい」を選択し、Rootボーン以下のすべてのボーンを削除する。

GENOMA017

準備が整ったら、シーンを別名で保存しておく。GENOMAを一度走らせてしまうと不可逆的な変更が加えられてしまい、最悪手がつけられなくなる事態になることもあるため。

ボーンを作成したいオブジェクトを選択し、「リグ作成」をクリックする。ボーンがそれほど多くなくても結構計算に時間がかかる。次の画像のように「GENOMAリグが正常に作成されました」と表示されればひとまず問題なく処理が終了したことになる。

GENOMA018

GENOMAでリグの編成中にエラーが出ると、GENOMAは途中で処理を終了してしまう。次の画像は、存在していないオブジェクトを指定したために出たエラー。仮にシーン内に同名のオブジェクトがあったとしてもGENOMAはそれを識別してくれない。あくまでもGENOMAスケルゴンとして組んだものしか処理の対象にならないという点に注意しなければならない。ゴールオブジェクトをGENOMAスケルゴンにあえて組み込まなかったのはシーンに既に存在するNullオブジェクトを利用したかったから。

GENOMA019

GENOMAの処理が途中で終わってしまうと、ボーンの階層化まで処理が進まずにモデルの配下に同一階層のボーンが並んでしまうこともある。他にもありとあらゆる物が中途半端な状態になるため、手のつけようがなくなる。モデラーに戻ってエラーの原因になった設定を見直す。

GENOMA020

無事にGENOMAリグの作成が済むと、次の画像のようにスケルゴンの階層どおりの整然とした親子関係が築かれる。MASTERオブジェクトというNullオブジェクトが原点位置に必ずできてしまうので、それに相当するオブジェクトが既にあって必要なければ削除しても構わない。

GENOMA021

元のリグに戻すため、モデルをTOP_Nullオブジェクトの配下に配置し直す。

GENOMA022

同様にリグの復元のため、RootボーンをWaist_Nullオブジェクトに追従するように設定する。詳しくは下半身IKの記事を参照のこと。

GENOMA023

次の画像はRootボーンにフォロワーモディファイヤを追加した状態。

GENOMA024

最後に、IKで使用する各ボーンにゴールオブジェクトを指定して完了。IKで屈伸する関節などその他の設定はモデラーで済んでしまっているので、そんなに大した作業ではないはず。

GENOMAリグの更新

モデラーでリグの設定のほとんどを済ましてしまえるのだから、動的にリグを更新できるようになった、と言いたいところなんだけど、実はそれほど簡単でもない。

モデラーでスケルゴンを編集してリグを変更したら、レイアウトにある、その名もズバリの「リグ更新」で変更箇所を反映させられるんだろうかと思うのが人情なんだけど、リグ更新ツールを使うとリグとはまったく関係なくても「オブジェクト」と名のつく物はすべて消去されて最初から構築し直されてしまう(ライトやカメラは残る)。つまり、当該ツールはモデルに組み込んだリグを何もないシーンでテストする時にしか使えないということ。リファレンス・マニュアルにもそのように書いてあり、LightWaveの仕様なのでこればかりはどうしようもない。

そうかと言って、既に組んでしまったシーンに存在するモデルのリグこそ更新したいと思うのは自然な欲求。そういう場合は、リグ更新ツールを使うのではなく、モデルを新しいものに入れ換え、再度「リグ作成」を実施する。その際に、ボーンはもちろんのこと、MASTERオブジェクトも削除しておかなければならないし、GENOMAを使用すると自動的に追加される次のような名前のオブジェクトも削除しておく必要がある。実態は把握していないけど、おそらくコントローラやエクスプレッションに関する設定が入っているか、他のソフトウェアとの互換を図るためにあるものだと思う。

  • Anima_Data_Counter_FK@0
  • Anima_Data_Counter_SaIControl@0
  • Animation_Data_Counter

GENOMAが自動的に作成したものをすべて削除してしまえば、再度リグ作成を実行できる。頻繁にリグを見直す可能性がある場合は、素直に新規シーンで個別にテストしたほうが無難。

途中経過

この画像だけではわかりにくいと思うけど、腕を少し長くした。本文ではまったく触れなかったけど、GENOMAプリセットに用意されている人物用のリグは構造があまりにも複雑でちょっと使う気にならなかった。本気でアニメーション完全対応のリグを組むとこうなるよ、という教材としては参考になりそうなんだけど。

GENOMA025

関連記事


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

最終更新:2016/09/06

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

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

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

Cilia000

まつ毛のモデリング

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

Cilia001

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

Cilia002

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

Cilia003

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

Cilia004

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

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

Cilia005

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

Cilia006

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

Cilia007

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

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

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

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

Cilia008

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

Cilia009

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

Cilia010

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

Cilia011

途中経過

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

Cilia012

関連記事


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

最終更新:2016/09/06

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

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

概念図

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

Pupil018
平面状の目

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

Pupil019
すり鉢状の目

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

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

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

Pupil000

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

Pupil001

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

Pupil002

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

Pupil020

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

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

Pupil003

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

Pupil004

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

Pupil005

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

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

Pupil006

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

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

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

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

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

Pupil007

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

Pupil008

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

Pupil009

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

Pupil010

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

Pupil011

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

Pupil012

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

Pupil013

サーフェースの設定

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

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

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

Pupil021

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

Pupil022

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

Pupil023

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

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

Pupil024

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

Pupil025

レンダリング比較

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

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

Pupil014
すり鉢状の目

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

Pupil015
平面状の目

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

Pupil016
すり鉢状の目
Pupil017
平面状の目

途中経過

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

Pupil016

関連記事

参考記事


LightWaveで二次元キャラ系人物モデリング奮闘記 ―続・髪の毛 HairBlade編―

最終更新:2016/09/06

最初に作った髪の毛を破棄し、作り直すつもりで仮にかぶせていた髪の毛を本格的にモデリングし直す。

LightWaveでもZBrushのように曲線で髪の束を管理できる機能があったらいいのになぁ、と思って調べていたら、意外と身近にあった。unReal Xtreme2と同じ開発者によるHairBladeというプラグイン。短冊状のポリゴンから髪の毛を作成することを想定したものだけど、工夫次第ではどんな髪型にも応用できる。

LightWave用としては極めて珍しい常駐型のプラグインで、曲線を編集することでリアルタイムに髪型を確認しながらモデリングできる。LightWave 8.xかLightWave 9.x以降の使用を想定したものだけど、LightWave 2015でも問題なく動作する。HairBladeUtilityプラグインも併せてインストールしておくと作業効率を改善できる。

次の4種類のプラグインは頻繁に使うのでユーザーメニューに登録しておく。HairBladeプラグインの中核であるHairBlade PolygonHandlerはインストールした瞬間からモデラーに常駐して動作を開始する。

  • CurveToBlade
  • Blade Edit
  • Blade Freeze
  • HairBlade Manager

これまでサブパッチで1週間単位の時間をかけても納得のいくものができなかったのに対し、3日ほどでイメージに近いものをモデリングできるようになった。これまでは髪の毛のことを考えると気が重くなっていたけど、これで髪型の異なる複数のキャラクターをモデリングするのも苦にならなくなる。

HairBladeを作成する

曲線を元にしてHairBladeを作成するので、最低1本はドロー(Spline Draw)ツールで曲線を引く必要がある。X軸方向からYZ平面を見る側面ビューで次の画像のようにX軸座標の0に1本目を引くといいだろう。

HairBlade000

ドローで引く曲線が経由するポイントの数は任意だけど、あまり少なくても後の作業がやりづらくなるので、ひとまず6セグメントになるように7ポイントにした。曲線の始点と終点は接続せず、開いたままにしておく。

HairBlade001

始点はどこから始めてもいいけど、HairBladeは始点から順にコントロール・ポイントをカウントし管理するので、髪の毛の根元側を始点と決めたら以後一貫して変えないほうがいい。

作成した曲線はポリゴンの一種として扱われるので、ポリゴン選択モードで次の画像のように曲線を選択し、CurveToBladeを選択する。

HairBlade002

CurveToBladeを選択すると、次の画像のようなHairBladeをどのように作成するかの設定パネルが表示される。「Shape Type」は断面の形状を選択できるけど、まだ何も登録していないので、ひとまず「Procedural」にする。Proceduralにはデフォルトとして最も単純なV字形断面が登録されているけど、積極的に使う機会はないかもしれない。「Width」と「Height」パラメータは「Shape Type」に「Procedural」を選択した場合のみ有効で、特に変更する必要はない。「Start Cap」と「End Cap」は始点と終点の終端にフタをするかどうかの選択。後からでも変更できる。

HairBlade003

「OK」をクリックすると曲線が特殊な線状ポリゴンに置き換えられ、線状ポリゴンを中心軸として次の画像のようなHairBladeが作成される。HairBladeは浮動ポリゴンとも言える未確定のポリゴンで、見えてはいるけど実在はしていない。実在していないので、ワイヤーフレームを表示できないし、サブパッチを適用することもできない。ポリゴンを加工するツール類もほとんど使用できない。

HairBlade004

断面の登録

次に、髪の毛の断面形状を登録する。別のレイヤーなどで断面として登録したいポリゴンを次の画像のように作成し加工する。登録可能なポリゴンはHairBladeの方向とは無関係にXY平面方向のみに限られる。ポリゴンが傾いている場合でも法線方向とは関係なくXY平面に垂直に投影される。

HairBlade005

登録したいポリゴンを選択し、HairBlade Managerを起動すと次の画像の設定パネルが表示される。「Capture Shape」をクリックすると選択中のポリゴンが「Shape List」の最初の行に追加される。「Comment」欄にどんな形を登録したのかわかるように記録しておくと後のBladeEditで困らなくて済む。

各ポイントに付けられている番号はポリゴンの始点と終点をわかりやすくするためにあり、UVの区切りに関係する。この画像の場合だと0番目と7番目がUVの区切りになる。0番目のポイントの位置の都合が悪い場合は右下の「Flip」の「<」と「>」ボタンをクリックすることで循環させることができる。

HairBlade006

なお、エッジが連続していない複数のポリゴンをひとつのShapeに同時に登録して「polygon」スライダーで選択することもできるけど、ややこしくなるので複数登録はしない方針。

HairBladeを編集する

HairBladeを選択した状態でBladeEditを選択すると次の画像のような「Shape」タブで「Shape Type」を先ほど登録した断面に変更できるようになっている。「Shape Type」を変更すると「Procedural」シェイプ用の「Width」と「Height」の各パラメータは無効になる。

HairBlade007

Shape Typeを変更すると次の画像のようにHairBladeの形状も変わる。Shape TypeはBladeEditでいつでも変更できるので、最初はあまり深く考える必要はない。

HairBlade008

BladeEditで「Point」タブを選択すると、次の画像のように各コントロール・ポイントの各種パラメータを編集できる。始点から遠いほどPoint番号は大きくなる。Shapeで登録した断面のXY方向が表示されるので、「+X Scale」、「-X Scale」、「+Y Scale」、「-Y Scale」の各パラメータで断面の大きさを調整できる。十字に出ているコントロール・ポイントを掴んでドラッグすることでも変更できるけど、最初からあまり細かく設定してしまうと後の調整に手間がかかるので、大雑把でいい。

HairBlade009

次の画像のように毛先の断面のスケールを「0%」、以降を「12.5%」、「25%」、「50%」、「75%」といったようにあらかじめ段階的に設定しておき、コントロール・ポイント間の間隔を広げたり縮めたりすることで髪の途中の太さの調整を行うようにするとBladeEditを逐一起動しなくて済む。髪の束の数が増えてくるとコントロール・ポイントの編集の手間が馬鹿にならなくなってくるので、自分なりのテンプレートを決めておいて例外が発生した場合のみコントロール・ポイントを編集するようにする。

HairBlade010

HairBladeの向きは始点とその次のコントロール・ポイントの2点で結ばれる方向のベクトルで決定されるので、髪型によっては毛先に進むほど意図する方向とはよじれてきてしまうことがある。そういった場合は、次の画像のBladeEditの「Global」タブで「Rotate」や「Twist」にバンク角を指定し、HairBlade全体を傾かせることで改善できることがある。コントロール・ポイント単位でバンク角を指定することもできるけど、管理が難しいのでHairBladeの特性に慣れてからにしたほうがいいだろう。

HairBlade035

断面の変更

もし、編集中にHairBladeの断面形状が思わしくなくて髪型の調整に限界を感じてきたら、再度HairBlade Managerを起動し、「Replace Shape」でいつでも断面形状を置き換えることができる。

次の画像は髪の束の背面のボリューム不足が気になってきたので、背面側のポイントを更に後ろ(-Y方向)に移動した例。

HairBlade011

サブパッチによるモデリングで一番問題だったのは、髪の毛のボリューム不足に気付いた場合や、断面形状を維持できなくなった場合に大変な労力をかけて修正しなければならなかったことなんだけど、HairBlade Managerを使うとどんなにたくさんのHairBladeが存在していても一括で断面形状を変更できる。このプラグインで最も気に入っている点のひとつ。

前髪の形成

HairBladeの断面の設定が済んだら、最初に作成したHairBladeをポリゴン選択モードで選択した上でCtrl+Cでコピーし、Ctrl+Vで同じ位置に貼り付けて移動させ、髪の束を増やしつつ髪型を整えていく。複製(Clone)ツール(Cキー)や鏡面複製(Mirror X/Y/Z)ツールなどの複製系のツールを使うと線状ポリゴンの始点と終点がつながってしまうので、少々面倒でもコピー&ペーストで複製していく。

次の画像のように中心軸のみが表示されているので髪の流れや密度を直感的に把握、調整しやすく、ストレスが少ない。FiberFXにおける髪の束の中心軸となるガイドとして使用するストランドの編集によく似ていて、実に使いやすい。FiberFXは一種のシミュレーションなのでパラメータを上手に設定したとしても実用的な髪の束の太さには限界があるのに対し、HairBladeはポリゴンなので太さに事実上限度がない。

HairBlade012

HairBlade DisplayLevelで浮動ポリゴンを三面図に表示させることもできるけど、サブパッチでモデリングしている時のように表示が見づらくなりやすいので、髪型の確認はパースビューで行うようにし、線状ポリゴンのみで編集している。

HairBladeの編集はBladeEditで行うのが基本なんだけど、パラメータが多くコントロール・ポイントの選択にも若干手間がかかる上、一度にひとつのHairBladeしか編集できないので、ポイント選択モードの編集ツールを併用すると複数のHairBladeを一度に編集でき、大幅に省力化できる。

具体的には、ポイント選択モードで移動(Move)ツール(Tキー)、ストレッチ(Stretch)ツール(Hキー)、軸でポイント整列(Align Points to Axis)ツールなどは通常どおり使える。ある程度ポイントをまとめて斜体(Shear)ツール([キー)も使えるので、毛先を斜めに揃えたい場合や場所によってある程度不規則性を持たせたい時に活躍する。他にもポイントを対象として作用するツールは使える可能性が高い。

もし、途中でコントロール・ポイントが足りなくなったと感じた時はポイント追加(Add Points/Insert Vertex)ツールで好きなところに増やすことができる。追加したコントロール・ポイントのパラメータは前後のコントロール・ポイントから自動的に求められる。

HairBlade013

ただし、HairBladeの線状ポリゴンはポリゴンであって厳密にはポリゴンではないので、ナイフツールで複数のHairBladeを一括で分割したりデバイドでエッジを均等に分割することはできない。その他、エッジやポリゴンを対象とするツール群はほとんど使えないと考えていい。

選択拡張ツール(Shift+])も線状ポリゴンに属するすべてのポイントが選択されてしまうので、連続面の選択ツール(]キー)と同じ動作になる。いくつか制限はあるものの、ポリゴンを曲線で管理できる便利さを知ってしまうとその程度の制限は気にならなくなってくる。

後ろ髪の形成

よほど個性的な髪型でない限り、後ろ髪にも前髪と同じ方法を使っているとHairBladeの向き(ベクトル)の調整に苦しむことになるので、ボール状のプリミティブを下地にして等角度方向に広がる放射状の曲線を量産して省力化する。

頭の1割から2割増しくらいの直径の適当な分割数のボールを作成し、底面の三角ポリゴンが集中している箇所は削除する。また、次の画像のようにデフォルトとは異なるスケッチ色を設定しておく。

HairBlade014

ボールの頂上部分のポイントとその下のセグメントにあたるポイントを選択し、ループ選択(Select Loop)、開いた曲線の作成(Make Open Curve)を連続で選択し、ボールを囲むような曲線を作成していく。作成された曲線は次の画像のようにデフォルトのスケッチ色で表示されるので、曲線を作成したところとまだ作成していないところを視覚的に識別しやすくなる。

HairBlade015

前にも書いたけど、ループ選択にはショートカットキーが割り当てられていないので、「˜」(Shift+^)に割り当てている(日本語キーボードには書いてないけど、BackSpaceキーの2つ隣り)。開いた曲線の作成をそのすぐ下の「`(グラーブアクセント記号)」(Shift+@)キーに割り当て、隣り合うキーにショートカットを割り当てることで、Shiftキーを押しながら連続で素早く曲線を作成できるようにしている。

作成できたら、次の画像のようにポリゴン状態ウィンドウ(Wキー)で「曲線」のみを選択する。

HairBlade016

作成した曲線をすべて選択した状態が次の画像。スクリーンショットではわかりにくいけど、曲線の始点を示す緑色の小さい円が頂上に表示されている。ループ選択を使用していても、ポイントが下から順に選択されてしまうことがあるので、始点と終点が予想と逆転していないかここで確認しておく。逆転していたら、ポリゴンの反転(Flip)ツール(Fキー)で始点と終点を入れ換えることができる。

HairBlade017

なお、邪魔なら下地にしたボールは削除してしまっても構わない。

選択した曲線をコピーし、HairBladeで前髪を作っているレイヤーにペーストする。

HairBlade018

新しく後ろ髪としてペーストした曲線を選択し、CurveToBladeでHairBlade化する。

HairBlade019

いずれかひとつのHairBladeのコントロール・ポイントのスケールなどを設定し、HairBladeUtilityプラグインのBladeKnotsCopyでHairBlade1本分のコントロール・ポイントの設定を丸ごとコピーする。これで他のHairBladeにBladeKnotsPasteでペーストできる。BladeKnotsPasteにはEdge、Mirror、Repeat、Resetの4種類があるけど、1本分丸ごとコピーする場合はどれでもいい。BladeKnotsPasteの違いを詳しく知りたい場合は公式マニュアルを参照のこと。基本的な考え方はタイル状テクスチャ・マップの繰り返し設定と同じ。

HairBlade020

HairBladeの複製

HairBladeの複製は基本的にコピー&ペーストで行うと上で書いたけど、主に省力化のためにどうしても左右対称に一括で複製したい場合がある。注意点に気をつければ一括複製はできる。

例えば、後ろ髪の内側に頭髪全体のボリューム不足を補うためのもうひとつの後ろ髪レイヤーを作りたいとする。右半分までは自力で作ったものの、左半分も手作業で作っていくのは負担になる。それほど芸術的なモデリングを必要とするところではないので、できれば右側を左側に複製して省力化したい。

HairBlade021

右側のHairBladeをすべて選択し、コピー(Ctrl+C)して同じ場所にペースト(Ctrl+V)する。そのまま選択を解除せずに反転(Flip It)ツールを使用してX軸を中心に反転する。ポリゴンの裏表を反転するツールとは異なるので注意。

HairBlade022

反転した直後の状態が次の画像。HairBladeの先端と根元の間に右側とは異なる浮動ポリゴンができてしまっている。

HairBlade023

三面図で見ると、次の画像のように始点と終点が閉じてしまっているのがわかる。これがHairBladeに不規則な浮動ポリゴンができてしまっている原因。反転ツールに限らないんだけど、複製系のツールは複製後に曲線の始点と終点を閉じようとするものが多い。

HairBlade024

ただ、内部的にはバッチコマンドのように始点と終点を閉じるステップが独立していることがほとんどなので、アンドゥ(Ctrl+Z)で1ステップだけ戻すと始点と終点が開き、次の画像のように不規則な浮動ポリゴンは表示されなくなる。

HairBlade025

三面図を見ると次の画像のように始点と終点を閉じていた線分が取り除かれているのが確認できる。これで複製ができる。ここでは後ろ髪を例にとったけど、もちろん前髪でも左右対称にしたい箇所がある場合はこの方法で複製できる。

HairBlade026

HairBladeのポリゴン化

HairBladeを編集して次の画像のように所望の髪型に仕上がったら、浮動ポリゴンを実在のポリゴンとして確定する。

HairBlade027

BladeFreezeを選択すると同一レイヤーに次の画像のように確定したポリゴンが生成される。HairBladeはそのまま残っているので、確定したポリゴンのみを選んで別のレイヤーに移すことになる。

HairBlade028

HairBladeの浮動ポリゴンには直接色を着けることはできないんだけど、HairBladeの線状ポリゴンにはマテリアルを設定できるので、髪の毛に使うサーフェースが既に決まっている場合はあらかじめそのサーフェースを色・質感(Change Surface)(Qキー)で設定すると浮動ポリゴンにも間接的に着色できる他、BladeFreezeで確定したポリゴンにもそのサーフェースが自動的に引き継がれて設定される。

HairBladeの線状ポリゴンにはスケッチ色を指定することもできるけど、確定したポリゴンにはそのスケッチ色は引き継がれず、デフォルトのスケッチ色が強制的に設定される。これを逆に利用し、HairBladeと確定したポリゴンを分離する。ポリゴン状態ウィンドウで「面」だけを選択しても場合によってはHairBladeがくっついてきてしまうこともあるので、スケッチ色で区別したほうが確実。

HairBlade029

必要に応じて次の画像のようにサブパッチを適用する。断面形状にもよるけど、総じてサブパッチを適用すると髪の束の太さが痩せる傾向にあるので、髪の束の間に隙間があいてしまうなど不都合が発生した場合は必要なHairBladeをすべて選択し、BladeEditで「Global」タブの「W Scale」と「H Scale」を調整するか、HairBladeを編集し直す。

HairBlade030

問題なさそうなら、次の画像のようにビューをウェイトシェイドに変更し、頭に相当するボーン・ウェイトを設定する。

HairBlade031

「マップ」メニューグループにあるMAP値指定(Set VMAP)ツールを選択し、ここでは頭のボーンである「Head」を指定し、髪の毛全体に100%のウェイト値を与える。

HairBlade032

100%に設定すると次の画像のように全体がオレンジ色に染まる。どこのボーン・ウェイトにも属していないポイントがあるとレイアウトで表示が大幅に崩れるので、とにかくなんでもいいのでウェイト値を指定しておく。

HairBlade033

ここまでできたら、体のモデルやボーンがあるレイヤーに髪の毛をコピーし、オブジェクトを保存した後、レイアウトでレンダリングする。

ハネ毛やアホ毛

今回の例では基本に忠実に菱形の断面を利用したけど、俗に「ハネ毛」とか「アホ毛」と呼ばれる二次元イラストや漫画に特有の細長い髪の毛を再現したい場合は円形の断面を使用したほうがいい場合もある。HairBlade Managerを使えば必要に応じていくつでも断面形状を登録できるので、目的に応じて使い分けるといいだろう。

HairBlade034

ただし、これらの断面形状はオブジェクトのデータとしては一緒に保存されないし、LightWaveのバージョンをアップグレードした場合にも引き継がれないので、「Export All Shape」と「Import All Shape」を使ってデータを移行するか、「Capture Shape」で再登録する必要がある。また、使用中の断面形状を単純に削除すると、リストの行がひとつずつ繰り上がるので、BladeEditで断面形状を再度設定し直す手間が生じるので注意が必要。

途中経過

バナナ状の髪の束を並べてモデリングしていた時には試行錯誤を繰り返しながらあんなに苦労してもまったくイメージ通りのものが作れなかったし、作れるような気さえしていなかったのに、HairBladeを使ったらこうもあっさりとできてしまって自分でも驚いている。やはり髪の毛は曲線で直感的に管理できるのが大事だと痛感した。

HairBlade036

応用

HairBladeはその名のとおり髪の毛のモデリングを想定しているものだけど、断面形状の維持に着目して設計されているので、髪の毛以外の棒状や筒状のものを効率よくモデリングするのにも適している。

例えば、断面形状を維持しながら刀身に絶妙な弧を描かせたい日本刀をはじめとする曲刀のモデリングが典型だろう。直刀でも断面形状が複雑なファンタジックなものをモデリングするのにも利用できるだろうし、曲がりくねった杖のようなものをモデリングすることもできるだろう。

メカのモデリングでも、何らかのパイプを特定のポイントを経由して立体的に配管した後、2点間を接続したい場合にも活躍しそうだ。パイプの配管というのは標準ツールだけでは意外と手間取る。

関連記事

参考記事


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に入力するだけでいい。

SSS000

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

SSS001

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

SSS002

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

SSS003

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

LightWave 2015.x

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

SSS004

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

SSS011

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

SSS005

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

SSS010

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

SSS006

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

SSS007
LightWave 2015
SSS003
LightWave 10

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

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

SSS008

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

SSS009

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

途中経過

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

SSS007

関連記事

参考記事