background

スポンサーサイト

--年--月--日(--)

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


多段モーフの多段制御

2017年03月30日(Thu)

1. やたらと長い前置き

Poserにはカタカナ用語がたくさんあって、最初にまとめて覚えようとして挫折したり、わからないなりに把握してたり、という人も結構いるんじゃないかと思う。

たとえばジオメトリ。「OBJのことでしょ?」と言われれば、まあその通りだ。じゃあ「オブジェクト」と「ジオメトリ」は同じものだろうか? そう聞かれると、内心焦ってしまったりするんじゃないだろうか。

ジオメトリ (Geometry) は「図形」や「幾何学」という意味だ。つまり形状、モノのカタチそのものを指す。一方、オブジェクト (Object) はソフトによって微妙に使われ方が違うけど、基本的により抽象的なモノ、存在そのものを表す。例えばPoserの背景や大気は確実にシーン内に存在し、特性や独自のマテリアルも持つオブジェクトだけど、ジオメトリを持たない。

170330-01

逆にVictoria 4.2に仕込まれたマグネット群にはカタチがないけど、あれは「存在しない」というジオメトリを読み込んでいる。ライトやカメラは表示用のジオメトリを持っているけど、あれは言わばガイドのようなもので、そこから光が発せられていたりするわけじゃない。

ヤヤコシイネ。

Poserのジオメトリは基本的にWavefront OBJ形式で記述されている。まず頂点があり、その頂点を直線で結ぶことでポリゴンが定義される。ポリゴンとは多角形の意味で、だいたいは三角か四角のどちらかだ。まれに線が閉じられず、面を持たない線ポリゴンというものも存在する。ダイナミックヘアーのガイドヘアーは線ポリゴンだ。

そして面ポリゴンがたくさんたくさん繋がって、立体のカタチを作り上げている。一見なめらかな表面でも、表示スタイルを変更してやれば、そのオブジェクトが複雑なジオメトリを持っていることがわかるだろう。

170330-02

さて、ここからちょっと若返る時間。

三次元空間の中にある、一つの頂点をPと呼ぼう。Pointの頭文字をとってPだ。この頂点Pがどこにあるかを定義するためには、X軸、Y軸、Z軸、それぞれの座標を求めればいい。頂点PのX軸座標はpxで、Y軸座標はpy、Z軸座標はpzだったとする。そのとき、「頂点Pは(px, py, pz)にある」と定義することができる。ジオメトリファイルの中には、そんな感じの座標が大量に記録されている。

でもってこの頂点Pを、別の位置に動かした。具体的にA地点まで動かした。A地点の座標はax, ay, azだ。さて、頂点Pはどれだけ動いただろう。

170330-03

「どれだけ変化したのか」を知りたい時、それは「変化した後の状態」から「変化する前の状態」を取り除いてやることで求めることができる。例えば財布の中の1万円が9千円になったとしたら、その変化の量は9000-10000=-1000。マイナス千円変化した、ということになる。変化の量がマイナスだから、減ったわけだ。

つまり頂点Pが元の位置からA地点に移動したとき、位置は(ax-px, ay-py, az-pz)だけ変化したということになる。変化した量というのは引算なのだ。なので数学の世界ではこれを差分 (difference)の頭文字d、さらにはギリシャ文字にしてΔ(デルタ)と呼んだり書いたりする。モーフターゲットの中に含まれるデルタとは、名前からして「どれだけ変化したか」を意味しているのだ。

170330-04

ところで、このデルタ内に記録されている数値はダイヤルを1にしたときの変化量だ。ダイヤルの値が2なら2倍移動するし、-0.5なら逆方向に半分だけ移動する。

170330-05

ということは、モーフターゲットは直線にしか移動できない、ということだ。ファギュアのパートやマグネットのように、回転させることはできないのである。

スポンサーサイト


キリのいいサイズ。

2017年03月07日(Tue)

自分は一応理系をうたってはいるが、512円とか1024メートルなどという数字を見たら「半端だなあ」と思う程度には凡人である。しかし、これが512バイトとか1024ピクセルという単位に変わると、「お、キリがいいね」と思う程度にはアレである。

コンピュータは今のところ「スイッチがONになっている」と「スイッチがOFFになっている」のどちらかしか判断できない。有るか無いかの二者択一だ。その組み合わせを繋げていくことによって、膨大な数を表現している。二進数というやつだ。この数は2の乗数で表される。人間が概ね10進数を使い、100とか1000といった数をキリがいいと感じるように、コンピュータは8とか256とか1024といった数をキリがいいと感じる。いや、感じているかはわからないけど、無駄なくスマートに扱うことができる。Poserのレンダリング設定のバケツサイズが32だったり64だったりするのは、その単位で計算した方がコンピュータにとって無駄がないからだ。

すると、テクスチャも1024ピクセルや4096ピクセルといった大きさで作成した方がいい、ということになる。もちろんその方がメモリを効率よく使えるだろう。では、レンダリング速度に関しては影響するのだろうか。キリのいい画素数の方が、早くレンダリングできるのだろうか。

というわけで実験。あ、Fireflyでは誰かがやってた気がするので、Superflyだけ。

170307-1

使用するのはDante78さんの中世ビール醸造所。この人の作品はどれもプロモ画のそっけないミニチュア感が、なんというか仄淡い郷愁を誘ってくるのでとっても好みなんである。しかし、どうもいつもレンダがもっさりする。作りもマテリアル構成もシンプルなのにである。

そこで使用されているテクスチャを確認し、なるべくキリのいい画素数にリサイズして、レンダリング時間を比較してみる。

表1: Medieval Breweryのテクスチャと画素数
File NameOriginal SizeResize
Medieval_Brewery_Ground_A_Txt2700×27002816×2816
Medieval_Brewery_Ground_A_Bump2700×27002816×2816
Medieval_Brewery_Ground_B_Txt2800×28002816×2816
Medieval_Brewery_Ground_B_Bump2800×28002816×2816
Medieval_Brewery_Objects_Txt3500×35003584×3584
Medieval_Brewery_Objects_Spec3500×35003584×3584
Medieval_Brewery_Objects_Bump3500×35003584×3584
Medieval_Brewery_Roof_Txt2700×27002816×2816
Medieval_Brewery_Roof_Spec2700×27002816×2816
Medieval_Brewery_Roof_Opa2700×27002816×2816
Medieval_Brewery_Roof_Bump2700×27002816×2816
Medieval_Brewery_Structure_Txt3500×35003584×3584
Medieval_Brewery_Structure_Bump3500×35003584×3584
Medieval_Brewery_Wall_Ext_Txt3500×35003584×3584
Medieval_Brewery_Wall_Ext_Bump3500×35003584×3584
Medieval_Brewery_Wall_Int_Txt3000×30003072×3072
Medieval_Brewery_Wall_Int_Bump3000×30003072×3072
Medieval_Brewery_Wood_Roof_Txt2300×23002304×2304
Medieval_Brewery_Wood_Roof_Spec2300×23002304×2304
Medieval_Brewery_Wood_Roof_Bump2300×23002304×2304

ただし、Jpegは再保存するたびに情報が劣化するし、圧縮率などの設定項目もある。元の設定がわからないので、とりあえず画質100%のプログレッシブ形式で上書き保存した。普段なら絶対やらないことだけど。さらにPNG形式で、同様にオリジナルサイズとリサイズしたファイルの二種を用意する。シーンファイルはコピーして、エディタで拡張子のjpgをpngに書き換えた。パスなどには影響されないよう、拡張子以外のファイル名は同名とし、差し替える時はランタイムのフォルダごと差し替える。

表2: テクスチャファイルの形式とファイルサイズ
-JpegPNG
OriginalResizeOriginalResize
Total file size177.3 MB137.6 MB244.4 MB247.3 MB

リサイズする画素数は256で割り切れる数字で、元より大きくなるようにする。Jpegでは再保存したことでファイルサイズが小さくなっているが、PNG形式では大きくなっていることがわかる。

シーンにはアイテム以外なにもロードせず地面も非表示、無限光1灯に拡散IBL1灯。レンダリング設定はデフォルトのまま。Poserを起動してシーンファイルをロードし、レンダリングボタンを4回押して、ログウィンドウを確認するだけの作業だ。

毎回、レンダリング自体はものすごく早い。最初のブロックが現れてからたぶん2秒ぐらいしかかかってない。しかしその前、レンダリングボタンをクリックしてから最初のブロックが現れるまでに顕著な差がある。

170307-2

この時。なのでやっぱり、テクスチャまわりで時間がかかっているんだろうな、とは思う。

というわけで実際にレンダリングを繰り返した結果がこちら。

表3: ログによるレンダリング時間の比較
-JpegPNG
OriginalRisezeOriginalResize
Rendering Memory (MB)645675645675
1st Render (sec)45.1539.7611.937.28
2nd Render (sec)29.5526.515.936.19
3rd Render (sec)29.9828.325.876.15
4th Render (sec)30.8626.885.896.18
Average 2nd-4th (sec)30.1327.245.906.17

まず最初に、レンダリングメモリはJpeg・PNGともにリサイズした方が増えている。このことから、レンダリングメモリはファイルサイズや形式ではなく、テクスチャの総画素数に依存することがわかる。

次に、初回と2回目以降のレンダリングでは、2回目以降のレンダリングの方がどのケースも早い。初回はテクスチャを読み込む時間自体が含まれるからだ。2回目以降のレンダリング時間にはほとんど差がないので、その平均も並記している。

そして初回のレンダリング。オリジナルサイズよりも、リサイズした方がJpegもPNGも早くなっている。Poserはテクスチャをメモリに読み込む際、キリのいいサイズの方がすんなり行く、と考えていいだろう。もしかしたらメモリに展開するときに、内部でキリのいいサイズにリサイズしているのかもしれない。

しかし、問題は2回目以降のレンダリングである。こちらはJpegでは早くなっているが、PNGでは逆に少しだけ遅くなっている。レンダリング速度は画素数ではなくファイルサイズに関係しているのだろうか。

そして、Jpeg自体がPNGに比べて圧倒的に遅いのも気になる。

Jpegにリサイズする時は、Photoshop CC 2017で画像解像度を変更して上書き保存した。いつものように書き出しメニューを使うと、ファイルサイズが極端に減ってしまって、検証に影響がでるかもしれないと思ったからだ。しかし書き出しメニューを使わない場合、Photoshopはファイル自体にいろんな情報を埋め込んでしまう。ひょっとして、それらが何か悪さをしていないだろうか。

というわけで、元の画素数のまま書き出しメニューを使用したJpegのファイル群も用意してみた。画質は100%のまま、プロファイルやメタデータの埋め込みは行わない。

170307-3

で、結果がこれ。

表4: ログによるレンダリング時間の比較(再出力含む)
-JpegPNGExport Jpeg
OriginalRisezeOriginalResizeOriginalResize
Total file size (MB)177.3137.6244.4247.3157.175.5
Rendering Memory (MB)645675645675645646
1st Render (sec)45.1539.7611.937.287.527.56
2nd Render (sec)29.5526.515.936.196.126.10
3rd Render (sec)29.9828.325.876.156.045.79
4th Render (sec)30.8626.885.896.186.125.80
Average 2nd-4th (sec)30.1327.245.906.176.095.90

めっちゃ早くなった。

このことから、一番のボトルネックになっていたのは画素数でもファイル形式でもファイルサイズでもなく、画像の保存方法だったことがわかった。その上で、初回のレンダリングにはキリのいい画素数であるかどうかが関係し、2回目以降のレンダリングでは、ファイルサイズ自体が小さい方が早くなることがわかった。しかし、今回のようなアイテム単体のシーンでは、差はまだそれほど大きくないことも読み取れる。

というわけでまとめ。

  1. まず、ファイルパス正しく保たれるように、画像はRuntimeフォルダの中に保存する。読み込み時に検索がかかっては元も子もない。
  2. ファイルを保存する時は書き出しメニューを使用し、余分なデータを含まないようにする。あと、画質も無駄に高くしない。80%もあれば十分である。
  3. 画像はなるべくコンピュータにとってキリのいい数字、256の倍数で作成する。あと正方形だともっといいかも(未検証)。
  4. マテリアルやマップによっては、解像度がそこまで必要ないものもある。そういうものは縮小してファイルサイズ自体を小さくしてしまおう。

レンダリング中、テクスチャ読み込みでもっさりするような時は、元テクスチャを再書き出ししてみるのもアリかもしれない、ということだ。おかげでずいぶん軽快になった。

170307-4

内側から見てもいい感じ。



モーフのミラーコピー

2017年02月28日(Tue)

Poser 11 Proはモーフパテツールでモーフターゲット(以下MT)の鏡面コピーを作成することができる。残念ながら並の方のPoser 11ではできないみたいだけど。この鏡面コピーはモーフブラシで新しく作成したMTに限らず、既存のモーフでもコピーできる。例えば、マグネットでこんな感じのMTを作ったとしよう。これを左右対称にしたい。

170228-01

まずは編集ツール(Editing Tools)パレットから、モーフパテ(Morphing Tool)ボタンをクリックする。パレットを片付けていたらウィンドウメニューで表示しよう。

170228-02

すると下図のような縦長なパレットが表示される。モーフパテツールはパーツ内の既存MTを組み合わせてぐりぐりする「統合(Combine)」タブと、ブラシでもりもりする「作成(Edit)」タブからできている。使いたいのはモーフブラシの機能なので、「作成(Edit)」タブを表示する。

170228-03

上部のSelect or Create Morph(日本語名未確認)で、編集するMTを新規作成したり選択することができる。今回はすでに作成済みのモーフを編集するので、リストから該当パートの該当グループの目的のMTを選択する。

170228-04

すると選択したMTが読み込まれ、ブラシで編集できる状態になる。値が1になってなかったらMT名の直下のダイヤルをひねっておこう。

170228-05

リストの下部のミラー(Mirror)ボタンをクリックして、コマンドを選択する。今回はHeadパート内で左半分にあるものを右半分にコピーしたいので、「(パート名): +x to -x」を選ぶ。

170228-06

例えば右腕のものを左腕に……なんて時は、「(フィギュア名): Right to Left」を選択してやればいい。選択したMTと同名のモーフが、右肩から左肩に、右腕から左腕にと丸ごとコピーされる。該当モーフがなければ新たに作成してくれる。

なお、どっちがプラスでマイナスだったっけ? と混乱する人のために。

170228-07

テキストプロップって初めて使った(笑)。

ちなみにリストで指定するXYZはワールド座標ではなく、個々のパートのローカル座標だ。パートが回転してたらややこしいので、ポーズや移動はまったくない状態で作業しよう。

170228-08

といういわけで無事にコピーできた。元々左右対象じゃない形状ではうまくいかないかもしれない。普通のフィギュアならたぶん問題ないと思う。

ちなみに既存のMTを組み合わせて好みの顔を作っていた場合、マグネットや外部MT読み込みで新しいモーフを作る時に既存MT分の変形を相殺するのを忘れないようにしよう。詳しくは過去ログ参照。

左右対称にしたら、今度は左右別々に動かしたいと考えるもの。そういう時はモーフダイヤルのオプションメニューで「モーフを分割(Split morph...)」を選ぶ。

170228-09

左右に分割された2つの新しいMTが作成される。元々のモーフはそのままだ。

170228-10

表示されるダイアログだと内部名を指定できるのかなと思ったんだけど、残念ながらそんなことはなかった。なんでだろ。

170228-11

とりあえず外部名はオプションメニューのパラメータ編集で変更できるからいいか。

モーフのコピーを使えば片側だけ編集しただけでキレイに反転できるので、マグネットをコピーする手間や、外部モデラで鏡面編集するの忘れてた、なんてミスが省ける。便利便利。



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で透明設定と振り分けるのがいい。

そんなところかな。





Menu

Profile

Kyotaro

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

Categories

Calendar

04 | 2017/05 | 06
- 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非推奨。


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。