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

最終更新:2019/05/09

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

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

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で二次元キャラ系人物モデリング奮闘記 ―手指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で二次元キャラ系人物モデリング奮闘記 ―瞳編―

最終更新: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で二次元キャラ系人物モデリング奮闘記 ―肌の質感編―

最終更新: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

関連記事

参考記事

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シェーダを先に指定しても同じ結果が出力されるように調整されている(古いバージョンでは順番によって結果が異なる場合があるという特徴があった)。

unReal000

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

unReal001

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

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

unReal002

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

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

unReal003

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

unReal004

EdgeTracerシェーダ

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

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

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

unReal005

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

unReal006

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

unReal007

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

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

unReal008
サーフェース貫通なし
unReal009
サーフェース貫通あり


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

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

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

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

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

unReal021

ToonTracerピクセルフィルター

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

unReal010

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

unReal011

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

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

unReal012

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

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

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

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

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

unReal013

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

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

unReal014

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

unReal019
クラスタ境界未設定
unReal020
クラスタ境界「スケッチ色」指定


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

unReal015

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

unReal016

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

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

unReal017

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

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

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

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

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

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

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

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

「グループ境界」と「法線の折り目」をOFF(パースペクティブ・カメラ)

「グループ境界」と「法線の折り目」をON(上と同じ画像)


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

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

途中経過

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

unReal018

関連記事

参考記事

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

最終更新:2016/09/06

現状、スカートは次の画像のようになっている。とりあえず足がスカートを突き抜けたりはしていないけど、足のボーン・ウェイトにスカートを巻き込んで無理矢理変形させているだけなので、不自然さが拭えない。

ClothFX000

解決策はいくつかある。

  1. スカートのみを別のオブジェクトとして分離してポーズに合わせて固定モデリングする方法。
  2. スカート専用のボーンを新たに組み込み、ボーン・ウェイトを適用して変形させる方法。
  3. スカートに物理演算を適用してポーズをとった後の体のラインに半自動的に沿わせる方法。

1.は服のしわなどを緻密に作り込みたい場合に向いているけど、主にフィギュア向けの方法なので、ここでは使わない。2.はローポリゴン・モデルでよく使われている方法だけど、ここでまたボーン・ウェイトを使うのも芸がない。そこで、3.の物理演算を利用してなんとかしてみる。

スカート用オブジェクトの用意

現状では次の画像のように、スカートは体や他の服装と一緒のレイヤーにひとつのオブジェクトとしてまとめられている。

ClothFX001

スカートのみを選択して切り取り、別のレイヤーに保管しておく。仮にもボーン・ウェイトが既に設定してあるものなので、単純に削除してしまうと後でやっぱり必要になったという時にウェイトの設定をやり直さないといけなくなる。

ClothFX002

体をモデリングした時の初期段階のまま放置してあって下着などをちゃんと作ってないので、とりあえず裸に見えないようにサーフェース色を変えてある。直接見えないところは後回しにしていたわけだけど、いい加減このへんの作り込みもしないといけない段階になってきた。

保管したスカートを元にして物理演算用のスカートを加工する。オブジェクトに厚みがあると物理演算の際に色々と大変なので、ウェスト部分を除いて裏地を削除し、両面の1枚ポリゴンにする。両面になっていないと足にスカートの影が落ちないので注意。サブパッチがかかっているので、レイアウトではもっと多ポリゴンのオブジェクトとして扱われる。このスカートのオブジェクトを「ハイポリゴン・スカート」とする。

ClothFX003

ウェスト部分のポイントを選択し、ポイントセットで選択セットを登録しておく。

ClothFX004

セット名は「Skirt_Waist」とした。この選択セットは物理演算の時に動かない箇所を指定するのに用いる。

ClothFX005

更に上で加工したハイポリゴン・スカートを複製してまったく同じ形のスカートを別のレイヤーに作る。この際、必ずサブパッチを解除しておく。これを「ローポリゴン・スカート」とする。

ClothFX006

今回は簡単な形状のスカートだったので、単にサブパッチを解除しただけのものをローポリゴン・スカートとしたけど、大きさが同じであれば、細部は異なっていても問題ない。

ポイントセットを作った後で複製していれば、ローポリゴン・スカートにも同様の選択セットができている。一応、念のため「Skirt_Waist」選択セットで選択できるか確認しておく。

ClothFX007

以上でモデラーでのオブジェクトの用意は終了。ファイルを保存する。

ClothFX単体の設定

まずはハイポリゴン・スカート単体でClothFXを試してみる。レイアウトに移り、0フレームでハイポリゴン・スカートを呼び出す。モーションオプションで指定する親アイテムはRootボーンがいいだろう。Rootボーンの位置がリグの腰コントロールの設定によって原点になっていない場合は、Rootボーンの座標を参考にして体の位置に合うようにスカートの位置を決める。大抵はZ軸座標を足すか引くかすれば体の位置と一致させられるはず。

ClothFX008

次に、体のオブジェクトに衝突判定用の物理演算を追加する。体のアイテムプロパティから「物理演算」タブを選択し、「Collision」を追加する。パラメータは次の画像のとおり。「Radius/Level」をあまり小さくしすぎると衝突判定が起こらずに貫通してしまうこともあるので、適度にマージンを確保しておく。「Bounce/Bind power」は「100%」が基準。スカートが足に当たってゴムボールのように跳ね返るわけではないけど、あまり小さいと足がスカートを貫通しやすくなる。

ClothFX009

ハイポリゴン・スカートにも物理演算を設定する。ここでClothFXを追加する。

「Fix」にスカートの加工で作成したポイントセットを指定する。「Skirt_Waist」ポイントセットがドロップダウンメニューから選択できるようになっているはず。
「Weight」は単純に重量のことでウェイト・マップとは直接関係ない。1.0がデフォルトだけど、衣服に使うような軽い布の場合は「0.1」~「0.3」程度の低めがいいようだ。
「Viscosity」は粘性、「Resistance」は抵抗のことでこれらの値を大きくすると布の変形を遅らせることができるようになるけど、1.0より小さい値にしても変形が早まるわけではなく、むしろ変形が逆流するようになるので「1.0」が最低値と思ったほうがいいようだ。
「Hold Structure」は構造を維持しようとする力、「Sub Structure」は構造を分散させようとする力。説明が難しいけど、「Sub Structure」は「Hold Structure」の範囲内で規則性を乱すといった感じか。「Hold Structure」が高すぎると伸縮性がなくなるので足とスカートの衝突判定に関係なく足がスカートの裾から出てしまいやすくなる。

ClothFX010

各パラメータには「Fx」というドロップダウンメニューがあり、それぞれオブジェクトに設定したウェイト・マップを利用して場所によって強度を調整できるようになっているけど、今回は省略。ClothFXの挙動はただでさえ難解なので、最初は基本設定だけで試してみることをおすすめする。

「Collision」タブはスカート側の衝突判定設定。「Collision Detect」を「<all>」に設定し、「Collision Offset」もやはり適度に確保しておく。「Bound」は「100%」でなくてもいいけど、「0%」にしてもそれほど大きくは変わらない。

ClothFX011

「Advanced」タブはデフォルトのままで変更しない。

ClothFX012

「Etc」タブもデフォルトのままで変更しない。重力の設定は厳密には必要なんだろうけど、ClothFXの利用目的がスカートの型を維持させたいくらいのものであれば特に設定する必要はない。

ClothFX013

最後にハイポリゴン・スカートの「ジオメトリ」タブを選択し、「サブディビジョン手順」を「一番終り」に設定し、「表示サブパッチレベル」が「3」、「レンダーサブパッチ」レベルが「3.0」になっていることを確認する。

ClothFX015

再び「物理演算」タブに戻り、「演算」ボタンをクリックして演算を開始する。サブディビジョンをする前のスカートに対して演算するため、それほど長くはかからないはず。もし、演算に時間がかかりすぎて待ちきれないようなら次節の「FX_MetaLinkを使って演算時間を短縮する」を試す。

演算が終わったら、「Save Motion」で必ずモーションをファイルに保存しておく。これを忘れると、せっかく演算した結果が消えてしまい、フレームをレンダリングしても演算結果が反映されない。

ClothFX014

演算結果を反映したスカートが次の画像。これで特に問題ないならばシーンを保存する。たまたま良好な結果が得られてしまったけど、これでいつもうまくいくとは限らない。

ClothFX016
サブディビジョン手順:一番終り、表示サブパッチレベル:3、レンダーサブパッチレベル:3.0

単体ClothFXの試行

試しに、次の画像のようにハイポリゴン・スカートの「サブディビジョン手順」を「一番初め」に設定して演算してみる。演算時間が非常に長くかかるようになる。

ClothFX017

演算を中断し、大体同じくらいのフレームをレンダリングしてみたのが次の画像。サブディビジョン手順を「一番終り」にしたものと比較すると結果の差は一目瞭然。サブディビジョンが最初に実行されてしまうので、エッジが細かくなることで布として変形できる箇所が多くなり、くしゃくしゃな結果になる。

ClothFX018
サブディビジョン手順:一番初め、表示サブパッチレベル:3、レンダーサブパッチレベル:3.0

物理演算としては正しいのかもしれないけど、いきなり細かい計算が始まるので極端に時間がかかる上に出力も良好でないとなるとサブディビジョンを最初にするのは賢明ではないということになる。

演算時間を短くするには、演算対象のポリゴンの数を減らせばいいんだけど、表示サブパッチレベルとレンダーサブパッチレベルが一致していないと問題が起こることがある。

表示サブパッチレベルを「1」、レンダーサブパッチレベルを「3.0」とし、サブディビジョン手順を「一番初め」にしてみる。

ClothFX019

演算そのものは速くなるし、レイアウトの表示では問題ないように見えるけど、レンダリングすると次の画像のようにスカートの表面がめくれたり逆立ってしまったように大きく乱れてしまい、とてもではないけど見るに堪えないものになってしまう。

ClothFX020
サブディビジョン手順:一番初め、表示サブパッチレベル:1、レンダーサブパッチレベル:3.0

表示サブパッチレベルとレンダーサブパッチレベルは同様で、サブディビジョン手順を「一番終り」にしてみる。

ClothFX021

演算速度は変わらず、次の画像のように表面の処理そのものは改善した。もっとも、だいぶ前に膨らんでしまっていて良好なレンダリング出力とまでは言えない。

ClothFX022
サブディビジョン手順:一番終り、表示サブパッチレベル:1、レンダーサブパッチレベル:3.0

試した範囲ではたまたま許容できるくらいの結果になったけど、表示サブパッチレベルとレンダーサブパッチレベルが一致していないとレンダリングの時に警告が出て演算結果が出力に反映されないことがある。

FX_MetaLinkを使って演算時間を短縮する

ハイポリゴン・スカートだけでは良好な結果が得られなかった場合や、演算時間が許容できないほど長すぎる場合は、ローポリゴン・スカートを併用することでレンダリング出力の改善と演算時間の短縮の両方を図ることができる。この方法は、ClothFXが実装されてさえいればLightWaveのバージョンに関係なく良好な結果を得られる可能性が高い。

まず、ローポリゴン・スカートを呼び出し、ハイポリゴン・スカートと同様にRootボーンを親アイテムに指定する。

ClothFX023

ローポリゴン・スカートのアイテムプロパティを開き、「ジオメトリ」タブを次の画像のように設定する。「SubPatches」の数値が「0」である点に注目してほしい。サブパッチがひとつもないので表示サブパッチレベルとレンダーサブパッチレベルは意味がないように思えるかもしれないけど、ハイポリゴン・スカートのサブパッチレベルと同じかそれ以上のレベルであることが重要。サブディビジョン手順は「一番初め」にしておく。

ClothFX024

ローポリゴン・スカートにサブパッチが適用されていると演算時間は短縮されないし、サブパッチレベルがハイポリゴン・スカートより低いと、次の画像のような陥没が生じることがある。ハイポリゴン・スカートのサブディビジョン手順を「一番終り」に設定しておけば回避できるけど、サブディビジョン手順の初期設定は「一番初め」なので、うっかりするとこのようなミスをしやすい。

ClothFX033
(ローポリゴン・スカート)サブディビジョン手順:一番初め、表示サブパッチレベル:1、レンダーサブパッチレベル:1.0(ハイポリゴン・スカート)サブディビジョン手順:一番初め、表示サブパッチレベル:3、レンダーサブパッチレベル:3.0

ローポリゴン・スカートにClothFXを設定する。ハイポリゴン・スカートにClothFXを設定済みならそれを「File」タブからコピーしてペーストすると簡単に転写できる。「Basic」タブ以外の設定は省略するけど、上で書いた設定と同じ。

ClothFX025

ローポリゴン・スカートは物理演算のためだけに使うので、レンダリング出力に映らないようにScene Editorで「A」欄のチェックを外し、ローポリゴン・スカートそのものをレンダリングの演算対象外にする。

あるいは、次の画像のようにアイテムプロパティの「レンダリング」タブで「オブジェクトディゾルブ」を「100%」、「光線無効」、「カメラ無効」、「ラジオシティ無効」、「フォグ無効」にしておく。光線とカメラが無効なのでそもそも影は生じないから影の設定は任意。

ClothFX026

ハイポリゴン・スカートのモーションオプションで親アイテムをローポリゴン・スカートに指定する。「その場でペアレント(Parent in Place)」がオンになっていれば特に移動させる必要はないはず。

ClothFX027

ハイポリゴン・スカートのアイテムプロパティを開き、「変形」タブで変位プラグインに「FX_MetaLink」を追加する。「プロパティ」かFX_MetaLinkをダブルクリックして「Smoothing」にチェックが入っていれば問題ない。

ClothFX028

FX_MetaLinkは、親に指定したアイテムの変位情報を子アイテムに移し替えるプラグイン。LightWaveには結果の厳格さを求めない代わりに物理演算を簡素化する方法がいくつか用意されている。

ハイポリゴン・スカートの物理演算はすべて削除しておく。

ClothFX029

続けて「現在のオブジェクト」からローポリゴン・スカートを選択し、ClothFXを演算させる。演算が終わったら、「Save Motion」でモーションを必ずファイルに保存しておく。

ClothFX030

ローポリゴン・スカートにはサブパッチが適用されていないため、サブパッチレベルの設定は3ではあるけど実質レベル0と同じなので演算時間を短縮でき、かつハイポリゴン・スカートに適用されたサブパッチにより良好なレンダリング出力を得られる。

ClothFX031
(ローポリゴン・スカート)サブディビジョン手順:一番初め、表示サブパッチレベル:3、レンダーサブパッチレベル:3.0(ハイポリゴン・スカート)サブディビジョン手順:一番終り、表示サブパッチレベル:3、レンダーサブパッチレベル:3.0

途中経過

今回は結構微妙な差なので、比較画像。左がボーン・ウェイトのみ。右がスカートにClothFX使用。歪んでいた裾がだいぶすっきりした。ミニスカートなので特に大きな問題は起きなかったけど、ロングスカートだとどうなるだろうか。

ClothFX032

関連記事

参考記事

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

最終更新:2016/09/06

上半身のIKを設定する。上半身系のボーン構造は次のとおりになっていることを前提とする。手首から下のボーンは今回のIKには関係ないけど、すべて記載した。

  •  Root
    • Spine
      • Breast
        • Chest_L
          • ChestIK_L(IK用)
            • Upper_Arm_L
              • Lower_Arm_L
                • Wrist_L(IK用)
                  • Hand1_L
                    • Finger11_L
                      • Finger12_L
                  • Hand2_L
                    • Finger21_L
                      • Finger22_L
                        • Finger23_L
                  • Hand3_L
                    • Finger31_L
                      • Finger32_L
                        • Finger33_L
                  • Hand4_L
                    • Finger41_L
                      • Finger42_L
                        • Finger43_L
                  • Hand5_L
                    • Finger51_L
                      • Finger52_L
                        • Finger53_L
        •  Chest_R
          • ChestIK_R(IK用)
            • Upper_Arm_R
              • Lower_Arm_R
                • Wrist_R(IK用)
                  • Hand1_R
                    • Finger11_R
                      • Finger12_R
                  • Hand2_R
                    • Finger21_R
                      • Finger22_R
                        • Finger23_R
                  • Hand3_R
                    • Finger31_R
                      • Finger32_R
                        • Finger33_R
                  • Hand4_R
                    • Finger41_R
                      • Finger42_R
                        • Finger43_R
                  • Hand5_R
                    • Finger51_R
                      • Finger52_R
                        • Finger53_R
        • Neck
          • Head

以下、特に断りがない限り、0フレームで操作する。

左腕IKの設定

腕のIK設定のおおまかな流れは足とほぼ同様で、ゴールオブジェクトになるNullオブジェクトの作成、IK用のボーンからゴールオブジェクトを参照する設定、IKで動くボーンの指定、及びIKが及ぶ範囲の限定という4つの手順からなる。

まず、胸の位置に新しいNullオブジェクト「Breast_Null」を作成する。

IK046

Breast_Nullを下半身IKで作成したWaist_Nullの子オブジェクトにする。

IK047

Altキーを押しながらBreast_Nullを移動させ、Neckボーンの根元にスナップさせる。位置が決まったら、モーションキーを作成しておく。

IK048

左腕ゴールオブジェクト

次に、左肩コントロール用のNullオブジェクトを作成する。名称は「ChestIK_Null_L」とした。腕はX軸方向に伸びているので、向きがわかりやすいように「Axis」を「X」にした。

IK049

ChestIK_Null_LをChestIK_Lボーンの根元にスナップさせ、モーションキーを作成する。

IK050

ChestIK_Lボーンを選択する。IK用のボーンでモデルのボーン・ウェイトに極力影響を与えないように短くしているため少しわかりにくいけど、次の画像の位置にある。

IK051

モーションオプション(Mキー)を開き、「ゴールオブジェクト」をChestIK_Null_Lに指定する。

IK052

「Wrist_Null_L」オブジェクトを作成し、Wrist_Lボーンの根元にスナップさせる。

IK053

Wrist_Lボーンを選択し、モーションオプション(Mキー)で、「ゴールオブジェクト」をWrist_Null_Lに指定する。

IK054

左腕IKの屈伸設定

IKで自動的に屈伸するボーンを指定する。左上腕にあたるUpper_Arm_Lボーンを選択する。

IK055

モーションオプション(Mキー)で「制御と制限」タブを選択し、「ヘディング制御」と「ピッチ制御」を「インバースキネマティクス」に指定する。バンク制御は変更しない。肩関節にあたる部分の設定で、腕の垂直方向に上げ下ろしする方向と、水平方向に広げる方向の両方についてIKを有効にする。

IK056

続けて左下腕にあたるLower_Arm_Lボーンを選択する。

IK057

モーションオプション(Mキー)の「制御と制限」タブで「ピッチ制御」のみを「インバースキネマティクス」に指定する。ヘディング制御及びバンク制御は変更しない。肘は曲がる方向が決まっているので、前後に曲げる方向だけに制限する。

IK058

最後に左肩に相当するChest_Lボーンを選択する。

IK059

モーションオプション(Mキー)で「制御と制限」タブを選択し、「ヘディング制御」と「ピッチ制御」を「インバースキネマティクス」に指定する。バンク制御は変更しない。鎖骨にあたる部分の設定で、腕に連動して肩を動かすことができるようになる他、肩で息をするような肩だけ上下させるような動作が可能になる。

IK060

左腕IKの停止設定

再びChestIK_Lボーンを選択し、モーションオプション(Mキー)で「子孫のIK効果を及ぼさない」にチェックする。これでWrist_Null_Lの移動によるIKの影響範囲は肩までに限定される。

IK061

親子関係の設定

作成したNullオブジェクトに親子関係を結ばせる。次の画像をとおり、Waist_Nullの配下にBreast_Nullを配置し、Breast_Nullの子にChestIK_Null_LとWrist_Null_Lを配置する。

IK062

足と異なるのは、肩と手首のNullオブジェクトに親子関係を結ばせないという点。足の場合は足首に必ず爪先が追随してくることを前提としているけど、手首が必ずしも肩に追随しない設定になっている。

右腕IKの設定

左腕の設定を右腕にも設定する。ChestIK_Null_LとWrist_Null_Lをそれぞれひとつずつ複製(Ctrl+C)し、X座標を反転させて右腕のゴールオブジェクトを作成する。名称をそれぞれChestIK_Null_RとWrist_Null_Rに変更し、モーションキーを作成しておく。

IK063

右腕ゴールオブジェクト

右腕のゴールオブジェクトは未設定なので、ChestIK_LボーンとWrist_Lボーンを選択し、それぞれ次の画像のように複製したNullオブジェクトをゴールオブジェクトに設定する。

IK064
ChestIK_Rボーン
IK065
Wrist_Rボーン

右腕IKの屈伸設定

左腕と同様に右腕の各ボーンにIKで自動的に屈伸する設定をする。

IK066
Upper_Arm_Rボーン
IK067
Lower_Arm_Rボーン
IK068
Chest_Rボーン

右腕IKの停止設定

左腕と同様に、肩関節のボーンにIKの及ぶ範囲を設定する。

IK069
ChestIK_Rボーン

上半身IKのチェック

すべての設定が終わったら、シーンを保存する。Wrist_Null_L又はWrist_Null_Rを選択し、XZ平面方向に動かしてみる。肩を軸にして肘が曲がってくれたら成功。手首のNullオブジェクトの移動につられて肩のボーンも動いてしまう場合は肩のIK停止設定を忘れている可能性が高い。

IK070

チェックが終わったら、フレームを0から1に移し、再び0に戻すとWrist_Null_L/Rは初期位置に戻っている。モーションキー自動作成モードにしていると移動したNullオブジェクトの位置に0フレームのキーが作成されてしまうので、別のフレームでチェックする。

スケマティックビューの整理

オブジェクト本体から読み込まれたボーン構造は、最初はスケマティックビューで一列の直線状に並んでいるので、左右にわけて階層構造がわかりやすいように並べ替えておくと後でモデルに動きをつけたい時にボーンやオブジェクトを視覚的に探すのが容易になる。

IK071

ウェイトの正規化

チェックが済んだら一時退場させていたオブジェクト本体を表示し、0フレーム以外の任意のフレームに移動する。一連の操作で作成した各ゴールオブジェクトを動かすとモデルに様々なポーズをとらせることができるようになっているはずだ。

ただ、肩関節など大きく動く箇所でモデラーのVertex Paintで設定したボーン・ウェイトのとおりに変形してくれないことがある。そういう場合は、対象のボーンのアイテムプロパティを開き、次の画像のように「フォールオフ種」が「反比例 ^ 32」になっているか確認し、「ウェイトのみ使用」と「ウェイト正規化」にチェックを入れると大抵の場合改善する。

IK072

回避方法はあるとしても、レイアウトの独立という特徴を持ちながら、モデラーの設定と同期できていないという難点がある。また、標準機能のボーンを使用していると、リグを途中で変更したくなった時に一度すべてのボーンを入れ換えてから再設定しなければならないという問題もある。これらの問題がLightWaveをアニメーション制作用のツールとしての第一線から遠ざけている要因にもなっている。これらの問題を解決するリグ用ツールとしてLightWave 11からGENOMA/GENOMA2が追加されたけど、実用例が少ない上に、詳細に解説した書籍がないため、一般に広く知られた機能とまでは言い難い。

途中経過

IKの効果を端的に示しているかどうかは微妙だけど、背骨にもIKを組み込み、胸を反らした姿勢ができるようになった。また、腰コントロールにより足にポーズをつけても地面との距離の調整が容易になった。今までは何もない空白の空間に立たせていたけど、地面と背景に相当するオブジェクトを追加してみた。足下に影が落ちてようやくCGらしくなってきた。

IK073

補足

今回のIKでは指に関する設定をしていない。指は関節が集中する箇所なので、5本の指にそれぞれIKを設定すれば指先のゴールオブジェクトを動かすだけで良くなり、キーフレームの操作が楽になるだろうと考えるのが人情というもの。しかし、指の関節は他の指の動きによっても動きを制限されたり、力の入れ具合によってはすべての関節が均等に曲がるとは限らないため、IKに適さないことが多い。もちろん、目的によりけりの部分も大いにあるため、アニメーションを作る上で指の動きが大きなウェイトを占めるのであれば、指のモーションの効率化が課題になるので指のIK設定に挑戦してみてもいいかもしれない。

それから、背骨に関するIKの設定もしていない。Breast_Nullオブジェクトはゴールオブジェクトに指定されていないため、上半身をWaist_Nullに追従させることと両肩をリンクさせて同時に動かすためだけにしか使われていない。背骨にもIKを設定すればBreast_Nullをゴールオブジェクトとして胸を反らしたり前屈みの姿勢をとらせることもできるようになる。

手順は多いけど、ボーン単位でテクニカルに設定できるので、一度慣れてしまえばボーン・ウェイトをポリゴン単位で緻密に設定するよりは精神的疲労は少ない。惜しむらくは片側の設定を反対に対称コピーする方法がLightWave標準機能にはないことくらいか。各関節の可動角度の制限も特にしていないので、あまり極端なポーズをとらせると関節が逆に曲がることもあり、これでも必要最小限。

もちろん、IKにも欠点はある。FKは特に何も設定しなくてもモデルをとりあえず動かすことができるのに対し、あらかじめIKを使う設定を一定の手続きに従って済ませておかなければならないし、上位階層の構造が制作者の思ったように動いてくれないケースもある。

IKを設定したからといって万全というわけでもなく、膝を外に向けて歩く「がに股」歩行やバトルシーンのような大胆なアクションには対応できないこともある。爪先のゴールオブジェクトが邪魔に思えることもあるだろう。リギングのみを専門に担当するエンジニアがいると言われるくらいなので、目的に応じたIKの設定が必要になるわけだけど、基礎さえおさえておけば工夫のしようもある。LightWaveではIKで実現できない部分にFKをブレンドすることもできるけど、高度なのでここでは割愛する。

そういった短所があるとしても、部分的にでもIKを取り入れると後の作業効率は劇的に改善する。

関連記事

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

最終更新:2016/09/12

次はレイアウトに移っていよいよIKを設定する。一般には略してIKと呼ばれるけど、正式にはインバース・キネマティクス(Inverse Kinematics)と言い、関節等によって多重階層構造を持つモデルの末端部分の位置を先に決めることによってその上位階層の要素の位置を逆算的に求める技法。

普通、階層構造を持っているモデルの場合は上位の要素から順に位置を決めていかないと末端要素の位置は決まらないものなんだけど、例えば人間の足のように全長が決まっていて基本的に伸び縮みしないものである場合、目測を誤ると足が宙に浮いてしまったり、逆に地面に埋まってしまったりといった事態が起こる。すると、上位階層に戻って調整をやり直すことになり、単に歩くだけの動作ひとつにも非常に手間がかかる。

上位階層から順に位置を決めていく方法をIKに対してFK(Forward Kinematics)と言う。FKはアクション・フィギュアのような人形や人型ロボットのプラモデルにポーズをとらせる時に手足の関節を上から順に曲げていく感覚に近い。ただし、CGの世界には物理演算を使わない限り重力がないため、重心の位置や左右の荷重バランスをとらなくても立ってしまい、作品として捉えた時に違和感のないポーズをとらせるのが逆に難しい。

一方、実際の人間は自分の手を差しだそうとした場合や、足を一歩踏み出そうとした場合に、手や足の未来位置を意識することはあっても、その時に肩、肘、股や膝の関節をどのくらい曲げようかということまでは通常意識しない。IKは「足を持ち上げて50cm前へ進ませる」といった人間にとっては当たり前の動作を上位階層を必要以上に意識せずに実現するものだと思ってもらえれば一番わかりやすい。動画などで反復運動が多い作品を作る際に非常に役立つものだけど、静止画の場合でも有用なことが多い。

準備と前提

IK000前置きはこのくらいにして、レイアウトを起動する。まず最初に、「その場でペアレント(Parent in Place)」がオンになっているかどうかを確認する。オフになっている場合はボタンをクリックし、トグルしてオンにしておく。

これがオンになっていないと、2つのオブジェクトに親子関係を結ばせた時に親オブジェクトの座標を基準とした相対座標が計算されず、子オブジェクトの絶対座標がそのまま相対座標に代入されるため、子オブジェクトの位置が動いて定まらなくなってしまう。親子双方のオブジェクトが原点から離れている場合、子オブジェクトが画面外へ飛んでいってしまうこともあるので、親子関係を設定したと同時にオブジェクトの挙動がおかしくなったらまずこの設定を疑う。

また、普段からモーションキーを手動で作成するのを習慣にしているため、新しいオブジェクトを配置するたびにモーションキーを作成している。自動作成モードにすればモーションキーを作成する煩わしさから解放されるけど、常に自動にしているとモーションキーのことを意識しなくなることがあるので要注意。不自然な動きをする時はキーを手動で作成し直すとオブジェクトの挙動が改善することがある。

なお、記述が煩雑になるのを防ぐため、下半身系のボーン構造は次のとおりになっていることを前提とする。

  • Root
    • Hip
      • Coxa_L
        • Upper_Leg_L
          • Lower_Leg_L
            • Ankle_L(IK用)
              • Foot_L
                • Toe_L
                  • FootIK_L(IK用)
      • Coxa_R
        • Upper_Leg_R
          • Lower_Leg_R
            • Ankle_R(IK用)
              • Foot_R
                • Toe_R
                  • FootIK_R(IK用)

以下、特に断りがない限り、0フレームで操作する。

スケルゴンからボーンへの変換

モデラーでスケルゴンとしてボーンを組み込み、ボーン・ウェイトを設定したオブジェクト本体を呼び出す。体や髪の毛はもちろん、服装も含むオブジェクトのすべての構成要素がひとつのレイヤーにまとめられていて、更にボーンも同一レイヤーに組み込まれていることが前提。

IK001

オブジェクト本体のプロパティを開き、「表示サブパッチレベル」を「1」又は「0」にする。マシンパワーに余裕のあるPCの場合は「3」のままでも問題ないけど、ボーンの旋回などの結果が反映されるまでに時間がかかるので、表示品質は落ちるけど表示サブパッチレベルは下げておいたほうが能率は良くなる。「サブディビジョン手順」は「一番終り」に設定する。サブディビジョン手順をボーンによる変形などの後にすることによって、まっすぐなストローを無理に折り曲げた時のような関節の潰れを防止できる。

IK002

オブジェクトを選択した状態で、「ユーティリティ」メニューグループからプラグインを選択し、「SkelegonReader」を選択する。普通は「スケルゴン変換」を使うんだけど、ボーンを組んだ時にスケルゴンエディターでバンクをZ軸方向に揃えた操作が反映されないため、SkelegonReaderを使う。

IK003

次の画像のようなダイアログが表示されるけど、「Yes」で問題ない。

IK004

ボーンがオブジェクト本体に完全に埋まっている場合は見た目にはわかりにくいかもしれないけど、組み込まれたボーンはモデラーで組んだ階層構造のとおりにすべてオブジェクト本体の配下に設定されている。

IK005

ボーンが読み込まれたら、オブジェクト本体は一時的に必要なくなるので、Scene Editorを使ってオブジェクト本体を「Hidden」に設定して、レイアウト画面に表示されないようにする。

腰コントロールの設定

次に、すべてのオブジェクトの頂点に位置する最初のNullオブジェクトを作成する。「アイテム」メニューグループの「追加」から「Null」を選択する。名称はなんでもいいけど、「TOP_Null」とした。「Shape」は「Ring」、「Axis」は「Y」に設定する。「Scale」はモデルの大きさに対して見やすい大きさにしておく。後でアイテムプロパティの「ジオメトリ」で変更することもできるので、間違ってデフォルト設定で作成してしまっても削除してやり直す必要はない。

IK007

次の画像のように足下にNullオブジェクトが作られた。

IK006

作成したNullオブジェクトをひとつ複製(Ctrl+C)し、名称を変更する。腰の高さに設定するものなので、「Waist_Null」とした。

IK008

Rootボーンを選択し、Y座標をコピーする。コピーした座標をWaist_NullのY座標にペーストする。次の画像はRootボーンを横から見た図。

IK009

Waist_NullがRootボーンと同じ高さになったら、Enterキーを何回か押し、モーションキーを作成する。更に、RootボーンのZ座標をコピーし、同様にWaist_NullのZ座標に貼り付ける。再度モーションキーを作成するのを忘れずに。

IK010

モーションキーを自動作成モードにしている場合は逐一キーを作成する必要はないけど、何か操作する度に勝手にキーが作られてしまうので、操作すべきフレームを間違えた時にキーを削除しなければならず、どちらが便利とは一概には言い難い。

Waist_Nullの座標が決まると、次の画像のようになっている。

IK011

再びRootボーンを選択し、モーションオプション(Mキー)を開く。「モディファイヤ追加」をクリックし、ドロップダウンメニューから「Follower」を選択する。追加できたら、名称欄を右クリックして「プロパティ」を選択する。

IK012

Followerコントロールを開くと、次の画像のように表示される。

IK013

「After IK」のチェックを外し、「Item to Follow」に「Waist_Null」を指定する。また、Z PositionにRootボーンのZ座標を入力する。左下に表示されているので、それをそのまま入力すればいい。メートル単位なので、600mmならば「0.6」と入力する。回転角度やスケールの設定は三角をクリックし、「(none)」を選択して無効にしておく。

IK014

「続行」をクリックすると、RootボーンはWaist_Nullの動きに追随するようになる。

左足IKの設定

足のIK設定のおおまかな流れは、ゴールオブジェクトになるNullオブジェクトの作成、IK用のボーンからゴールオブジェクトを参照する設定、IKで動くボーンの指定、及びIKが及ぶ範囲の限定という4つの手順からなる。

左足ゴールオブジェクト

まず、ゴールオブジェクトになるNullオブジェクトを追加する。くるぶしに当たる箇所に使うので、名称は「AnkleIK_Null_L」とした。形状は「Ball」にしたけど、好みで変更して構わない。後で選択しやすいように大きさは足の幅よりも大きくなるようにする。

IK015

原点に作成されたAnkleIK_Null_LをAnkle_Lボーンの根元に配置する。矢印を掴むとひとつの軸方向にしか動かせなくなってしまうので、中間の円弧あたりをAltキーを押しながら掴み、ボーンの根元にスナップさせる。Ankle_Lボーンは短いので、根元にスナップできているかわかりづらい時は拡大して確認する。位置が決まったらモーションキーを作成する。

IK016

同様にして「FootIK_Null_L」オブジェクトを作成し、Altキーを押しながらFootIK_Lボーンの根元にスナップさせる。しつこいようだけど、モーションキーも忘れずに作成する。

IK017

Ankle_Lボーンを選択し、モーションオプション(Mキー)を開く。「ゴールオブジェクト」に先ほど作成したAnkleIK_Null_Lを指定する。

IK018

同様にFootIK_Lボーンを選択し、モーションオプション(Mキー)で「ゴールオブジェクト」をFootIK_Null_Lに指定する。

IK019

左足IKの屈伸設定

次に、IKで自動的に屈伸するボーンを指定する。太ももにあたるUpper_Leg_Lボーンを選択する。

IK021

モーションオプション(Mキー)で「制御と制限」タブを選択し、「ヘディング制御」と「ピッチ制御」を「インバースキネマティクス」に指定する。バンク制御は変更しない。股関節にあたる部分の設定で、足を前後に持ち上げる方向と、足を左右に広げる方向の両方についてIKを有効にする。

IK020

続けてふくらはぎ又は脛にあたるLower_Leg_Lボーンを選択する。

IK023

モーションオプション(Mキー)の「制御と制限」タブで「ピッチ制御」のみを「インバースキネマティクス」に指定する。ヘディング制御及びバンク制御は変更しない。膝は曲がる方向が決まっているので、前後に曲げる方向だけに制限する。

IK022

足首から下にもIKを設定する。足首から下の足にあたるFoot_Lボーンを選択する。

IK025

モーションオプション(Mキー)の「制御と制限」タブで「ピッチ制御」のみを「インバースキネマティクス」に指定する。ヘディング制御及びバンク制御は変更しないけど、ピッチ制御だけだと足首は曲げ伸ばしの方向にだけしかIKが効かないことになるため、足を大きく投げ出すようなダイナミックなポーズをとらせたい場合などはヘディング制御にもIKを有効にしておく。

IK024

爪先にあたるToe_Lボーンを選択する。

IK027

モーションオプション(Mキー)の「制御と制限」タブで「ピッチ制御」のみを「インバースキネマティクス」に指定する。ヘディング制御及びバンク制御は変更しない。

IK026

左足IKの停止設定

太もものUpper_Leg_Lボーンの更に上位に位置する、腰骨にあたるCoxa_Lボーンを選択する。モーションオプション(Mキー)で「子孫のIK効果を及ぼさない」にチェックする。これは、IKによる足の屈伸が腰から上のボーンに影響を及ぼさないようにするための設定。IKでは「IKによる自動変形をどこで止めるか」という情報が必要になる。言い換えると、IKの固定軸をどこにするかの指定ということになる。

IK028

再びAnkle_Lボーンを選択し、モーションオプション(Mキー)で「子孫のIK効果を及ぼさない」にチェックする。

IK029

親子関係の設定

作成したNullオブジェクトに親子関係を結ばせる。TOP_Nullの配下にWaist_Null、ボーンを含むオブジェクト本体、AnkleIK_Null_Lを配置し、AnkleIK_Null_Lの子にFootIK_Null_Lを配置する。次の画像を見てもらったほうが早いだろう。

IK030

オブジェクトの親子関係の設定にはScene Editorを使うと簡単だけど、うっかり既存の親子関係を壊してしまうと修復に苦労することにもなりかねないため一長一短。モーションオプションの「親アイテム」でも設定できるので、数が少ない場合はこちらを利用したほうが間違いが少なく、結果的に早い場合もある。

IK031

これまでは各Nullオブジェクトが独立していたので何の効果もなかったけど、親子関係を結ばせることにより、TOP_Nullを動かせば全体が移動するし、Waist_Nullを動かせばTOP_Nullに重心は拘束されるもののAnkleIK_Null_Lによって足を地面方向に拘束させて胴体を動かせるようになる。

右足IKの設定

左足の設定を右足にも設定する。AnkleIK_Null_Lを選択し、「階層の複製(Clone Hierarchy)」でFootIK_Null_Lと一緒に複製する。

IK032

TOP_Nullとの親子関係は維持されるので、Scene Editorで確認するだけでいい。

IK033

「AnkleIK_Null_L (2)」と「FootIK_Null_L (2)」をそれぞれ「AnkleIK_Null_R」と「FootIK_Null_R」に名称を変更し、AnkleIK_Null_RのX座標を正負反転させると右足のボーンの上に配置されるので、モーションキーを作成しておく。

IK034

右足ゴールオブジェクト

右足のゴールオブジェクトは未設定なので、複製したNullオブジェクトをゴールオブジェクトに設定する。

IK035
Ankle_Rボーン
IK036
FootIK_Rボーン

右足IKの屈伸設定

左足と同様に右足の各ボーンにIKで自動的に屈伸する設定をする。

IK037
Upper_Leg_Rボーン
IK038
Lower_Leg_Rボーン
IK039
Foot_Rボーン
IK040
Toe_Rボーン

右足IKの停止設定

左足と同様に、股関節と足首のボーンにIKの及ぶ範囲を設定する。

IK041
Coxa_Rボーン
IK042
Ankle_Rボーン

下半身IKのチェック

すべての設定が終わったら、シーンを保存する。Waist_Nullを選択し、Y軸方向に動かしてみる。マイナス方向に動かすと足首の位置はほぼそのままに腰を落とし、膝を曲げてしゃがむような姿勢になる。この時点で足を構成するボーン群の動きが左右で食い違っていたり、膝が逆に曲がったり、爪先の方向がおかしかったりした場合はIKの設定をどこか忘れている可能性が高い。

IK043

Waist_NullをY軸プラス方向に動かすと足を伸ばし、爪先を下に向けてジャンプする。足首と爪先のボーンはゴールオブジェクトのほうを常に向いているけど接着はしていないので、ゴールオブジェクトを離れることができる。MMDで人物オブジェクトが基幹ボーンをY軸方向に動かすだけでジャンプできたりするのもこれと原理は同じ。

IK044

チェックが終わったら、フレームを0から1に移し、再び0に戻すとWaist_Nullは初期位置に戻っている。モーションキー自動作成モードにしていると移動したWaist_Nullの位置に0フレームのキーが作成されてしまうので、別のフレームでチェックする。

途中経過

下半身IK設定完了。下半身のIKが設定されているだけでもポーズはとりやすくなるし、歩行アニメーションを作る時に足が地面から離れないように腰の高さを調節することもできるようになる。

IK045

関連記事

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

最終更新:2016/09/06

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

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

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

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

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

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

LoveMiku000

レイヤーが大量に読み込まれるけど、ほとんどがモーフ用で実際のモデルが保存されているのは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

LoveMiku001

surf001

LoveMiku002

surf002

LoveMiku003

surf003

LoveMiku004

surf004

LoveMiku005

surf005

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

LoveMiku006

surf006

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

LoveMiku007

surf007

LoveMiku008

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

LoveMiku009

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

保存

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

LoveMiku010

レイアウトに読み込む

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

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

LoveMiku011

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

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

LoveMiku012

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

LoveMiku013

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

 

LoveMiku014

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

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

関連記事

BRDFシェーダ

最終更新:2016/09/06

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

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

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

BRDF000

Regularモード

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

BRDF001

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

BRDF002

Anisotropicモード

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

BRDF003

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

BRDF004

AnisotropicⅡモード

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

BRDF005

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

BRDF006

ティーポットで実験

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

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

BRDF008

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

作品への応用

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

BRDF009

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

BRDF010

バグについて

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

関連記事