background

だからテストレンダ。

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使うならトランスルーセントも活用しようね、っていう話。



モーフのミラーコピー

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

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

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





Menu

Profile

Kyotaro

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

Categories

Calendar

03 | 2017/04 | 05
- - - - - - 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 - - - - - -

Comments

Archives

Track back

RSS feed

Links

Search

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

※Internet Explorer非推奨。