流転四界ぶろぐ

自分的最大の難所、UV展開がどうにか完了したので、木目っぽいテクスチャでも作ろうかなって思ったんだ。プロシージャルテクスチャで作ったマテリアルを、テクスチャに焼き込んで出力するベイクという機能。去年ターナーを作った時にもなんとか出来たから、たぶん今回もなんとかなるだろうって思ってたんだ。

Blender。

去年ダウンロードした時、操作方法を調べて右クリックと左クリックを入れ替える的なカスタマイズを少しやって、カメラ操作方法なんかのメモは机の前に貼ってある。

……他の事はなんにも覚えていなかった（笑）。

慌ててあちこちのサイトを検索しながら、あーでもないこーでもないって試行錯誤したんだけど。マテリアルの概念とか画像ファイルの扱いとか、基本というより根本的な部分から抜け落ちてるから、どの説明を読んでも途中でひっかかるところが出てくる。やっぱり、こういうのは書いて残しとかないとな～。

その昔、自分は「ウンチクはひけらかさないと身につかないから～」などと嘯きつつ覚えたての雑学を語ろうとするイヤな子供だった。けど実は今でも、知識を身につけるには他人に説明をするのが一番だと考えている。

というわけで、Blenderでベイク機能を使ってテクスチャを作る手順の覚書。主に未来の自分に向けた用。モデリングは別のソフトで行い、UV展開済みのデータをWavefront OBJ形式で出力しているとする。

»Read More

コネクタのオスメス間違えたり、修正したら今度は左右が反対になってたり、落書きに逃げたりサルベージしたり。ついでに発狂したりしつつ、ようやく踏むやつのUV展開が完了。

めんどくさかったのでマップは4枚に分ける。分けたらマテリアルグループも別にしないといけないので、本体のマテリアルが2つになってしまった。本当は非正方形のマップにすればいいんだろうけど、細かいパーツの展開で目が疲れたのでもう色々省略。

そんなわけで今さらっぽい覚え書き。

カッチリした形状をUV展開するとき、並行投影で展開したいけど形状自体が斜めを向いてる……みたいなケースでは、ローカル座標を使っている。ギターのヘッドみたいにある程度形状を作ってから回転させるような場合は回転パートを使用するので、その回転パートのローカル座標を使う。回転パートでなくても、ガイド形状を放り込んだダミーパートなんかも使ったりする。

適当な変形を持つパートがない場合、例えば面取りしてできた斜面などを基準にしたいときは、ローカル作業軸を作成する。まず基準にしたい面を選択して、画面右下にある作業平面コントローラ（っていう名前らしい）をクリック。

でもって「ローカル座標軸を作成」を選択。

すると、画面表示が選択面を基準にしたローカル座標に切り替わる。

よく編集中の形状が行方不明になったりするので、そういう時は表示切替メニューから「選択形状に合わせる」で画面の中に表示させる。

で、この状態でUV展開で並行投影を使うとちゃんとローカル座標で投影してくれる。

サイズは選択形状がぴったり収まるような数値が自動入力されているので、これをX、Y、Zで同じ値を入力しておくと縦横の比率が1:1になる。異なる形状でも同じ値を入力すれば同じサイズで展開されるので、あとから正面と側面をくっつける時には便利。

元の表示に戻す時は作業平面コントローラか、画面上のコントロールバーでグローバル座標系を選ぶと元に戻る。

LSCMで自動展開すると斜め向いたりするし、結局並行投影で展開してチマチマとポイント移動した方が綺麗だったりするんだよなー。

果たして。ネットの海からRolandの社名ロゴと公式フォントを拾ってきたので、次はテクスチャ作成……の前にPoser化かな。どうも手際が悪いなあ。

1. やたらと長い前置き

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

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

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

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

ヤヤコシイネ。

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

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

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

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

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

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

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

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

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

»Read More

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

で、結果がこれ。

めっちゃ早くなった。

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

というわけでまとめ。

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

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

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

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

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

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

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

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

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

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

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

テキストプロップって初めて使った（笑）。

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

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

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

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

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

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

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

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