background

いざSSS・後編

2012年03月29日(Thu)

というわけで前回の続き。

3. Scatterノードの役割

それでは一番使用頻度が高(くなるかもしれな)いScatterノードについて見ていこう。Scatterノードは代替拡散に接続する。間に他のノードを挟むのはいいけど、ルートノードの他のパラメータに接続すると計算結果が反映されないので注意しよう。プリセットのMaterialは、ここではSkin 1を選択している。Use_Material_Colorはプリセットの色を拡散色に使用するので、テクスチャを使用する場合はこのチェックを外すべし。

とりあえずテスト形状。他の値はすべて0にしておく。

120329-01

SSSを試そうとして、いきなり人物フィギュアの複雑なツリーに組み込んで、長時間レンダした挙句「効果がよくわからなーい」とか言ったことがある人は反省しよう。なんでまだ効果すらよく分かってないものに対して、そんな効率の悪い方法で時間を掛けられるのかと。

120329-02

レンダリングオプションのSubsurface Scatteringにチェックを入れると、シャドウマップとIDLの計算後、レンダリング前にSSSノードが存在するマテリアルグループだけの計算が入る。まず表面下つまり物質内部をレンダリングして、その結果を元に本レンダリング時は表面の状態がどう変化するかを計算するのだ。

120329-03

Scatterノードを適用した方は、立方体の角の部分を越えて光が側面に滲み出しているのがわかる。側面は光の当たる側が明るくなっているのに対して、正面は逆に角の周辺がわずかに暗くなっている。正面から入射した光が内部で散乱し、正面ではなく側面へ脱出してしまったためだ。

120329-04

側面(暗部)に現れる散乱光の色と量はプリセットによって異なる。Custom Scatterノードの場合は、Scatter Colorで指定することができる。

120329-05

図を見れば、側面(暗部)に現れる色と正面(明部)周辺で暗くなる色は、補色の関係にあることがわかる。出ていった光の成分だけ暗くなるのだから、当然といえば当然だろう。ということは、私たちが普段見ている肌の色は拡散色と散乱色が合わさったもので、実際の肌の色(表面色)は図の周辺部分のようにもっと青白いことになる。

Texture_Detailでは、表面色と内部色の比率を決定する。値が0のとき、Colorに接続された情報はすべて物質内部の色として扱われる。逆に1の場合、物質内部は白色で計算され、Colorに接続した色で計算された拡散光と乗算される。

120329-06

0の方は中に色が練り込まれているように見える。1の方はプリントされた柄っぽいかな。

内部散乱で決定した色は、表面に出てくる時に表面の拡散色と乗算される。ScatterノードではTexture_Detailが1の時、ちょうど接続されたColorの色を再現するように設計されている。そのためTexture_Detailが1未満の場合、中間色がColorの色よりも若干白っぽくなるので注意しよう。

さて、プリセットの一覧を見ると、散乱色の他にもにじみの幅がそれぞれ異なっていることがわかるだろう。Scatterノードでは、プリセットの材質に応じて散乱光の現れる距離も固定されている。通常のシーンでちょうど物理的に正しいにじみ幅になるように設定されているのだ。

しかし、シーンによってはオブジェクトを拡大縮小して使用する場合もある。例えば小人の世界を作る時、シーンの作りやすさを考えれば、人物フィギュアを縮小するより小道具を拡大した方が扱いやすい。しかしそのままでは、小道具の表面下散乱は拡大された後の寸法を元に計算されてしまう。これでは人物フィギュアが小さくなったようには見えない。

120329-07

このような場合に使用するのがScaleパラメータだ。小道具を二倍に拡大して1/2サイズの小人の世界を作るなら、ScatterノードのScaleを0.5にする。すると散乱光の現れる距離がそれまでの倍になる。逆に巨人の世界(小道具を50%に縮小)の場合はScaleを2.0にすると、散乱光の距離が半分になる。これによって拡大縮小されたシーンでも物理的に正しい距離で計算することができる。

120329-08

オブジェクトを拡大縮小しない場合、Scaleは単なるにじみ幅のパラメータと同じになる。プリセットのにじみ幅が気に入らない場合、このパラメータを調節することになるだろう。

120329-09

MaxErrorは散乱光を描画する時の品質を決定する。値が小さいほど精度が高く、速度が落ちる。値か大きければ精度は落ちるが速度は向上する。具体的にはSSSの計算時間ではなく、レンダリング時の時間が伸びる。特に問題なければ初期値のままでいいだろう。

4.人肌のSSSシェーダ

さて、お待ちかねの実践編。といっても、既にSSSを取り入れて試行錯誤している人にはあまり役に立たないだろう。より複雑なシェーダツリーを構築することがテクニックなら、私がやっていることは初級を通り越して初心者レベルだからだ(毒)。

というわけでM4をロード。標準マテリアル(マテリアルコレクションファイル)を当てている。

120329-10

シェーダツリーはこんな感じ。使ってないところは暗くしている。確かV4はもうちょっと複雑だったような気が……。

120329-11

頑張ってるけどP7以前ってカンジの構造だ。環境色に赤を入れ、暗い部分が赤く浮くようになっている。その分通常の拡散色に青を乗算して、明るい部分の赤色が飽和しないようにしているらしい。明るいシーンではそこそこまともに見えるものの、真っ暗な状況で赤黒い人影が現れるという、正直「使えない」構成だ。これ系のマテリアルが流行ったおかげで、キャラアイテムのMATは当てたらまず全見直しという習慣が通常ルーチンとなった(あ、前からか)。

ちなみに誤解してる人がいるかもしれないけど、私が「加算系のノード」という造語で呼んでいるのは、単なる環境色や代替拡散というわけではない。加算に対しては乗算があるわけで、何に対して乗算かというと、ライトの強度である。ライトの強度が乗算されない=真っ暗な時に真っ黒になっていない=一定の値を底上げ(加算)しているノードのことを加算系と呼んでいる。なので代替拡散に繋がれているノードも、ちゃんと陰影付けされるノードは加算とは呼ばない。マップや固定の値を単純に引っ張っていて、真っ暗闇でも描画されるのが加算系である。

何はともあれ、いらないものをばっさりと落としてみる。

120329-12

すっきりした。拡散色は白に、環境値は0にしておこう。

120329-13

あんまり見栄えが変わらないね。今までのはなんだったんだろうね(笑)。

ではここで、代替拡散にScatterノードを接続する。Scatterノードは拡散成分を計算するものなので、通常の拡散値は0にしておく。で、テクスチャをScatterノードのColorに接続。ルートノードの拡散色に繋いでる見本なんかもあるけど、自分はテクスチャシェーディングは使わないので(いちいちマップの再読み込み入って重くなるだけだし)、特に接続はしていない。鏡面は少しだけ青みがかった明るい灰色にして、元のマップとテクスチャから適当に適当にこしらえたのものを接続。ちゃんとしたスペキュラマップがあるならそれを使えばいい。

120329-14

で、レンダするとこんな感じ。目のマテリアルにも手を入れた。

120329-15

せっかくなので新ノードのKs_Microfacetを代替鏡面に接続。代わりに通常の鏡面値は0にする。

120329-16

で、レンダ。

120329-17

SSSの効果が少しキツいなー、と思ったときはScaleを少し大きくするといい。

120329-18

こんな感じかな。Ks_Microfacetの粗さを制御するマップがあれば、スペキュラももう少し見栄えがよくなると思う。たぶんblinnノードにあれこれ繋いで調整するより効果的なんじゃないかな。

果たして。

SSSで必要なことはこれだけである。何か難しいことがあっただろうか?

SSSの計算にかかる時間は、SSSを使わないときの時間に関係する。SSSを使わないときに時間がかかるなら、SSSの時間もかかるのだ。合計すればよりレンダ時間が増大することになる。マテリアルの調整でテストレンダを繰り返す時は、どうしても必須でない限りレイトレースやIDLなどは使わない方がいい。

Texture_DetailやScaleを部分的に調整したくなったら、マップを作ることになるだろう。自分で描き起こしてもいいし、既存のマップに演算ノードを繋いで作ってもいい。どこをどう調整したいかが頭の中にはっきり浮かんでいれば、無駄にノードを重ねる必要はない。本当に必要なノードだけを追加することができるはずだ。中には「本来、拡散反射と鏡面反射の区別はない」という部分を忠実に再現するため、両者を合成して代替拡散に繋いでいる強者な人もいる。何をどう取捨選択するかは個人の自由である。できるなら無駄なく効果的に、なおかつ思想の感じられるマテリアルを組みたいものである。

5. おまけ(Ks_Microfacetノード)

リクエストがあったので、Ks_Microfacetの値の変化の図。パラメータは粗さと強度しかないのでどれぐらいの値でどれぐらいのハイライトが出るのか把握しておけばいいだろう。

120329-19

中央付近と周辺部のハイライトの現れ方の違いに注目。

120329-20

つやつやな物体とさらさらな物体がこれ一つでカバーできる。応用範囲は広いと思う。

120329-21

以上。さー世界だー(何)

スポンサーサイト





いざSSS・前編

2012年03月27日(Tue)

さて。焦らしプレイも堪能したことだし、そろそろSSSの話でもやろうかな(ぉ

先日のPoser 9とPoser Pro 2012の半額セールで、晴れて最新バージョンのオーナーになったという方も多いだろう。レンダが早くなった人もいるだろうし、ウェイトマップを試してみた、という人もいると思う。そんな中で、ひょっとしたら期待の割に大したことなかった、などと誤解されているかもしれない新機能の一つがSSSなんじゃないだろうか。

自分の所感でいいなら、SSSはかなり劇的で、しかもお手軽で、わりと速くて、要するに効果的だ。正直なところIDLでライティングするより、SSSを組み込んだ方がコストパフォーマンスは高い気がする。IDLはポテンシャルを完全に引き出すにはガンマ補正が必須だし(ガンマコレクションにチェックを入れたら薄毛になったという人、ウチの過去記事を10回音読するように!)。まあSSSは適用しない材質にとってはあまり関係ないし、速度についてはマシン依存なんであくまで所感にすぎないんだけど。

そんなわけで、ざっくりと解説っぽいもの。

1. SSSとは

いままで3DCGに触れてきた人に改めて「SSSってナニ?」と尋ねたら、大抵は「えーと、よくわからないんだけど光が皮膚の中で広がって……」といった風に答えるんじゃないだろうか。それが正解で、さらに言うと、ほぼそれがすべてなんである(笑)。皮膚に限らず、外から入った光が物質の中で散乱し、表面に影響を与えるのがSubsurface Scatter(表面下散乱)だ。略してSSS。

図にするとこんな感じ。

120327-1

現実の物質には、拡散色や鏡面値といったパラメータはない。あるのは表面の粗さと反射率だ。この反射率というのは色(波長)によって異なり、どの波長をどれだけ反射するかで反射光の色、すなわち物質の色が決定する。

120327-2

表面が粗ければ拡散する光が増え、滑らかな表面ではまっすぐに反射する光が増える。これを3DCGでは拡散反射と鏡面反射に分け、それぞれのパラメータでコントロールしているわけだ。さらに、光を透過する物質ならそこに透過率と屈折率が加わる。

120327-3

光は物質に当たるといくらか反射する。表面の微細な凹凸で、鏡面反射したり拡散反射したりする。反射しなかった残りは物質の内部に入る。光がすべて物質に吸収されてしてしまえば、それは不透明な材質ということになるし、吸収されずに反対側まで進んでいけば透明な物質だ。そして光は物質の中に入るとき(というか物質と物質の境界を越えるとき)、物質の屈折率によって屈折する。光というものは直進するものだから、屈折したあとはまっすぐに進んでいくはずだ。

しかし、物質の中に不純物が含まれていると、光はそこでも反射し、または屈折し、あるいは吸収される。さらに反射した光がまた別の不純物に当たって反射し……と、光が完全に吸収されるか外部に出て行くまで、延々と反射を繰り返すことになる。

物質の内部で何度も反射した光の中のうち、何%かはもう一度物質の表面に到達する。すると、物質の表面には鏡面反射と拡散反射以外にも、考慮しなければならない成分があることになる。これが表面下散乱である。

120327-4

この表面下散乱の一番のポイントは、光が入射したところとは異なる地点から出てくる、という点だろう。何度も乱反射を繰り返す(散乱する)うちに、入射した地点から少し離れた地点まで到達しているのだ。すると、光が当たっていない部分、ほとんど当たらない部分も若干明るくなる。ただしあんまり遠い地点までは、光が吸収されてしまうのでなかなか届かない。

120327-5

表面下散乱が発生するのは、なにも人間の肌だけとは限らない。牛乳など透明度の低い液体、翡翠や大理石といった鉱物からプラスチックなど、ざまざま物質が実は内部で散乱を起こしている。

120327-6

でまあ、こういう事をざっくり言うと肌の中でなんか光が広がって……ということになるのだ。

2. PoserのSSSノードと使い分け

PoserでSSSを使用するための手順は2ステップ。

  1. SSSを使用する専用のノードをルートノードの代替拡散に接続する。
  2. レンダリングオプションでSubsurface Scatteringにチェックを入れる。
120327-7

これだけである。では、SSSを使用するノードとはどのノードだろうか。現在Poser 9(とPoser Pro 2012)のSSS関連ノードは5つある。

  • Custom Scatter
  • Scatter
  • Subsurface Skin
  • Ks_Microfacet
  • Fast Scatter

この中で、上から4つまでが今回新しく追加されたノード。Subsurface Scatteringを使用するノードは上の3つだ。Ks_Microfacet以外はLighting>Specialカテゴリの中に分類されている。順に確認していこう。

一番の大本になるのがCustom Scatterノードだ。細かいパラメータを設定することができ、自由度が高いが若干扱いにくい。SSSがどうやって計算されているかを把握していないと、狙った効果を出すのが難しい。

Custom Scatterノードに対し、より直感的に設定できるパラメータに置き換えて難しさを取り払ったのがScatterノードだ。果物、大理石、人肌、牛乳など11種類のプリセットを備え、少ない試行錯誤で手軽にSSSを扱うことができる。

Subsurface Skinノードは、Scatterノードからさらに突き詰めて人間の肌に特化したノードだ。テクスチャを繋げばそのまま使えるだけでなく、なんと鏡面反射光まで一緒に計算してくれる。

Ks_Microfacetは、実はSSSを実現するためのノードではない。Lighting>Specularカテゴリに分類されていることからも分かるように、鏡面反射のノードである。列挙したのは、Subsurface Skinノードの鏡面反射成分と同じ計算方法を使用してるからだ。上にも書いた通り、現実の物質に鏡面反射というパラメータはない。表面の粗さと反射率で鏡面反射か拡散反射かが決定する。このノードは粗さと反射率をパラメータに持ち、従来のフォンノードやブリンノードより物理的に正確な方法で鏡面反射を計算する。

Fast ScatterはPoser 6から実装されていたノードだ。SSSを計算するのではなく、シャドウマップがオブジェクトからずれて発生するという原理を利用し、SSSに似た効果を描画する。言ってみればなんちゃってSSSである。「なんちゃって○○」というと、まるで出来損ないだ、騙されたみたいな反応をするユーザもいるけど、それはお門違いだ。最初からマニュアルに「SSSを擬似的な手法でより高速に再現する機能」と書いてある。名前も高速皮下散乱だし。拡散IBLIBLと混同するのと似た勘違いである。

それはさておき。

そんなわけで、SSSを実現するには複数の方法が用意されている。人間の肌のシェーダを作るなら、だいたい次の方法になるだろう。

  • (A)Subsurface Skinノード
  • (B)Scatter+鏡面反射を計算するノード
  • (C)Custom Scatter+鏡面反射を計算するノード

この内、(C)のCustom Scatterノードはちょっと面倒くさいので、(A)か(B)を使う事になる。今のところ(B)のScatter+鏡面反射という手法を用いているのが多いかな。

というわけで、長くなったので続きは次回。
Scatterノードのパラメータを確認しながら、実際にシェーダを組んでみる予定。



もうちょっと探索。

2012年03月23日(Fri)

自分でパノラマ画像を作ってみるテスト。

ざっくりライティングした背景セットを、だいたい人の目線の高さのドリーカメラで回転しながらレンダリングする。

120323-1

セットはレンダロで売ってるMerlinさんのMedieval Tavern

120323-2

で、Photoshop CS4の自動処理でパノラマ合成する。うまく合成させるためには、ある程度重なった部分がないといけないらしい。自分は画角が90度になるように焦点距離を調整して(ちなみにPoserのカメラのフィルム幅は今も1インチらしい。計算方法は過去記事のこのあたり)、30度ずつカメラを回転させながら撮っている。360度を30度で割るから合計12枚。

さらに真上と真下をレンダリング。

120323-3

極座標フィルタで変形させたものを合成、全天方向のパノラマ画像を作ってみた。

120323-4

で、前回のように球体に貼り付ける。今回はモデラで作成してみた。面は内向きに、UVも内側から見た方向と一致するようにする。

120323-5

で、カメラをぐりぐり動かして悦に入る(笑)。

全天方向をカバーするパノラマ画像にするには、それなりの解像度が必要だ。プレビュー画質で表示できるのが最大4096ピクセルなので、必然的にサイズは幅4096×高さ2048ピクセルになる。画角が90度なら、一枚の画像は高さを2048にするとして幅1024。IDLレンダで12枚撮るのにだいたい2時間ぐらいかかった。まあIDLの品質は結構ざっくりだけど。上下は別の画像を合成するので、厳密に上から下まで撮る必要はないかもしれない。上下の画像は極座標フィルタをかけるので、横方向の画像より大きい方がいい。

120323-6

ちょっと歪んでいるかなー。

メリットは、最初にレンダした画質がプレビューレンダで再現できるところ。普通の画像なのでフィルタかけたり加工したい放題だし、HDRIにすればライティング用にも使えるかもしれない。もちろん、プレビューレンダだからムービーも早い。

上手く貼れてるかなー。

難点はその場所から移動できないこと(笑)。なので本気でムービーに活用するにはどうかな、と思わなくもない。むしろ大量に使い回しできる書き割り背景みたいな感じかなあ。

そういえば初めて気付いたんだけど、Poserでムービーを作ると実際に指定したフレームから少しズレてレンダされてしまった。Poserが吐いたムービーはファイルサイズ的にもイマイチだし、イメージ連番書き出しを使ってQuickTime Pro 7のイメージシーケンスで読み込むのが一番かな。

もうちょっと真面目に合成してみたり。今度はPredatronさんのThe Monastery

120323-7

パノラマ合成をするソフトは、探してみるとそこそこあるっぽい。モノによっては何にも考えずボタンクリックすれば歪みのない画像が作成できるものもあると思う。まあそこまでする気はないので、Photoshopで修正したりするぐらいだけど。

120323-8

真上と真下はプレビュー表示だと難があるっぽい。

いろんなセットで全方位対応のリアル系ライティングさえしてしまえば、結構楽しめるかなと思う。



ランタイム探索

2012年03月21日(Wed)

ちょっと息抜きに、Poser Pro 2012でできる暇つぶし。

まず、小道具の球をロードする。ハイレゾ版はUVがアレなので低解像度版を使う。

特性パレットの「原点を表示」で原点位置を表示させ、球体の中心に移動する(Poser単位でY軸方向に0.05プラスする)。原点を移動するのは、球を拡大した時に中心から拡大されるようにするため。ついでY移動をPoser単位で0.05マイナスし、シーンの中央に来るようにする。さらに、グループ編集ツールで面の向きを内側向きに反転させる。

120321-01

そういうオブジェクトをモデリングしても手間は変わらないかな。

次に、ドリーカメラのY移動とZ移動を0にする。カメラは必ず球体の中心に置く。球をカメラにペアレントしてもいいかもしれない。

120321-02

球体は適当に拡大。

で、球のマテリアルをこんな感じで拡散値と鏡面値をゼロに、環境色を白にして環境値を1にする。イメージマップノードを接続して環境色と拡散色に接続する。

120321-03

テクスチャを読み込む。デフォルトランタイムのTexturesフォルダの中に、HDRVFXというHDR画像を格納したフォルダがあるので、その中から適当に一枚選ぶ。ファイル名の末尾にaとついていないやつを選ぶべし。P7の時は2種類しかなかったのに、いつの間にか増えてたんだなあ。

120321-04

続いてレンダリング設定のプレビューでOpenGLを選択、「ハードウェアシェーディングを有効」にチェックを入れ、その下のチェックは全部外す。テクスチャのサイズはマシンパワーが許す限り大きくしておく。

120321-05

Fireflyレンダを使うときはガンマコレクションにチェックを入れておく。

120321-06

表示をテクスチャシェーディングに切り替える。もっとも、大半の人は普段からテクスチャシェーディングを使っているかもしれない。で、視点をドリーカメラに切り替えてみる。地面は非表示にしておくと吉。するとこんな感じになる。

120321-07

まあ、それだけと言えばそれだけのお話(笑)。

カメラをグリグリ動かしてみると、周辺を見回すことができる。いつも拡散IBLに使っていた画像の中に入り込んでる感じ。拡散IBL用の画像は周囲の歪みが大きいので、後方にあるものはよく見えなかったりしたんだけど。

120321-08

池に直滑降する滑り台を発見したり。ちなみにPro 2010では、プレビューのハードウェアシェーディングがガンマコレクションに対応していないので、暗いままの画像になる。Fireflyでレンダリングすればちゃんと明るく表示される。それ以前はFireflyもガンマコレクションに対応していないので、P7でもやってみたい、という人はノード演算でガンマ補正してから接続するといい(数値演算_色でガンマ値の逆数を累乗する)。

他の画像も色々読み込んでみよう。ガレージみたいな一室。

120321-09

外が明るすぎるせいで、中の様子がよくわからない。Fireflyレンダならトーンマッピングを調整すると若干見えやすくなる。

120321-10

こんな感じ。あんまり変わらないかも。

120321-11

どこかのビルの中。あんまりデキのよろしくないパノラマ画像だと、歪みが生じててヘンな感じ。

120321-12

こんな風景だったんだねー。

120321-13

試みにフィギュアを読み込んでみたり。地面を表示させて、カメラを上に持ち上げる。カメラは必ず球の中心にしなければいけないので、カメラを移動させたら同じだけ球も移動させる。

120321-14

写真の出来次第だけど、カメラが実際に撮影された高さにあればパースは一致するはずだ。球体はIDLの光源として使うにはちょっと弱いので、別にライトを用意する。写真の見たままの角度に合わせるだけだから、ライティングは楽といえば楽。ちなみに、球体は特性パレットで影を落とさないように設定しておく。

120321-15

どこに立たせてもだいたい合ってる感じ。まあ写真自体が歪んでたりするし、厳密に合わせるものでもないかな、という気はする。背景に使えるかも、ぐらいの気持ちで。

120321-16

こうやって見ると、じぇしーも美人なんだけどなー。

そんなわけで、現実逃避にいろんな写真を探索してたりして。



海より深く。

2012年03月14日(Wed)

和風展、コメント受付中です。自分はこれからゆっくり閲覧の予定~。

第六回和風展バナー大

というわけで、一人和風展反省会パート2。

昨年の和風展が終わった時点で、奈良時代っぽいものをやりたいな、と漠然と考えていた。特に深い意味はなく、単にやってる人が少なそう+平安より衣裳が好きな感じだから、という単純な動機だ。突き詰めていくと和風というより中華風になってしまうのが微妙だけど(笑)。イメージはヒラヒラな女性がフワフワしてる感じ。説明になってないけど。仏教関係の天女が空を飛んでるとかじゃなくて、あくまで普通の女の人の感じで。使うフィギュアはA4かなあ、若い女の子ならManihoniさんのAnnyがちょうどいいし、などと考える。(←自分でキャラをこしらえる気は毛頭ないらしい)

とりあえずGoogleで検索しながら必要そうなアイテムをリストアップ。髪・髪飾り・服・ヒラヒラ・ウチワ・etc... という感じで溜息をついたのが月曜日ぐらい。仕方ないので簡単そうなものから手をつけていく。

120314-01

翳(さしば)。顔を隠す(むしろチラ見せする?)ためのアイテム。テクスチャは後でまとめて作るつもりで、適当にUV展開しておく。

120314-02

髪は手持ちのものの中からA4に合って使えそうなやつを探して、結った部分だけを作る。テクスチャはKozaburoさんのテクスチャを切り取って流用。

120314-03

どうせ見えないって分かってるのに作ってしまったり。

120314-04

蝶はメモ用紙にぐりぐりしたラインを、Shadeでそのまま再現した感じ。ポーズが付けられるようにフィギュア化しておく。あんまり深く考えずに作ったので、角度限定というか別アングルから見たらちょっとイマイチ。光球は以前紹介したもので、蝶のBODYにペアレントしてある。

作れるものはだいたい作ってしまったので、一度頭の中を整理しようと落書きする。服を作るのに躊躇していたとも言う。

120314-05

なーんかピンと来ないなあと不安になりつつ、DC計算の必要なパーツや色の組み合わせなどを漠然と把握する。

120314-06

衣(きぬ)の袖はDCにするので、作りやすいよう腕を伸ばしたポーズに合わせる。背子(からぎぬ)はコンフォーム、裙(も)はスカート部分だけDCで腰と紕帯(そえおび)の部分はコンフォーム、というわけで上下一体のハイブリッドフィギュアにする。モーフを作るのがめんどくさいので、最初からA4体型に合わせてモデリング。配布品じゃないし。JP調整も絵のポーズだけ再現できればいい、という感じで。

120314-07

フィギュア化が終わったところ。DC部分は六角ポリゴンから作った三角ポリゴンになっている。衣は袖部分しか作っていない。どうせ見えないしー。

120314-08

早速着用してポージング。手は衝突対象から外すので、ダミーの球体で覆ってド●えもん状態に。表情とA4のマテリアルもこの時点で作り込んでおく。

120314-09

比礼(ひれ)はテクスチャがなるべく歪まないように簡単な形で作って、一度途中までシミュレーションしたところで「新規小道具を作成」で小道具化。再度ウィンドデフォーマをかけつつシミュレーションする。発想はDC展の時と同じ。

120314-10

シミュレーション後、もうちょっとなびいて欲しい裾をマグネットで引っ張ったり。

ここまで来たところでテクスチャを作る。衣、裙、背子、紕帯、比礼、翳、髪飾り×3……。リストを作って陰鬱な気分になったのは、確か木曜日だったような気がする。とにかく素材集を切り貼りしてテクスチャを作成、マテリアルは別ファイルで調整してライブラリに登録。

120314-11

ちょっと余裕がありそうだったので、釣灯籠をサクっと作る。イメージは春日大社の回廊にズラっと並んでるやつ。テクスチャを作らずに済むよう、網の部分もモデリング。

120314-12

シーンファイルはこんな感じ。水面は基本小道具に追加されたでっかい平面。

今までなんかピンと来ないなあ、と思いつつ作業を進めてきたのが、いよいよ本格的にピンと来なくて焦る。不安になりつつ本番レンダ。ライトはIBLとスポットライト1灯、無限光1~2灯。

で、生レンダ。

120314-13

もう「駄目だあぁっ!!(ガッシャーン)」(←焼物職人が壷を割ってるイメージ)という感じ。

だめ、全然しょーもない。「こんな(検閲削除)なものを製造するためにお前は約一週間ひたすら机に向かってきたのか、この(自主規制)め!」みたいな罵詈雑言が脳内を駆け巡ったり。

ちなみに「しょーもない」というのは関西人にとって「存在する価値もないクズ」ぐらいの意味合いである(嘘)。

とは言え代案もないので、そのままPhotoshopへ。適当な写真の山のシルエットをコピーしてきて塗りつぶして重ねたり。

120314-14

ああ、余計意味わかんない。無い方が良かったんじゃないの。なくてもダメダメだけど。

120314-15

輪郭線を足してみたり。またこのパターンかよ! 芸がなさすぎ。そんなに下手ならもうPoserやめたら?

120314-16

トリミングしてみたり。構図はマシになったかもしれないけど、ありきたりだよね。結局意味不明なポートレートじゃん。

……などとやっているうちに、だんだん目が慣れてきたというか「もういいだろ」という気持ちになってきて、タイトルを考えようと万葉集を検索したら「夢で逢えたら」みたいなテーマが浮上してきて、ああ、ここは幻と現実の境界なんだな、この女性はもう逢えない人なんだな、みたいな解釈になって最終的に文字入れに頼って手直しして、という感じでとにかく完成に漕ぎ着けた。

完成してみれば、まあ……まあ、普通かな(笑)。


今回つくづく感じたのは、自作って(絵にとっては)なんの価値もないよね、ということ。自作を否定しているわけじゃなくて、どんなに時間を掛けてモノを作り込んでも、最終形態が絵ならその絵自体が良くなければ意味がない。展覧会は絵を見せる場所だから、その絵だけがすべてで、何にどれだけ労力をつぎ込んだかは関係ないんだ、という。

今回作ったものに関しては、(細かいミスはあるけど)それなりに満足かな、と思う。テクスチャもシミュレーションも思った形になったと思う。でもモノの良さをアピールするならワイヤーフレームの三面図を公開するなり商品プロモを作ればいいのであって、絵を見せる場所でそんなものは場違いなんである。

というわけで、やっぱり全くのノープランで取りかかるのは良くないな、と。もうちょっとしっかり完成絵のイメージを持ってから取りかかるべきだった、と反省。来年参加できるなら、その辺踏まえて取りかかりたいな……と……。

もうネタないんだけど(汗)。

(※今回文章表現がちょっぴり過激だけど、だいたいいつも通りの自分ツッコミを文字にしただけなので、気にしないよーに。)



さらさらっとな。

2012年03月13日(Tue)

第六回和風展の投稿期間が終了しました。コメントは15日まで受付中です。

第六回和風展バナー大

自分の今年の投稿は二枚。今年は比較的余裕を持った投稿になったけど、完成までの時間が予測できなかったので、わりとヒヤヒヤしていたり。

一枚目は軽くジャブというか(ちょっと違)、今年の「Poserってこんなことも出来るんだ部門」みたいな感じで。スケッチレンダラ自体は第四回の時にroseさんが使用なさっているので、特に目新しいことはないと思う。昨年マシンパワーが格段に上がったので、パラメータ設定を試行錯誤しやすくなったのが「やってみようかな」と思った第一の動機だったりして。

そんなわけで実際に設定したパラメータの数値とかは特に載せない。パラメータのざっくりした解説は以前本に書いたので、そちらを参照して欲しい。一応本に書いた内容はWebで公開したりしないという約束になっているので。

絵については構想なし。傘の構造を正確にCR2で再現できないかなあ、みたいなことを以前から考えていて、

120313-1

この辺りで「やっぱいいや」という気分になったので、まず可動しない和傘を適当にこしらえた。

120313-02

線が出たらいいなあ、などと考えていたので、糸をモデリングするという暴挙に出ている。

で、俯瞰で振り袖の女性(顔は傘で隠れて見えない)が石畳の道を歩いてるような構図を考えて、あらかじめ保存しておいたスケッチエディタのプリセットを適用してみると、

120313-03

上からのアングルでは傘の骨部分が描画されなかったという(笑)。しかも糸の部分は線が集中しすぎて真っ黒に(泣)。

仕方ないので、急遽構図を「横から見た図」に考え直す。横からだと顔が見えることになるので、全身を作らないといけない。となると既にライブラリに登録されているミフネを使うのが一番手っ取り早い……みたいな感じで手元のメモ用紙に走り書き。

120313-04

書いた本人が認識できればいいんだい!(笑)

傘→雨、ミフネ(WIZ)→カエル、みたいな連想で。花札っぽいと指摘されて初めて「そういや何かあったような」と思い出したぐらいなので、組み合わせに特に意味はない。柳の下を探すと鍵でも見つかるかな、みたいな。襲いかかってくるのはアリかもしれない。

120313-05

作ったシーンはこんな感じ。背景が白なのは、スケッチレンダの背景を白にしたかったから。単に描画しないだけなら背景のDensity(密度)を0にすればいいんだけど、それだと背面ポリゴンの色もつかなくなってしまうのであらかじめ白にしておく。

ちなみにスケッチレンダはおおむねプレビュー画面をそのまま描画する。だからプレビューがテクスチャシェーディングなら色付きで、スムースシェーディングならマテリアルの拡散色で、ワイヤーフレームなら線だけが描画されることになる。

120313-06

フィギュアを並べたときにミフネに徳利を持たせようと思ったんだけど、適当なものが見つからなかった(というか探すのが面倒になった)ので急遽それっぽいのを作成。文字は後からPhotoshopで合成するつもりだったので、テクスチャは作成していない。

ざっくりスケッチレンダでテスト。

120313-07(クリックで原寸)

だいたいこんな感じかな、というところで本番レンダに入る。もちろんPhotoshopで加工しやすいように輪郭線(Edges)のみ、塗り(Objects)のみのレンダに分割。輪郭線はさらに線が太いの細いので二通り。髪や帯など、エッジが描画されなかった部分はそのパーツのみを表示してレンダしたり。傘の骨は天井紙を透明にしたりとか。

120313-08

右下のは色の詳細用に拡散IBLでのっぺらレンダしたもの。あらかたレンダしたらPhotoshopで線を合成していく。描画されなかった着物の合わせ部分は他の部分の線をコピー&ペーストで。顔と髪の部分は別取りしてもキレイに出なかったので、色つきレイヤーを下地にしてエアブラシでざっくりと加筆。

書き足し部分。

120313-09

影も描いて、色つきレイヤーを合成したところ。灰色はトリミング範囲。

120313-10

トリミングしてもなーんかしっくり来なかったので、

120313-11

カエルと柳の位置を切り抜いてちょっと上に配置し直す。傘にかかっている柳の枝が伸びてるけど、ざっくりした絵なので継ぎ目はボカしてしまえば気にならない(笑)。

あとは地色とか、地面や空やフチに色を乗せたりノイズを乗せたりして全体の調整。雨はRonさんの雨ブラシを移動ぼかしで加工している。

スケッチレンダは出た当初(というか自分が使い始めたP6の頃)はイマイチな使い勝手だったけど、今は大抵のマシンならストレスはかなり軽減されていると思う。まあパラメータを変更してもプレビューが再計算されなかったり、処理中のカーソルが計算終わっても元に戻らなくてスライダーを選択しにくかったり、細かい部分は相変わらずなんだけど。こういう操作感をちゃんと改善していけば、ユーザーももっといろんな機能を使うようになると思うんだけどな。

そんなわけで次は二枚目。



UV情報とバンプ、検証について

2012年03月02日(Fri)

まず告知。第六回和風展が開催されています。投稿期間は11日いっぱいまで。年に一度の本気展、ぜひ奮ってご参加ください。

第六回和風展バナー中

じ、自分は鋭意作成中……(小声)。


さて、今回のエントリはろるふぃさんのブログ「POSERとHexagon中心に3DCGを楽しもう」の記事POSERのテキスタイル(バンプ)が保存できない不具合と解決法と、thattori43さんのブログ「TH Free Style」の記事ミレ犬お散歩グッズを受けての内容となる。お二人とも精力的にPoser活動なさっている方で、いつもブログを拝見しているのだけど、一点だけ勘違されていらっしゃると思しき箇所があるので訂正させていただくことにした。

ホントは自分はフォーラムに持ち込まれない限り、他の方のサイトの疑問などには応えないようにしてるんだけど。読んだ方が他にもいらっしゃるかもしれないので、ここは老婆心ということで容赦してほしい。コメント欄への書き込みでは説明し辛いし、メール等では他の読んだ方の目に触れなくなってしまうので。

問題の箇所は「UV情報が無いとバンプ関係のマテリアル設定がライブラリ登録時に消えてしまう」というもの。これが事実でないということ、なぜそんな誤解が起こったのかということを書いていこうと思う。

まず、UV情報を持たないオブジェクトを作成する。Shadeでプリミティブをポリゴン変換すると自動的にUVが設定されるので、WavefrontOBJのエクスポート時にUV値のチェックを外す。

120302-01

これをPoserでオプションを全部外して読み込む。最初は小道具の状態だ。適当にマテリアルを設定しておく。

120302-02

次に、セットアップルームで適当にフィギュア化。ライブラリに登録して、そのままロード。

120302-03

このように、フィギュア化してもバンプが失われることはない。ちなみに、ここで使用しているのは3Dテクスチャの乱気流(Turbulence)ノードである。

では、何が問題なのだろうか。

問題を正確に把握してみよう。ろるふぃさんのブログでは「バンプ情報が消える」「バンプ関係のマテリアル設定が消えてしまう」と書かれているけれど、マテリアルのキャプチャを拝見する限り、バンプにノードは接続されている。ということは、Poser内部でも保存されたファイルの中でも「バンプにテキスタイルノードを設定するという情報」はちゃんと保持されているということである。だから、「情報が消える」という書き方は正しくない。「バンプにマテリアルは設定されているけれど、レンダリングすると描画されない」もっと正確を期すと、本当に描画されていないのか今の段階では断言できないので「マテリアルは設定されているけれど、レンダリングすると描画されていないように見える」と表現しないといけない。

揚げ足取りみたいに思えるかもしれないけど、正確に表現することはとても大事だ。物事を正しく表現するには、現象を正しく把握する必要がある。表現が正確でないということは、現象を把握できていないということである。それでは正しい判断はできないし、物事を正確に伝えることもできない。

というわけで、問題の現象は「UV情報を持たないジオメトリをフィギュア化して再ロードすると、バンプに接続したテキスタイルノードが描画されなくなったように見える」ということになる。

ここで、「ん?」「2Dテクスチャのノードって、UVがないと使えないんじゃなかったっけ?」と思ったあなたは正しい。(UVに関しての説明は過去記事のこの辺の中盤あたりにある)

2Dテクスチャに分類されているノードは、平面(2D)方向に変化する情報を描画する。平面といっても、イメージマップノード以外はXY平面やXZ平面やYZ平面を指定することはできない。ではどの平面に対して描画を行うのかというと、UV平面しかない。つまり、2DテクスチャはUV平面に対して描画を行うノード群である。まあイメージマップノードは除外されるけど、イメージマップでUV以外を指定したことのある人はかなりレアだろう。

というわけで、UV情報を持たないオブジェクトには、そもそもUVを参照する2Dテクスチャノードが描画できるわけがないのである。

ではなぜ「小道具では正常に描画できてたのに、フィギュア化でバンプが消えた」と誤解されるような現象が起こったのか。

結論から言うと、この文章に間違いが三つある。

一つ、そもそも小道具の時に正常に描画されていたわけではない。
一つ、フィギュア化しても消えたわけではない。
一つ、バンプ以外でも同じことが起こる。

以下実証。UVを持たない小道具に対してテキスタイル(Weave)ノードを接続する。

120302-04

普通のアイテムに対してテキスタイルノードを使ったことがある人なら、これが正常な描画だとは思わないだろう。Poserの基本小道具(Primitives)内にあるボールを使って比較してみる。もちろんボールにはUVが設定されている。

110302-05

UV情報を持たない小道具では、パラメータを変更しても内容が反映されているようには見えない。ではバンプ以外、テキスタイル以外ではどうだろうか。拡散色(Diffuse_Color)に接続してみる。

120302-06

まったく同じ設定のノードを接続しても、UV情報を持たない小道具では異様な描画がされている。そもそも「その画素がUV上のどの位置に存在するか」が定義されていないのだから、いくら変位させるかも、何色で塗りつぶすのかもPoserが判断できるわけがないのだ。UV情報がないということは、「定義されていないから、不定」ということである。それを無理矢理描画させるものだから、イレギュラーな(不正な)描画になっている。

さて、フィギュア化したオブジェクトに対して2Dテクスチャノードを適用してみる。

120302-07

たしかに2Dテクスチャのノードが反映されなくなった……と、判断するのは誤りだ。本当にノードの情報が反映されていないのなら、イメージマップノードの「テクスチャの黄緑色」が描画されているはずがないからである。

では、フィギュア化によって一体何が変わったのだろうか。

Poserのインポートで作成されたオブジェクトは、その内部にジオメトリ情報を保持している。小道具としてライブラリに登録しても、ジオメトリ情報は小道具ファイルの中のgeomCustomという部分に保存されている。それに対し、セットアップルームでフィギュア化したフィギュアは、ライブラリに登録するとジオメトリファイルを別に出力する。つまり、フィギュア化したオブジェクトは、参照しているジオメトリが小道具であった時と異なるのである。

短いジオメトリ(8頂点の立方体)で試してみよう。左はインポート後そのままライブラリに小道具として登録したもの。右はフィギュア化してから、ライブラリに登録したときに生成されたもの。

120302-08

頭に「v」とついているのが頂点座標、「f」が一つ一つの面が参照している頂点番号/UV頂点だ。そして、頭に「vt」とついている行がUV値である。

フィギュア化したジオメトリには、UV値が一つだけ作成されている。そして、すべての面のUV頂点が同じUV座標 (0, 0) 、すなわち左下のただ一点を参照している。マップの同じ位置を参照しているのだから、凹凸や色の濃淡が生じるわけがないのだ。

フィギュア化したときにUVが生成されるのは、無用なトラブルを避けるためだろう。その結果、今まで不正な描画がされていたものが、正常な描画を行うようになったのだ。たまたま不正な描画の方が意図した結果に近く、正常な描画の方が意図した結果ではなかったために、それを不正な結果だと誤解してしまったのだろう。

以上のことをまとめると、

  • UV情報を持たないオブジェクトに対して、UV情報を参照する2Dテクスチャのノード群を適用すると、不正な描画が発生する。
  • フィギュア化でライブラリに登録したときに作成されるジオメトリは、元のジオメトリがUV値を持たない場合、自動的に (0, 0) のUV値を生成する。

ということになる。

UV値を持たないオブジェクトに凹凸や濃淡などつけたい場合は、2Dテクスチャではなく3Dテクスチャを使用すればいい。2Dテクスチャが(UV)平面方向に変化する情報を描画するノードだとすれば、3Dテクスチャは文字通り三次元方向に変化する情報を描画するノードである。つまりUVではなくジオメトリのXYZ座標によって内容が変化するのだ。縫い目やタイルのような2Dテクスチャと同じ描画はできないが、表面の粗さを表現するだけなら十分である。

作成したジオメトリにUV情報を付加するかどうかは、作者の任意による。ただ、もし配布するつもりがあるなら、一言「UV展開はしてません」程度に書き添えておいた方が親切だろう。巷のアイテムはUV展開されているものが大半だからだ。気に入ったアイテムのオリジナルテクスチャを作ろうとして、いざUVMapperを開いてみたら真っ白、となると「もう二度とDLしねえよ ヽ(`Д´)ノ」という気分になりかねない(実際に聞いた話・笑)。

なお、どうしてもフィギュアにUV情報を持たせたくない、という時はフィギュア化前のジオメトリを使用すればいい。PoserのWavefrontOBJエクスポートは法線情報は自動的に生成するが、UV値は生成しない。

120302-09

ちなみに自分は、フィギュア化で作成されるジオメトリは使用しないことにしている。以前のバージョンのPoserで、ポリゴンが欠落したり別のグループに割り当てられてしまうバグが発生するものがあったからだ。あと、フィギュア化するとジオメトリがパーツごとに分割されてしまう。これが個人的に不便なので、いつもPoser上でグループを整理したあと、フィギュア化直前に出力したものを使用している。


間違えること、失敗することは悪いことじゃないと思う。大切なのは疑ってかかること、何よりもまず自分自身を疑うことだ。他人の言っていることは正しくないかもしれない。悪意はなくとも正確ではないかもしれない。そして、自分の考えや行動はもっと間違っているかもしれない。もっと他にうまいやり方があるかもしれない。常にそう考え続けることはしんどいけれど、そうでなければ人間はすぐに自分の判断が正しいという考えに溺れてしまう。

考えて疑って、注意深く観察して、誰がどうやっても動かしようのない事実だけを積み上げていく。自分が正しいことを証明するのではなく、自分が間違っていることを証明するのだ。その結果間違いであることが証明できなかったなら、今のところはそれが「暫定正解」になる。そしていつか間違いであることが証明されたなら、新しい暫定正解に取って代わられる。古い間違いは決して無駄ではなく、新しい暫定正解をより正解に近いところに押し上げるのだ。

検証というのは、そういうものだと思う。





Menu

Profile

Kyotaro

確定名:Kyotaro
ネタを探しているらしい。

Categories

Calendar

02 | 2012/03 | 04
- - - - 1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

Comments

Archives

Track back

RSS feed

Links

Search

※2011年4月6日のサーバ障害の為、エントリのアドレスが以前のものからズレています。当Blogのエントリにリンクを張っておられた方は、お手数ですがアドレスのご確認をお願い致します。

※Internet Explorer非推奨。