流転四界ぶろぐ

自分は一応理系をうたってはいるが、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. マテリアルやマップによっては、解像度がそこまで必要ないものもある。そういうものは縮小してファイルサイズ自体を小さくしてしまおう。

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

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