background

多段モーフの多段制御

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月24日(Fri)

書かねばならないような気がしている。

170324

いや、単なる多段モーフなんだけども。なんというか、まとまった日本語の文献がそんなにないような、技術がうまくシェアされていないような、そんな気がしてるんだけど、どうなんだろう。

うーん。

(もったいぶっているわけではなくて、文を構成したり図を作成するのに時間がね……)



悪そう。

2017年03月22日(Wed)

連休を使ってAさん用に服なぞコンバートしてみたり。

170322-1

なんか「コイツは絶対悪役しかもクライマックスの手前で死ぬ奴」感が果てしない。まあ概ねその通りというか、まんまなんだけども(笑)。

DAZで販売されているFrances CoffillさんのTOA Legend for Genesis 2 Male(s) and Michael 6(長い)。M4用にリリースされたTOA Legendaryのリフィットでなく完全リニューアル版だとか。M4版を見た時にも確か「おっ」とは思っていたはずなんだけど、去年DAZの男服を数年分遡ってチェックした時に、Genesis 2版のプロモ画を見て速攻でWishリストに放り込んだ。Poserで使えるかどうかもまだよく理解できてない時期にである。いやなんというか、男物でこのテのラインを作る製作者さんには全力で敬意を表さねばなるまい的な強迫観念というか。売り文句欄にわざわざ「男物です」って大文字で書かれてるあたりがポイント高いというか。

まあ、ぶっちゃけジオメトリさえ持ってこれればフィギュア化できるし。

っていうか、結局フィットルームとかそういうのまったく使わずに普通にコンバートしたし。

でもって、Aさんはリグ全体をいじってあるから、最早James/Koji用ですらないという。

170322-2

まだ作業途中。

DSON Importerを通すと、初期設定ではデフォルトランタイムのDSONフォルダの中にチェック用のジオメトリを吐く。コンバートされたフィギュアやファイルはまったく無視して、吐き出されたジオメトリ(.objファイル)を読み込んで体型に合わせた。大まかな位置合わせはフィギュア状態でやった方が楽なんだけど、フィギュアをOBJ出力するとジオメトリに切れ目が入るのが「なんとなくイヤ」なのでマグネットで。細かなはみ出しはモーフブラシでペタペタ。

あとは普通にグルーピングを変更したり、セットアップルームで骨を入れたり。モーフコピーの精度はもうちょっと上がってくれないと、まだ使い物にはならない感じかなあ。スカートのモーフだけはDSON Importerを通してPoserで再保存したファイルからエディタでコピペした。

170322-3

ベルトはM4版とGenesis 2版で位置が違うんだよね……というわけで両方のバージョンを用意したりとか。DAZ Studioでの動作を全く確認していないので、わりと適当。

いや、本当は真紅の法衣をリニューアルしようと思ってたんだけど、基本的な形は変わらないとしてウエストはベルトにしようか紐でいくかとか、正装の時の肩掛けをどうやってまとめようかとかよく考えたらまだ煮詰まってなかったような気がして。でもそろそろハダカやTシャツ以外にも何か作らないと、いい加減に呪われそうな気がして。

以前着てた黒くて細身の法衣の案、という位置付けで仕立ててみたんだけど、よく考えたらこの服裾が割れてるし「さすがにあれでは動き辛かったものですから」と言うにはむしろこっちの方が動きやすそうな気がしなくもない。まあ、現代モノ的な感じで使おうかな。

170322-4

マテリアルもまだ調整中。



だからテストレンダ。

170320-1

Jack TomalinさんのプラチナアイテムHammam。ハンマームは中東の公衆浴場のことらしい。基本的にサウナみたいな感じで、画面中央のでっかい台に寝そべって垢擦りとかしてもらうんだそうな。というか、日本語のトルコ風呂に「えっちなお風呂屋さん」の意味があったなんて、今回初めて知った(ひー)。

この人のアイテムはどれもプラチナ価格で買うのが申し訳ないくらい素晴らしいクオリティなんだけど、それだけではなくて最近はIray用アドオンと称する追加アイテムが発売されている。要するにIrayでレンダリングするための、ノーマルマップや粗さマップが入ってるわけだ。あとライトセットなんかも含まれてるんだろう。

でもって、Iray用ということは、もちろんSuperflyでも使えるわけである。

というわけでパッケージを手動ダウンロードしてテクスチャだけを引っ張ってくる。まあ当然のごとくマテリアル設定は自力でやるわけだけども、元のマップがきちんと調整されているおかげで物理ルートに繋ぐだけで完結する。

170320-2

ファイル名にRってついてるのが商品ページではReflectionって書いてあるけど、ツルツルのところが黒くなってるのでRoughnessマップということでいいと思う。Weightっていうのはよく分からないけど名前からしてSpecularかMetallicあたりの比率を制御してるんだろう。とりあえず無視。あとランプあたりは適当にガラス的なマテリアルを当てる。

それでもいい感じになるんだから、ありがたい話だ。

170320-3

ちょっと例としてはイマイチな画像だけど、中央の台に反射が現れてるのが見えるかな。

物理ベースだから一概にバンプマップがダメでノーマルマップがいい、という話ではなくて、以前のアイテムでは高低差を描くべきバンプマップが光の当たった時の様子を描いてたり、テクスチャに陰影が描き込まれてたり、と当時のレンダリングで見栄えが良くなるように調整されていた、ということだ。だから今の物理ベースではかえって合わなくなってしまったものもある。そういうアイテムでも、ちゃんとしたマップを作ってやれば十分使える、という話。

170320-4

欲を言えばディフューズも新しいの欲しかったな~。まあ、贅沢か。



お返しに。

2017年03月14日(Tue)

170314

KYO’s Superfly materials 01 - Rosy -

ポチポチと自分用に作り貯めていた、Superfly用のマテリアル集です。ざっくり金属系36個、布系12個と革っぽいの4個、ガラス4個と液体っぽいの10個。実用に耐えるかな?というものもあれば、実験的なだけで汎用性に乏しいものもあり。

ちなみにFireflyには非対応です。中には専用のルートノードを持つものありますが、むしろ消していないから残っているだけで、調整などは一切してません。FireflyはCycles系ノード挟むと出力が0になっちゃうので、中には真っ黒だったりするのもあると思います。

ファイルにいちいち01とか番号がついてたり、そのくせなんだか飛び飛びになってたりするのは仕様です。作ってた中で不採用にしたものとか、最初から作っていないものなどがあるので。金のヘアラインとか、あっても仕方ないしね。そのうち第二弾とか出たら、同じ種類のものは同じフォルダにぶっ込むかもしれません。

とりあえず製作者側が作りやすい金属系、需要が高いであろう布系、作るのめんどくさい屈折系、あたりをちょこちょこ揃えています。他にも蝋とか紙とか石とか考えてたんだけど、いかんせん本格的に取り掛かるのが遅くなって時間が……あうあう。布系は概ねスケールを調整できるようになっているはずなので、アイテムに合わせて調整してやってください。シェーダってついてるのはだいたい色とか自分で指定できるようになっているはず……はず。たぶん。

あと、綿には普通のと透けるのと二種類を用意してるけど、実は普通の方も若干透けているのでご注意ください。服が透けるのは女子としては恥ずかしいことなので、女の子の外出着に適用するのは現実的ではない、とかね。

ええっと。

どのへんがバラ色なんだと聞いてはいけない。言うから。今から言うから。

いつだったかなあ。

「roseさんがPoser 7を購入されたら、マテリアル集でも出しましょうか」

……つまり、そういうことだ。

そんな、ぶっちぎりの不義理をぶちかますようなこのうつけ者を見捨てないでいてくれる、薔薇館のペンギン女史に日頃の感謝の気持ちを込めて。



キリのいいサイズ。

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年03月03日(Fri)

普通に撮る分にはFireflyに戻れない理由の一つがこれ。

170303-1

640×640pixelのテストレンダで、ピクセルサンプルはFireflyが3、Superflyが5。Fireflyはさらにレイトレースシャドウ+IDLの品質は7、イライラキャッシュをフル使用でシェーディングレート0.2というカナーリ抑えめなテストレンダでこの有様。Fireflyは透過体のIDL計算がやたらと苦手なんである。

しかもログを見ると、表示がなんだか怪しい。

170303-2

しめて1京8446兆7449億4988万2880秒。約6億年だなんて弥勒菩薩ぐらいしか待てないようなレンダリングを、小一時間で完了させるなんてFireflyある意味すごい……っていうかどこかで桁モレてるんじゃないのって感じだけども。

でもって、時間だけならまだ待てないこともないんだけど、アップにするとこの通り。

170303-3

暗い部分がベッタリと暗くなってしまう。Fireflyではちゃんとしたトランスルーセントを扱えなかったのが一番辛かったところで、レンダ設定を変えつつ複数枚撮りを合成することで対応してた。それがSuperflyではちゃんとマテリアル設定すれば、サクっと一発でレンダリングできるようになった。これが大きい。

170303-4

Superflyと同じ設定でFireflyレンダするとこんなになっちゃうしね。

ちゃんとしたTips記事にするのが面倒くさくてやってないけど、みんなSuperfly使うならトランスルーセントも活用しようね、っていう話。





Menu

Profile

Kyotaro

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

Categories

Calendar

02 | 2017/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非推奨。