2010年6月28日月曜日

LuxRenderのレンダスピードを向上させる10のポイント(後半)

前半からのつづき。



6.テストレンダを実施する

シーンが完成したのでLuxRenderでいきなりフルサイズでレンダ開始、というのは
おすすめしません。最低一度はテストレンダをして様子をみるべきです。

最終的にHDサイズに出力する作品だからといってテストレンダもHDで行う必要は
ありません。VGAや360pくらいのサイズでもノイズの出方や照明の具合、処理の
進行状況の傾向といったものは確認できます。

本番のレンダで数時間費やしてから後悔するよりは、5分程度のテストレンダで
失敗に気づいた方が精神衛生上よろしいかと。



7.ポータルを使用する

ポータルは光源からの光に対して明示的に光路を指定するためのオブジェクトです。
レンダ結果に影響しない無駄な光路計算を省略させることができるため、レンダ効率の
改善が期待できます。

と説明してもイメージしづらいかもしれないので、数量限定特価品がある開店前の
家電量販店の入り口を想像するとわかりやすいかも。

店としてはどれくらいの集客につながったのか、とか、用意した在庫数の過不足を
知りたいので客の人数を知りたい。

なのに開店を待っていた客がシャッターを開けた瞬間に入り口から店舗内に縦横無尽、
勝手気ままに殺到すると人数の確認も情報もなにもあったもんじゃない。
あまりの混雑のため特価品の売り場にたどり着けない客や、逆に特価品目当てでない客が
人の流れに巻き込まれてしまいさらに混乱がひどくなる状況も発生する。

そんな状況は勘弁していただきたいので、購入希望者の列を作るための立て札やロープ、
特価品のある売り場への誘導のためのスタッフ等を適切に配置すると、今度はスムーズに
客は流れるようになる。関係の無い客が巻き込まれることもなくなり、人数チェックも
確実に行えるようになる。

量販店入り口=光源、客=光、特価品売り場=被写体のオブジェクト、とすると
誘導のためのスタッフ、立て札やロープ=ポータル、という感じ。

実際のポータルのメカニズムとは若干違う部分もあるけど、当たらずとも遠からずかと。
あくまでイメージってことで。


[関連リンク]
ポータルを使ってみる



8.不必要なポリゴンを減らす

LuxRenderに限った話ではないですがシーンに存在するポリゴンが多くなれば
レンダ時間はより長くかかります。いわゆるローポリモデリングというほど
極端にポリゴン数を減らす必要はありませんが、不必要なポリゴンが存在して
いないか意識しながらモデリングしたり、シーンを構築するのは良いことです。

被写体としてレンダリングされないオブジェクトでもポリゴンを少なくしておく
ことでレンダスピードの改善につなげられるものもあったりします。
特に効果的なのは7.で説明したポータル用のオブジェクトとメッシュライト。

ポータル自体はレンダ結果に表示されることは無いのでできる限りシンプルに
しておくのがベストです。メッシュライトは自己発光のため形状がはっきり
出なかったりするのでこちらも極力単純な形状で面数が少ない方がよさげです。

どちらも面数が少なくしておくことでフォトンマップ作成やレンダ時の光路計算
などの処理が軽減されるためレンダスピードの向上につながります。



9.ポストエフェクトを使ってみる

LuxRenderでレンダしている場合ある程度まで処理が進捗すると、オブジェクトの
ディテールは出てきたし目立ったノイズも無いんで、あとは微妙なノイズというか
絵がざらっとしてる感じが減っていけばいいかな?という状態になるかと思います。

で、そこからが結構時間がかかるわけで。ガラスがすっきり透明になるまで、とか
影のグラデーションがなめらかにつながるまで、とかが。

そんな状況で役に立つのがポストエフェクトとして用意されているノイズフィルタ。
レンダをすすめつつリアルタイムに効果を確認しながら並列に適用できるので
あと一歩の状況でとても便利。

またレンズ効果もポストエフェクトとして利用できます。
レンズ効果はノイズ対策用というわけではないのですが、ブルームやグレアなどを
適用すると画像がぼんやり、柔らかくなるので結果として細かいノイズが目立たなく
なったりします。



10.適切なバージョンを使用する

LuxRenderはMac、Linux、Windowsで利用可能ですが、各OS向けに32/64bit版や
SSE2対応版などいくつか異なるバージョンが配布されています。自分の環境にあった
ものを選択することでより効率の良いレンダリングが可能です。

またオープンソースなのでソースから自分の環境にあわせて最適化したビルドを作成
することでハードウェアの性能をより引き出すことが出来るようになります。

配布されているビルドはSSE2までの対応だったり、CPU毎の最適化はされていないので
自分の環境に合わせた最適化の余地はかなりあるかと思います。またllvm-gccでの
ビルドも可能なので利用できる方は一考の価値があるかと。


[関連リンク]
Ubuntu10.04 でLuxRenderをビルドしてみる
blender とLuxRenderのビルド手順メモ
LuxRender10% 早くなる。



---------------------------------------------------------------
コメントなどありましたらこちらへ->web拍手

LuxRenderのレンダスピードを向上させる10のポイント(前半)

LuxRenderに関してぽつぽつと書いてきたけど、まとめ的なものが
そろそろあってもいいんじゃないかと思ったんでメモ。
切り口というかテーマはいろいろあるけど、一番役に立ちそうな
レンダスピードの改善を中心にまとめてみました。


LuxRenderのレンダスピードを向上させる10のポイント

1.マニュアルに目を通しておく

LuxBlendのGUIに各種設定に関するチェックボックスやメニューがあるので
なんとなーくオプションを設定しても、なんとなーくレンダできてしまいます。
が、レンダ速度と品質の改善のためにはざっとでもレンダ設定についての
マニュアルに目を通しておくべきです。

設定可能なオプションはすべてGUIに表示されています。
ただ、そのオプションの値が何を意味して、どのような効果があるのかを
知るためにはマニュアルを読むの最も手っ取り早く、効率の良い手段です。
レンダしようとするシーンに適切なレンダオプションを設定することで
処理速度や品質は大きく変わります。



2.速いCPUを使う

1.で期待をさせた後にこういうことを書くのはアレですが、レンダするのに
速いマシンを使うのに越したことはありません。Atom搭載のネットブックと
Core iやPhenomなどのCPU搭載のマシンでレンダした場合の差は歴然です。
Atomでちまちまとレンダオプションを設定していたのがバカらしくなります。

さらにデフォルト設定でも十分に速いマシンに、適切なレンダオプションを
設定すれば当然さらにレンダは速くなるわけで…ゴクリ。

しかしいろいろと事情がありマシンの買い換えや追加ができない場合も多く
あるはずです。というわけで以降はマシンの買い替えや追加をしなくても
改善できる方法を挙げていきます。


[関連リンク]
レンダリング用に新マシンを作ってみた



3.メモリを増設する

マシンを買い替えなくてもメモリを増設することで、レンダリングの効率が
改善される可能性があります。

メモリ不足の場合、スワップの発生によるパフォーマンス低下もちろんですが
レンダの際にメモリ管理のため、本来ならば不要な処理が発生します。
これにより十分なメモリが利用できる場合に比べて効率がさらに悪化するとともに
動作が不安定になり、レンダの最中に落ちる原因にもなります。
またフォトンマッピングでレンダリングを行う際は、メモリが不足していると
マップの作成が途中でキャンセルされてしまいます。

複雑で規模の大きいシーンをレンダリングする場合や、大きなサイズで画像を
出力したい場合などもメモリは多く必要になります。
レンダするシーンやモデルにもよりますが、自分のこれまでの経験では2GBで
ぎりぎりという感じ。2GBだとたまにシーンのエクスポート中に落ちたり
フォトンマップ作成が途中でメモリ不足でキャンセルされたりということが
まれにあるという状況。

これを機会にメモリを増設するならば4GB以上あると良さげです。



4.ネットワークレンダリングを行う

自宅にデスクトップ、持ち運び用にノートPCというように2台以上のマシンが
あるという人もいるのではないでしょうか?もしくは新しいPCを買ったので
古いマシンはあまり使わなくなって放置されているとか。

このように複数のマシンが利用可能ならLuxRenderのネットワークレンダリングが
役に立ちます。ネットワークにつながった複数のマシンで処理を分散してレンダを
行うことでレンダスピードの向上が期待できます。

同一のLAN内に存在するマシンはもちろん、インターネット越しのアクセスでも
ネットワークレンダリングに参加させることができます。使用するLuxRenderの
バージョンさえ同じなら、MacやLinux、Windowsなど異なるOS、32bit/64bitと
異なる環境でも協力してレンダリングを行うことができます。
動画でも、静止画でもどちらでもネットワークレンダリングが可能です。


[関連リンク]
LuxRender でネットワークレンダリング



5.適切なオプションを設定する

冒頭でも触れたようにシーンに合わせた適切なオプションを設定するのは重要です。
例えばインテグレータの選択だけでもいくつかありますが、オブジェクトの位置や
構図の確認だけならdirect lightingで十分です。
他の例としてガラスなど透明な物体を質感をリアルに表現したいならbidirectional、
ライトの照り返しなど間接光を表現するならigiというようにシーンや表現したいものに
対してより適した選択があります。

またRenderで設定可能なオプション以外にもOutputのファイル保存やプレビューの
更新間隔、Systemで設定可能なプロセスの優先度やアクセラレータの設定なども
レンダリングの効率や速度に影響があります。



長くなったので後半分けました

---------------------------------------------------------------
コメントなどありましたらこちらへ->web拍手

2010年6月24日木曜日

bidirectionalインテグレータの設定メモ

Dispersive Refraction有効な状況でbidirectionalと戯れる日々ですが
公式wikiも参考にしつつ設定関連がなんとなく分かってきたのでメモ。


bidirectionalの設定可能な通常オプションはbouncesのみ。
あるフォトンというか光路のパスにおける屈折や反射の回数の合計が
指定した数値に達したらトレースを終了するという値(のはず)。

デフォルトでは12になっているけど、より大きい値を指定すれば
パスをトレースする深さが増え、正確なレンダ結果が得られる。
その反面、計算回数も増えるのでレンダ時間も長くかかる。
逆も然りで小さい値ではレンダは短くて済むが、パストレースが
省略され表現されるべきディテールが出なくなる可能性もある。

レンダ時間への影響をチェックするためデフォルトの12から10へ
減らして昨日のシーンをレンダしてみると、時間は約10%短縮。
いくつか他のシーンも試してみると程度のばらつきはあるがレンダ
時間が短くなるのは間違いない雰囲気。


で、複数のシーンで試してみた感じだとbouncesの目安としては

K = Om + 2*Ot + L + 1

ただしOm、Ot、Lはシーンに存在するオブジェクトの数であり
Om:不透明なオブジェクトの数
Ot:一部もしくは全部が透明なオブジェクトの数
L:ライトや光源として使用しているオブジェクトの数
とする。

上記Kの値に対して

1. K≦5の場合、bouncesは5
2. 5<K<12の場合、bouncesはKの値を使用
3. K≧12の場合、bouncesは12

という感じ。経験則なので根拠はなにもありませんがw

例えば点光源一個と床替わりの板ポリ一枚、その床の上にsuzanneを
置く。床とsuzanneのマテリアルはmatteを指定というシーンなら

K= 2 + 2*0 + 1 + 1 = 4となり、K≦5なのでbouncesは5

もう一例。部屋替わりの箱の内部に、点灯している豆電球一個と
天井にマテリアルでエミッタを設定したエリアライト用の板ポリ
一枚の場合。箱のマテリアルはmatteとする。このシーンだと

K = 2 + 2*1 + 2 + 1 = 7となり、5<K<12なのでbouncesは7

ポイントは豆電球をOtとL、天井の板ポリをOmとLとして重複して
カウントするところ。被写体以外のオブジェクトの数が増えたり、
照明が複雑になっても、この条件式ならそれなりに対応できるはず。
あと、上の例には挙げなかったけどポータルはノーカウントで。

とこんな感じの目安を設定したものの、ダイヤモンドだとか
カッティンググラスみたいなものをレンダする際には条件式より
大きめのbounces値が必要なこともあるはず。


なにはともあれ、テストレンダは必須ということで。


---------------------------------------------------------------

コメントなどありましたらこちらへ->web拍手

2010年6月23日水曜日

Dispersive Refractionでいろいろ。

引き続きDispersive Refraction関連でいろいろ試行錯誤中。



昨日のレンダから少しカメラを動かして、レンズも絞ってみた。

光源やカメラを動かすとノイズが出なくなることもあるので期待したけど、相変わらず
同じような場所にノイズが残る。こういった感じのFireFlyノイズはv0.6で対策が入った
はずだけど依然でるときはでる、時間をかけても消えないものは消えないという感じ。

ただ昨日が6時間だったのに対して今日は2時間半と大幅にレンダ時間の短縮に成功。
さらにluxblendの設定を間違えて2コアしか投入していなかったので4コア全部まわせば
1時間台になるはず。さらにデノイズも使えば1時間かからないかも。

これで目立つFireFlyノイズが無ければかなり実用的なんだが。残念。
サンプラ変えてもダメだったんでお手上げ。v0.7RC4でどうにかならないかなー。


思い出したように拍手のお返事とか。

>luxrenderでSSS的表現ができることが分かって、たいへん有意義でした。
>ありがとうございました。
SSSなんてやったっけ?luxrenderで?と思って調べてみたら、多分これとか
この辺のですね。というか、まだ1年も経ってないことをさっぱり忘れる自分が怖いです。
しかも自分で書いたポストなのにw

ちなみに本家フォーラムでもSSSがらみでこんなスレッドがありました。
リンク先の作品はLuxRender v.0.7のスプラッシュスクリーンコンテストにもエントリ
されているようです。フェイクでないSSSの実装も今後の予定としてはあったはず
なんですが、ここまで表現できれば現状でも十分な気がします。


あとtwitterのアカウントとってみたり。

それなりに内容のあることや記録しておきたいことは翻訳やってるサイトか、ここに
載せているので、twitterは基本的に暇つぶしとか、容量の都合もあってここには
載せてないテストレンダやシーンのセットアップやらを適当に貼ったりとか。

お暇な方はどうぞ -> http://twitter.com/tksg8086

---------------------------------------------------------------
コメントなどありましたらこちらへ->web拍手

Dispersive Refractionが。

こっそりちょこちょこDispersive Refractionを試しているものの相変わらずいまいち。

LuxRender自体も使い始めた頃は、やたらレンダ結果がノイズだらけだったり
ノイズレスとまでは言わないが、そこそこ綺麗な絵を出そうとしても10数時間とか余裕で
かかってたりという具合だったので、きっかけがみたいなものがあるに違いない。

今日試したレンダはこんな感じ。もうちょっとレンズは絞った方が良かったかも。



虹色のノイズが残りつづけるのはどうにかならないかなー。色が出るとしても上の画像で
ノイズが出ている場所でなくテーブルに落ちている屈折光の方に色がつくと思うんだが・・・。
薄膜による干渉でノイズがでてるという可能性はモデルとしてありえないし。


使い方というかコツとか相性みたいなものが未だにつかめていない感じ。

---------------------------------------------------------------
コメントなどありましたらこちらへ->web拍手

2010年6月10日木曜日

六角ナット

たまにネジとかドリルとか作りたくなる病がひさびさに発症したので作ってみた。



BooleanとかEdgeSplitを使うとポリゴンが増えがちになるのでここまではSubSurfだけで
頑張ってみた。ネジ穴はScrewを使わざるを得ないが、Booleanは固い決意で拒絶。

リリースされたばかりのLuxRenderのRC3を使いたかったけど設定が詰められず。
というわけで久しぶりにblenderの内蔵レンダを使ってみた。



金属っぽさはそこそこよさげだけど、ごまかしたネジ穴がやっぱりいまいちだなー。
とくに最初の一山分の違和感が目立つ感じ。

気をとりなおしてノードでいじってみた。



微妙過ぎて分からないけど被写界深度ボケとか使ってみた。
ノードは面倒くさそうなので使ってなかったけどいろいろできるのね。ちょっと楽しい。


ちなみにうまく行かなかったluxでのテストレンダはこんな感じ。



やたらツヤツヤ、ピカピカなのはマテリアル設定を詰める前なので置いておくとして
手前のネジ穴が鬼門だった。

ライトの光が届きにくい上に、ネジ山が密集している細かい形状。
光量不足の場所や、詳細な形状は画像の収束に時間がかかる。

さらにネジ穴は形状をごまかして、厳密にはありえないメッシュの流れになっているわけで。
形状として厳密には破綻している場所でも、luxはできるだけ光学的・物理的に正しくレンダ
しようとがんばるのかそういう部分が存在するとレンダが一気に遅くなる。
いつまでたっても画像が収束しない感じ。

時間かけたらどうにかならないかと4時間レンダリング回してもこの有様だよ。orz


まぁluxの苦手なところとblenderの内蔵レンダラとノードの使い方が何となく分かったので
結果オーライということにしてみる感じで。

---------------------------------------------------------------
コメントなどありましたらこちらへ->web拍手

2010年6月7日月曜日

LuxRender 0.7RC3リリース

早いものでRC2からもう一ヶ月。
というわけで、RC3が無事リリースされた模様

リリースノートでアナウンスされている変更点としては
・GUIの改善
・多くのバグフィックス
・インテグレータのパストレース時にnullやarchitectural glassといった
透過マテリアルもバウンスがカウントされるように変更
といった具合。

バグフィックス中心という内容ですが、じつはひっそりと大きな進歩がありました。

ついにblender2.5系対応のエクスポータが今回のRC3に合わせて公開されました。
入手はRC3、LuxBlend25beta01ともに上記の公式フォーラムのスレッドから。

とはいうもののLuxBlend25は依然ベータ版という位置づけなので2.4系のluxblendと
比べてまだ見劣りするところが多いですが、こんな感じにレンダリングはできます。

これまでLuxBlend25は開発者向けのリポジトリからダウンロードする必要が
あったんですが今回のベータ版公開で多くの人が試すことができるようになって
開発へのフィードバックも増えて、開発もスピードアップしたりするといいなぁ。



---------------------------------------------------------------
コメントなどありましたらこちらへ->web拍手

2010年6月5日土曜日

pyImportance2DThicknessShaderを改造してみた。

某所で見かけたpencil+の他のオブジェクトを参照してエッジ描画を制御する
距離減衰機能のデモがおもしろそうだったのでFreeStyleでやってみた。

というかpyImportance2DThicknessShaderなんて便利なものが標準のシェーダに
あったのでそれをベースにコントロール用のオブジェクトを参照するように改造。

赤い球がコントローラ。こいつを動かすと線が太く強調される場所も動いてついてくる。




座標の変換とか行列の扱い方がよくわからんのでその辺はだいぶいい加減。
むかーし授業で習ったような気がうっすらとするので思い出しつつそれっぽく
適当にやったら何となくそれっぽい結果に。

しかし、そのへんの適当さやコントローラのz座標を無視してたりとかもあってか
微妙に太くなる位置がずれる。3DCGのための数学みたいな本がいくつかある
みたいなんで良さげなのを買ってきて久しぶりに勉強してみるかな。


---------------------------------------------------------------
コメントなどありましたらこちらへ->web拍手