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

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

関連記事

参考記事