background

Poserで組み込むERC

2017年02月22日(Wed)

今回義眼を作り直したついでに、虹彩を凹ませたり、瞳孔の大きさを変えるモーフなどを仕込んだ。当然両目のパーツに別々にモーフダイヤルが存在するわけだけど、表情ならまだしもこのテのモーフは片側だけを操作することはまずない。両目とも一度に変更できた方が便利だ。でもって、ダイヤルがHeadパーツにあるとなお使い勝手がよろしい。となるとERCを仕込むことになる。

ERCは"Enhanced Remote Control"の略で、Poser 4の頃に確立したテクニックらしい。直訳すると拡張式遠隔操作、みたいな感じで「あるパラメータを別のパートのパラメータで制御する」という仕組みだ。公式にはBODY上で全身のモーフを操作するFBM (Full Body Morph) 以外は動作保証外だったけど、仕組み上はシーン内のすべてのチャンネルを操作することができる。というわけで、関節の補正や服の追従に当然のように使用されまくっていたし、黙認されてる状態だったわけだ。

ところが、いつかのバージョンからこのERCがPoser上で編集できるようになった。なったんだけど全然使ってなかった。テキストエディタでやった方が慣れてるし、間違いないし。とはいえ、ファイルを直接編集するのが怖いという人もいるだろうし、いい機会なのでやってみることにする。

ちゃんと調べたらPoser上でERCを組めるようになったのはPoser 8かららしい。ただ、パラメータにキーを打ってスプライン補完するという手法で、残念ながら後方互換がなかった。11のPro版では旧来のERCも組めるようになったということなので、両方試すことにする。

ちなみにERCは公式ではDependent Parameters、依存パラメータと呼ぶらしい。……あんまり言いたくないけど、こう「連動パラメータ」とか、せめて「追従型パラメータ」とか、意味で訳した方が直感的じゃないかなー。いや、いいんだけどさー。



屈折について

2017年02月18日(Sat)

今回はちょっと長めの記事。あ、いつもか。

1. 簡単なマテリアル

Superflyで屈折を持つマテリアルを実現するには、二通りの方法が考えられる。一つはFireflyと同様、Poserサーフェイスノードの屈折色にレイトレース>屈折のノードを追加すること。もう一つはCyclesサーフェイスノードのSurfaceにRefractionBsdfノードを追加することだ。

170218-01

大抵の透過体は表面がツルツルしているので、反射成分を追加することになる。CyclesカテゴリにあるGrassBsdfノードなら、屈折と反射を同時に描画してくれるのでお手軽だ。

170218-02

で、大体はこれで話が終わってしまうんだけど、もう少し複雑な構造やシチュエーションをレンダリングしたい場合には、知っておきたいことがある。

2. 屈折とは何か

そもそもなぜ、まっすぐに進むはずの光が曲がってしまうのだろう?

光はこの世で最も速く進む存在だ。その速度は3.0×108[m/秒]、一秒間に約30万キロも移動する。だけど実は、何かの物質の中を通り抜ける時には少しだけ遅くなる。真空を進むより空気中を進む方が、空気中を進むより水中を進む時の方が遅くなるのだ。

この速度の違いが、光の屈折という現象を引き起こす。斜めに当たった光が、そのわずかな到達時間のズレによって向きを変えてしまうのだ。これは、片側の前輪だけ先に砂利道に乗り上げた車によく似ている。反対側の前輪が砂利道に入った時、先に乗り上げた車輪は後から追いついた車輪ほど先に進んでいない。両輪の進む速度が違えば、車体は進みの遅い側へ曲がってしまう。しかし両方とも砂利道に入ってしまえば、車体は再びまっすぐに進む。

170218-03

実際には光は波の性質を持っているので、この現象はホイヘンス=フレネルの原理によって説明される。詳しく知りたい人は検索してみるといいだろう。

170218-04

ある物質に入る前の光を入射光、入らずに反射した光を反射光、中に入った光を屈折光、そして光が進む物質を媒質と呼ぶ。屈折率は真空中を進む光の速度を、媒質中を進む光の速度で割った数字だ。これを絶対屈折率と呼ぶ。どんな媒質の中でも光は真空中より速く進むことはできない。だから絶対屈折率は必ず1より大きい。

絶対屈折率 IOR = 真空中を進む光の速度 c ÷ 媒質の中を進む光の速度 v

波は、波長が短く振動数が高いほど媒質の影響を受ける。つまり波長の短い光ほど屈折率が高くなり、たくさん曲がることになる。この屈折率の違いがプリズム、分光という現象を起こす。よく水の屈折率は1.33であると言われるけれど、これは波長589.3ナノメートルの電磁波(黄色い光)を基準にした絶対屈折率だ。

さて、光はいつも真空から飛び込んでくるわけではない。空気から水の中へ、あるいは空気からガラスの中へ。ある媒質から別の媒質へ進む場合の屈折率は、どう求めればいいだろう。

媒質Aの物質から媒質Bの物質へ入射する時、その速度の変化の度合い、比を表す式はvb÷vaとなる。先ほどの式から、それぞれの速度vは光速cを絶対屈折率IORで割った値であるから、

vb ÷ va= ( c / IORa ) ÷ ( c / IORb ) = IORb ÷ IORa

つまり、新しい媒質Bの絶対屈折率IORbを元の媒質Aの絶対屈折率IORaで割ってやればいい。

相対屈折率IORA→B = 新しい媒質Bの屈折率IORb ÷ 元の媒質Aの屈折率IORa

またこのことから逆の場合、つまり新しい媒質から元の媒質へと出て行く時、光は相対屈折率の逆数の屈折率で屈折することがわかる。

3. Poserマテリアルへの反映

ではこのような屈折率を、どのようにPoserのマテリアルに反映するべきだろう。薄いガラスの板を通り抜けるシーンを考えてみよう。

170218-05

ガラスの絶対屈折率はだいたい1.45~である。大気の屈折率はほぼ1であるとしていいだろう。大気とガラスの境界面のマテリアルは、屈折率1.45を指定すればいい。じゃあガラスと大気の境界面のマテリアルは、その逆数の0.69を指定すればいいのだろうか。

170218-06

これはもちろん正しい。ただし、問題が一つある。光がいつも表から入ってくるとは限らないことだ。光源が反対側にある時、あるいはカメラがガラスの中にある時。どこから光が入ってくるかわからないのに、入る時と出る時で二種類のマテリアルを用意することはできない。じゃあどうしよう。

Poserはポリゴンの表と裏で、この二つを区別している。

つまり、媒質の境界をポリゴンで表現した時、面の表を元の媒質、面の裏側を新しい媒質として、その相対屈折率を適用するのだ。表から裏へ光が通り抜ける時は、適用された相対屈折率をそのまま使う。そして、裏から表へ通り抜ける時は、相対屈折率の逆数を適用する。ポリゴンで形成されたオブジェクトは、境界面に囲まれた任意の媒質で満たされた空間だと考えることができるわけだ。

170218-07

ためしにガラスの屈折率を設定した球体を二つ並べて、片方の面を反転させてみよう。ちょうど逆数の屈折率を適用した場合と同じ屈折像が得られる。

170218-08

というわけで長々と考えてきたけれど、結局冒頭に載せたように屈折ノードを接続すればいいことがわかる。

また、この媒質の厚さが十分に薄い場合、光は直進する時とほとんど変わらない軌跡を辿る。

170218-09

これは、形状が薄ければ屈折率が1に近づくということではない。厚さを無視しても良いような場合に限り、屈折のマテリアルは透明度で代用することができるということだ。また逆に、厚みを持たない形状の場合、屈折率は1でなければならない、ということでもある。表面しかないメガネのレンズに屈折を設定すると、光はいつまでもガラスの中を進んでいると考える。レンズから肌までの距離も全部ガラスだと判断してしまうのだ。

4. コップの屈折

さて、ややこしいのはここからである。

水晶球のようなアイテムを作りたいなら、球体に水晶の屈折率を適用すればいい。地面にできた水たまりを表現したいなら、平面に水の屈折を適用すればいいだろう。では、水を入れたガラスのコップを表現したい時、それはどんなジオメトリを持つべきだろうか。

170218-10

まず、こんなジオメトリに屈折率を持つマテリアルを適用してみよう。

170218-11

とても私たちの知るガラスのコップには見えなくなってしまった。コップが空の時、その中身は空気である。しかしこのようなジオメトリでは、光は中身を正しく判断することができない。

170218-12

だから屈折を使用するオブジェクトは、厚みを持つジオメトリでなければならないのだ。

170218-13

では次に、水を注いでみよう。それはどんなジオメトリを持っているべきだろうか。最初に思いつくのはこんな形だろう。

170218-14

しかし、これではやはり正しい屈折を計算することができない。なぜならガラスと空気、空気と水の境界は正しく設定できていても、ガラスと水の境界を設定できていないからだ。

170218-15

この状態では、コップの中身は空気なのか水なのかはっきりしない。ガラスと水の境界を設定しなければならないのだ。

丁寧に作られたコップのいくつかはこんな形状をしている。コップの形状の中に、液体の形状が入った形だ。

170218-16

しかし、これではどこか現実的でない結果になる。ガラスのコップと液体との間に隙間、つまり空気の層が存在してしまっている。屈折率が1だから影響はないだろうと思っても、光の進み方はそこで決定的に変わってしまうのだ。

170218-17

そんなわけで、最終的に屈折率を正しく表現するとこのような形になる。空気とガラスが接する面、空気と液体が接する面、そしてガラスと液体が接する面。この三つに別々のマテリアルを割り当て、それぞれに屈折率を設定してやれば、どの角度から見ても正しく計算される。

170218-18

また、間に空気の層を挟む先ほどの例より反射回数も少ない。ただし、このようにモデリングされているアイテムは、まだとても少ない。水量モーフを作るのもめんどくさいしね……。

5. 屈折と影

ところで。

先ほど「地面にできた水たまりを表現したいなら、平面に水の屈折を適用すればいい」と書いた。しかし実際にやってみると、なにやら変なことがわかる。

170218-19

マテリアルは正しく設定されているのに、水面が真っ黒になってしまう。どうしたことだろう。

170218-20

水面を動かしてみれば、真っ黒なのは影が落ちているせいだとわかる。屈折のマテリアルは適用された面を通り越してその向こうの様子を描画することができる。しかし、地面を描画するのは地面に当たったレイである。そして残念ながら、屈折の適用されたマテリアルは、他のオブジェクトから見たら不透明な材質として扱われてしまう。床や地面を計算する時、水面は光を通さない板として影を落としてしまうのだ。これはFireflyのころから変わらない。

170218-21

もちろん、だったら特性パレットで影を落とさないようにしてやればいい。しかし、他の影を落とすマテリアルと一体になっている場合には使えないし、一部のシェーダの描画で不都合が出たりする。なるべくなら使いたくない手段だ。

このような透過後の光を正しく描画するには、レンダリングオプションで屈折コースティクスを使用する。屈折コースティクスが有効な時、Superflyはライトトレースで光の経路を計算するので、地面は水面を通った光で照らされることになる。しかし、コースティクスの描画には膨大なレンダリングコストがかかる。計算結果がなかなか収束しないから、それなりの精度を得るにはもんのすごいサンプル数が必要になるのだ。

そこまで時間をかけたくない場合、また厳密な経路を計算しなくていい場合に有効な方法がある。LightPathノードを使用して、影の計算の時だけ別のシェーダを当てるように振り分けるのだ。

170218-22

LightPathノードのIs Shadow Rayは影の計算を行っている時だけ真(=1の値)を出力する。これで影の計算の時はただの透明シェーダ、それ以外の時は屈折シェーダで計算することができる。

170218-23

影を描画しない場合、Volumeノードの計算がうまく働かない。たぶん影を計算する時に同時に距離を算出しているからじゃないかと思う。だけどこの方法を使えばVolumeノードも正常に描画できる。なので、水深が深くなるほど色が濃くなるといった表現ができる。

170218-24

AbsorptionVolumeノードは距離に応じて色がつく(光が吸収される)シェーダだ。GlassBsdfの色はできるだけ薄くして、表面では吸収されないようにしておく。

170218-25

こんな感じ。屈折と反射と、あと中央付近の色が濃くなっているのがわかるかな。

6. まとめ

長々と書いたけど、屈折についての要点は以下の通りだ。

  • だいたいはCyclesサーフェイスノードにGlassBsdfノードを繋ぐだけでいい。
  • ポリゴンは媒質の境界面を表し、その表裏と屈折率には密接な関係がある。正しい屈折像を得るには屈折を考慮したモデリングとマテリアル設定が必要である。
  • 屈折のマテリアルは影を落とす。光を透過したい場合は時間をかけてコースティクスを使うか、より手軽にLightPathノードのIs Shadow Rayで透明設定と振り分けるのがいい。

そんなところかな。



そういえばいつの間にか、ポーズルームでもマテリアルファイルやマテリアルコレクションファイルを適用できるようになった。とはいえマテリアルルーム以外だと、マテリアルファイルを適用した時にはダイアログが表示される。マテリアルファイルは現在選択されているマテリアルグループに対して材質を適用するファイルだけど、マテリアルルーム以外ではどのグループに適用したらいいかわからないからだ。

170214-1

大半のジオメトリは通常マテリアルグループを持っている。このグループというのは、ポリゴン一枚一枚についてのグループ分けで、フィギュアのパーツを決定するために使用されるポリゴングループとはまた別のカテゴリとなる。マテリアルグループを一つも持っていないようなジオメトリでも、Poserで読み込んだ時に自動的にプレビューというマテリアルグループが作成され、すべてのポリゴンがプレビューのグループに割り当てられる。たとえば、基本小道具なんかはマテリアルグループを持たないジオメトリだ。

ジオメトリのマテリアルグループと、フィギュアファイルや小道具ファイルで定義されているマテリアルが一致するとき、そのグループに属するポリゴンは定義された設定で描画される。なぜこんな回りくどい言い方をするのかというと、ジオメトリが持たない=実際には存在しないマテリアルグループでも、フィギュアや小道具は保持することができるからだ。

よく遭遇するのがV4リリース初期に作られたMATポーズファイルを適用した時。ポーズファイルはほぼノーチェックでフィギュアの情報を書き換えてしまう。ジオメトリが持つマテリアルグループと微妙に異なる名前のMATがあったりなんかして、いろいろ適用しているといつの間にかリストにNostrilとNostrilsが並んでたり、EyeTearとTearが並んでたりする。

170214-2

マテリアルコレクションファイルを使用した場合、適用先のジオメトリを予めチェックしてくれる。適用先に存在しないマテリアルグループを定義していると、その存在しないグループを無視するか追加するか尋ねてくるのだ。

170214-3

追加した場合、マテリアルグループのリストに新しいグループが増える。もちろん、どのポリゴンも所属していない空のグループなので、レンダリングしても描画には影響がない。ただフィギュアや小道具の記述がちょっと増えて、テクスチャなんかが余分に読み込まれたりするかもしれない、というだけだ。

例えば、マテリアルグループAとBとCを持つ小道具をロードしてそれぞれのマテリアルを調整、A’とB’とC’になったとしよう。これをマテリアルコレクションファイルとしてすべて登録する。次に、マテリアルグループBとCとDを持つ小道具にこのファイルを適用すると、「はい」と選んだ場合はマテリアルグループが作成され、(A’)とB’とC’とDというマテリアルを持つ小道具になる。「いいえ」を選ぶとB’とC’とDを持つ小道具になる。

そんな感じで、例えば基本小道具に色々と調整したマテリアルコレクションファイルを次々に適用していくと、最終的に全部入りのマテリアルグループができる。

170214-4

これをマテリアルコレクションファイルとして登録すれば、マテリアルグループAからFまで様々なグループを持つ小道具に適用できる、全部入りのマテリアルコレクションファイルが出来上がるわけだ。適用する時には「いいえ」を選ぶ。リストが無駄に長くなっても構わないならどっちでもいいけど。

170214-5

もちろん、この手段が使えるのは「同名のマテリアルは同一のマテリアル設定である」という前提が成立する時だけだ。同じMetalという名前でAという小道具は鉄、Bという小道具は銅、Cはテクスチャが貼られている、なんて場合には使えない。けれど、最近の入り組んだアイテムを作成される手慣れたベンダーさんは、ある程度マテリアル名が共通化されてたりなんかする。そう、Stonemasonさんとか。

そんなわけで出来上がったロンドンの全部入りSuperfly用マテリアルがこちら。

KYO's Superfly materials for The Streets Of Old London

カメラに映る範囲の小道具に適用しては「いいえ」を選ぶと、該当するマテリアルだけ変更されるコレクションファイル。と、あとライトとかちょっと。Fireflyはぶっちゃけ繋いだだけでテストレンダもしてないので、適当に調整してください。というかSuperflyの方もかなり適当な設定なのでいい按配にしてください。

そんな適当な設定でも、キレイにレンダしてくれるSuperflyっていいよね、みたいな。

170214-6


いまさら始めるDSON Importer

2017年02月07日(Tue)

去年何年か振りにPoser界隈をチェックして驚いたのは、G2とかG3とかいう略語がDAZのGenesisの世代を表す言葉になっていたことだ。そりゃあ、イーフロフィギュアは流行ってなかったから仕方ないけど、寂しい話だなあぐらいには思った。さらに驚いたのは、そんなDAZからDAZ Studioでしか使えないはずの、GenesisフィギュアをPoserに読み込むツールが出ていたことだ。

だけどまあ、正直な感想としては「どうでもいいや」だった。

楽しみ方は人それぞれだ。自分なりの妄想世界を作り上げているユーザーにとって、大切なのは脳内にいるキャラであって使っているフィギュアそのものじゃない。イメージにより近くて、それなりに服があって、そこそこ使いやすければなんだっていい。そりゃ脳内で肌色が組んずほぐれずしてることが多いという人なら、関節の破綻の少なさも大事だろうけども。

だから新しい機能が使えますよ、とかツールを駆使すれば簡単にコンバートできますよ、とか言われてもイマイチ響かない。現状維持が一番楽なことに変わりはないからだ。響くとしたら使いたい服、もっと言うと「ウチの子にどうしても着せたい」とまで思わせる服が出た時だろう。しかしカタログを数年分遡って、出た結論は前述の通りだった。

だけど、そんなつむじ曲りのユーザーも振り向く一言がある。

「○○○○さんの新作背景、いいですよね」

ここにStonemasonさんやJack Tomalinさんの名前でも入れれば高確率で振り返る。ふぁんたじースキーならFaveralさんやMerlinさんも急所だ。Neftisさんの髪だって大好きだ。

フィギュアや服に興味がなくても、クオリティの高い小道具や髪はやっぱり魅力なんである。というわけで、今回は画像過多注意。



続・Superflyで大気効果。

2016年12月18日(Sun)

前回の続き。せっかくだから、反射物のあるシーンでもなんちゃって大気効果を使えるようにする。まずは適当にシーンを作ってレンダリング比較。

161218-01

さすがに水面のマテリアルはそのままだと厳しいね。

Superfly(というか元々のCyclesレンダラ)の残念な点として、ディスプレイスメントを頂点単位でしかかけられないという制約が挙げられる。メッシュの粗い板ポリゴンに解像度の高いテクスチャを適用しても、ざっくりカクカクとした形状にしかならない。サブディビジョンをかければ多少は細かくなるものの、マシンパワー的に限度がある。ポリゴンをシェーディングレート単位でマイクロポリゴンに分割して変位をかけるという、Fireflyは結構優秀だったのだ。

まあ、ないものは仕方ないので、ここは素直にノーマルマップにでもしてしまおう。

161218-02

さくっとノードを足して、高さの情報を引っ張ってくる。こういう時、ルートノードを複数持てるのがいいよね。

161218-03

強度にいい加減な値を入れたままだから揺らぎ具合が合ってないけど、まあぐっと水面っぽくなったかな。そんなわけで前回作った大気レイヤーを近景と遠景のマテリアルに追加する。

161218-04

反射像を見やすくするために、一旦ノーマルマップを切断している。水面に反射している遠景の山が見た目よりハッキリ映ってしまっているのがわかる。

では、その条件分岐を行っている部分にノードをちょこっと足す。

161218-05

全体のノードの配置を変えちゃったからわかりにくいけど、実際に繋ぎ直したのはこの部分。

161218-06

今まで端折ってたのでざっくり書くと、LightPathノードは今計算しているレイについての情報を取得するノードだ。例えばIs Camera Rayなら、今計算しているレイがカメラから発せられたレイであれば1を出力し、そうでなければ0を出力する。つまりカメラに直接映っている時だけ1となる。反射像や屈折、間接光の計算をしている時は0になる。Is Reflection Rayなら、反射像の計算をしている時だけ1になる。これを数値演算ノードで他のノードと掛け合わせると、カメラに直接映るっている時だけあるマテリアルを適用し、それ以外の時は0のまま、というような計算ができるわけだ。

細かい説明はたぶん「Blender Cycles LightPath」あたりで検索すると見つかると思う。

数値演算ノードのMaxは、値1と値2に接続された値を比較して、どちらか高い方の値を採用する。1と0の組み合わせなら、どちらかもしくは両方が1の時1を出力し、両方とも0の時だけ0を出力する。つまり論理演算でいうAND回路の計算をするわけだ。一度に3つ以上の値を比較することはできないから、そういう時はノードを階段状に組み合わせる。これで「カメラに直接写っている時、または反射時か屈折率を持つ透過体の計算をしている時」だけ、効果を適用することができる。

なんでこんな手間をかけて条件分岐をつけるのかというと、二次反射光の計算など、大気の散乱の影響を受けてはいけないような時まで距離の計算を行うのを防ぐためだ。

161218-07

というわけでレンダリング。水面に映った反射像にも効果が適用されていることがわかる。

161218-08

水面のノーマルマップを再接続してこんな感じ。とりあえず満足。





Menu

Profile

Kyotaro

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

Categories

Calendar

01 | 2017/02 | 03
- - - 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 - - - -

Comments

Archives

Track back

RSS feed

Links

Search

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

※Internet Explorer非推奨。