その2:LuxRenderでのポストワーク』にて、LuxRenderのNetworkタブの解説として、ネットワーク上の他のコンピュータにレンダリング作業を分散させるネットワークレンダリングについて少し触れました。今回はそれがどのくらい有効なのか、実際のレンダリングで検証したいと思います。LuxRenderでのレンダリングは非常に時間のかかる作業です。そのため、GPUによるレンダリング補助(将来のバージョンで導入される予定です)やネットワークレンダリングが用意されているのです。シーンの複雑さによってメモリ使用量が増大するため、レンダリングを行うPCの性能が求められるということは何度かお伝えしてきました。ネットワークレンダリングの作業を分担するスレイブPCがWindowsXP(32bit)では難しいので、今回は64bitLinuxにLuxRenderをインストールしてスレイブとして使うということまでやってしまいます。※LuxRenderのネットワークレンダリングでは、スレイブPCのOSを問いません。■ネットワークレンダリングの方法まずは簡単にネットワークレンダリングの仕方をおさらいしておきます。※最初にLuxRenderでレンダリングを始めたPCをマスター、作業を分担するPCをスレイブと呼びます。(1)スレイブPCでluxconsoleをサーバーモードで起動します。Slave」というショートカットがあるので、それを実行して下さい。Addressを覚えておいて下さい(表示されない場合はifconfigなどのコマンドで確認します)。luxconsoleとはコマンドラインベースのLuxRenderで、GUIはありませんがもくもくとレンダリングをしてくれるいいヤツです。Addressを入力、+ボタンをクリックします。(3)データがスレイブPCに送られるのをじっと待ちます。Intervalの秒数毎にスレイブPCからレンダリングデータが送られてくるようになります。・スレイブPCでのレンダリングを終了したい場合は、マスターPCのLuxRenderのNetworkタブを開き、Server欄の-ボタンをクリックしてから、スレイブPCのコマンドプロンプトを閉じます。・マスターPCのLuxRenderを終了させると、スレイブPCのluxconsoleは待機状態になります。・マスターPCのLuxRenderでレンダリングをPauseまたはStopした場合でも、スレイブPCではレンダリングが継続し、マスターPCへデータを送り続けます。ネットワークレンダリングをするにはLAN上の他のPCとデータのやり取りをしなければいけません。そのため、アプリケーションの予期しない通信をブロックするファイアウォールソフトが邪魔をしてしまう場合があります。私の場合はWindows7をスレイブとした時Windowsファイアウォールが通信をブロックしていたので、それを許可する必要がありました。ファイアウォールを介したプログラムまたは機能を許可する」をクリックします。Slave」を探してチェックを入れます。ホーム/社内(プライベート)にチェックの入っている方でいいようですが、環境によって変わってくるかもしれません。■Linux版LuxRenderのインストールさて、上記の方法で2台のPCを使ってネットワークレンダリングをしようとしたのですが、以前の記事でも書いたように問題がありました。それは、簡単なシーンしかレンダリングできないという点です。スレイブPCとして使おうと思っているマシンは4GBのメモリを積んでいるものの、32bitのWindowsXPです。その5:32bitWindowsでの運用』の記事で書いたように、V4フィギュア1体置いただけでもテクスチャの量によってはエラーで止まってしまいます。スレイブとして使うPCではLuxRenderはマスターの時よりも多量のメモリが必要になるようです。※後でわかったことですが、ネットワークのスレイブとなるPCではテクスチャの管理が非効率になってしまっているようです。V4の胴体マテリアルの場合Diffuseテクスチャは1枚しか使われていないのですが、SpecularとBumpテクスチャは同じものが5枚ずつ(マテリアルの数だけ)使われていました(ログとテンポラリフォルダで確認)。DS上で隠したオブジェクトやパーツもマテリアルファイル上では記述がされているようで、その分のテクスチャもスレイブPCに送られるようです。LuxRenderの問題なのかRealityの問題なのかは不明です。そこで、無料で導入できる64bitのLinuxをインストールしようと考えました。ここで私がやった通りに手順を書いても、環境によって同じ工程が必要になるかはわかりませんし、OSのインストールには自分で調べてできるぐらいのスキルがないと危険だと思いましたので、飛ばします。いけば、30分ぐらいで起動まで持っていけます。私にとってのチェックポイントはWindowsとのデュアルブートと、マルチディスプレイでした。私は初Linuxでしたので、無数にあるディストリビューションの中から導入が簡単だと言われているUbuntu10.04(AMD64)を選びました(AMDと書いてありますがIntel機でも使えるようです)。ここから、Ubuntu(AMD64)にLuxRender(バイナリ)をインストールする手順を解説します。64bit」をダウンロードします。※マスターPCと同じバーション(Reality1.01だとv0.7)をダウンロードして下さい。選択し、ダウンロードフォルダを開きます。(3)ダウンロードしたファイル(luxrender-0.7-x86_64-sse2.tar.bz2)をダブルクリックします。(4)書庫マネージャが開きますので、ファイルをデスクトップに展開します。アプリケーション>アクセサリ>端末を選択します。(6)端末が起動しますので、そこでルート権限でファイルマネージャを起動します。nautilusと入力しENTERキーを押します。するとアカウントのパスワードを聞かれるので、入力してENTERキーを押してください。(8)デスクトップ上の(4)でできたフォルダを開き、その中の実行ファイルを(7)のウィンドウにドラッグ&ドロップします。※画像では全部移動させていますが、LuxBlend_0.7.pyとpylux.soはBlender用だと思いますので必要なさそうです。(9)端末のウィンドウをクリックした上でCtrl+cキーを押してファイルマネージャを終了し、端末を閉じます。必要があれば、パネルのアプリケーションメニューやデスクトップにLuxRenderを登録してください。■Linuxをネットワークスレイブにするさて、無事にUbuntuのインストールとLuxRenderのインストールまで済ませました。これがどのくらいの性能を発揮するのか、このようなシーンで確認してみました。32bitを使うとメモリが足りなくてエラーになってしまいます。そこで、スレイブPCのOSを64bitLinuxに変更し、レンダリング性能を計測します。マシンの性能はこのようになっています。512MBスレイブPCの起動直後の使用メモリ量は約530MiBです。上のシーンのレンダリングが始まると3.3GiBまで使用します。※単位はWindowsで表記されるMB、GBと同じです。32bitではエラーが出てしまう量です。2026S/px2倍近くスピードアップがされていることがお分かりいただけたでしょうか?予想以上の効果です。このスレイブPCではメモリが4GBしか積まれていませんので周りに何もない寂しいシーンになってしまっていますが、もっとメモリを増やせば複雑なシーンでも大丈夫です。一応搭載メモリ量をオーバーしても、HDDのスワップ領域を使うのでレンダリングはできるのですが、速度がガクンと落ちてしまうのでメモリ容量内での使用をオススメします。このコスチュームが気に入ったので別ポーズでもう1枚レンダリングしました。2036S/pxもう少し突き詰めてみようとCUI環境でUbuntuを起動してGUI(GNOME)に使う分のメモリを削減してみました。その場合の起動直後のメモリ使用量は283MiBと、かなり減ります。UbuntuのCUI起動にはGrub2の設定を書き換える方法を使いました。Ubuntuマシンをネットワークレンダリングにだけ使うならコマンドラインだけで十分ですし、問題なくluxconsoleも起動できましたので、これも有効ではないかと思います。■Linux版LuxRenderでのレンダリングここからはおまけコーナーです。前の記事でWindows32bit環境しか無い場合に、レンダリングのためにLinux64bitを導入するのをご提案しました。今回せっかくその環境ができたので、ネットワークスレイブとして使うだけではなくスタンドアロンでレンダリングしてみようと思い立ちました。Studioはありませんので、LuxRenderに渡すファイルはWindows32bit上で作成します。・Linux上からテクスチャデータが入ったWindowsのパーティションへアクセスする必要があります。・LinuxはUbuntu10.04(AMD64)で話を進めていきます。※上でご紹介しているように、ネットワークレンダリングのスレイブとしてLinuxを使う場合は、次のような手続きは必要ありません。アプリケーション1つを立ち上げておくだけで大丈夫です。Studioでシーンを作成し、LuxRenderでレンダリングを始めます。メモリオーバーしてしまってレンダリングができないとしても諦めず、できたファイルの場所を覚えておきます。(2)WindowsをシャットダウンしてUbuntuを起動します。(3)ホームフォルダに作業用の「Reality」フォルダを作成します。(4)Windowsのパーティションをマウント(上のパネルの場所メニューから目的のものをクリックするだけです)します。(5)Realityフォルダへ(4)から(1)で作成されたファイル(lxm、lxo、lxsの3つ)をコピーしてきます。(6)lxmファイルをgeditなどのテキストエディタで開き、テクスチャのパスを書き換えます。UbuntuでマウントしたWindowsパーティションは「/media/<パーティション名>/」というパスになります。Linuxではファイル名などの大文字小文字が別のものとして判別されてしまいますのでご注意下さい。WindowsのC:\/Poserdata/Runtime/Textures/Mytexture.jpgというパスが、Ubuntuからは/media/ボリューム/Poserdata/Runtime/Textures/Mytexture.jpgとなったりします。※テクスチャがたくさんのランタイムから使われている場合は、いっそテクスチャフォルダを全てUbuntuのパーティションへコピーしてしまうのが簡単かもしれません。filename"のパスも書き換えます。(3)の通りだと/home/<ユーザー名>/Reality/というパスになりますね。(8)LuxRenderを起動して、(3)のファイルをOpenしてレンダリングを開始します。この方法を使えば、アプリケーションのメモリ2GB制限から解放されるために、結構複雑なシーンでもレンダリングできるようになります。この方法で一番のネックになるのが、シーンを調整するのにはWindowsへ戻らなくてはいけないという所です。いちいちPCを再起動するのにはちょっと大変ですよね。LuxRenderのメモリを圧迫する一番の原因はテクスチャの解像度です。そこで、Windows側では低解像度のテクスチャを用意して使い、Ubuntuでテクスチャのパスを書き変える際に高解像度のテクスチャへ変えてしまう、というのはどうでしょうか?64bitのWindows7などを購入するのが一番なんですけどね。同じシーンをレンダリングした時の速度を比較してみました。67311S/s※同じマシンでOSを変更した環境での比較です。V4,CommentCloud私はこういう用途ならば、クラウドを利用するのが現実的な解であろうと思います。Azureなら実現可能です。いうのも、使用するCPU時間は知れてますし処理データ>転送データ量なのでクラウドの難点である転送データ量の料金を削減できます。プランさえ過たなければそれ相応のスペックのマシンを用意できますし。必要がなくなればインスタンスごと廃棄して課金対象から外せますしね。あと、マシンのコンフィグレーションが限られているのでパフォーマンスをたたき出すためのチューニングもしやすいですし。CloudG.O.R.Nさんはじめまして、ご訪問ありがとうございます。レンダリングにクラウドサービスを使うのはアリですね。企業ではCGアニメーション作品をクラウドでレンダリングしている例もあるようですし、コストさえ許せばかなりの時間短縮になるのは容易に想像できますね。EC2を利用したクラウドレンダリングの手順を紹介してくださっている方がいらっしゃったのでビックリしました。2.0になってLuxRenderでアニメーションをレンダリングするようになったら、クラウドサービスくらいのものを使わないと厳しそうですね。*...麗らかなり...*.。