background

スポンサーサイト

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

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


キリのいいサイズ。

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

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



Comments

Post Comment

管理者にだけ表示を許可する


Trackback

※このブログにトラックバックを送信する場合、お手数ですが本文中にブログ該当記事へのリンクを含めてください。

トラックバックURL:http://rutenshikai.blog63.fc2.com/tb.php/555-18096c02



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ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。