まずはLightWaveのネットワークレンダリングシステムがどのようになっているかを理解する必要があります。とは言ってもLightWaveのネットワークレンダリングシステムは非常に単純です。ScreamerNetの概念は以下の図のようになっています。
ScreamerNetはレンダリングするLWSNとそれを集中的に管理するLigthWaveから構成されます。LWSNとLightWaveが協調して動くために共有領域が必要になります。
LWSNは動作を開始すると共通領域にあるAckに開始したことを書き込みます。
LightWaveで「ネットワークレンダリング」-「スクリーマの初期化」を実行するとAckファイルを調べ、動いているLWSNを確認します。これでLWSNとLightWaveはお互いを認識するようになります。
これ以降ネットワークレンダリングが可能になります。
ネットワークレンダリングが開始されると、LightWaveはJobファイルを使ってレンダリングするシーンとフレーム番号を知らせます。
シーンファイルの中には以下のような情報が入っています。
レンダリングすべきオブジェクト名 proj/obj1.lwo
使用しているテクスチャ proj/img/tex.jpg
出力先 img/out****.tif
フォーマット TIFF
これらはすべてコンテントディレクトリを基準に動作します。
LightWaveやLWSNはデータの入出力やシェーダーの多くをプラグインに依存しています。これらのプラグインはｃｆｇファイルによってディレクトリが指定されいます。
ｃｆｇファイルが異なったり、参照しているディレクトリが違うと正常に動作しない場合があります。左図の例の場合、jpegの入出力やSasquathを使用しない場合は正常にレンダリング出来ますが、それらを利用したシーンのレンダリング結果に不整合が発生します。
ここでまとめるとSceamerNetは
さて、上記のことを踏まえてレンダーファームを構築して見ましょう。
今回構築するシステムは以下のような構成になっています。
また、ThinkPadは持ち歩く為、ネットワークが接続されていなくても同じ様に動作する必要がありました。ここが放牧タイプと名前をつけている由縁です。(^_^;)
この要求から今回はすべてのマシンの構成を以下のように定義しました。
このｚドライブとｙドライブの定義を状況に応じて切り替えることで柔軟性と即応性を確保しています。
メインマシンであるThinkPadは以下のようなコマンドをログイン時に実行しています。
subst z: c:\LightWave
subst y: c:\user\gra
ネットワーク接続でｚ/ｙドライブの設定を行っていないのはThinkPadの起動を考慮した為です。substはローカルのHD内のディレクトリをドライブに割り当てる命令です。ローカルHD内の命令なのでネットワーク接続の有無にかかわらず実行速度は一定になります。
一方、レンダリングサーバは二通りの設定方法を持っています。一つはThinkPadが接続されていてネットワークを共有している場合、もうひとつがThinkPadがネットワークから切り離された状態で双方がレンダリングする場合です。
ネットワークを共有している場合は以下のコマンドでネットワークを接続します。
net use z: \\ThinkPad\LightWave /persistent:yes
net use y: \\ThinkPad\gra /persistent:yes
LightWave階層自体をネットワーク経由で接続し、そのディレクトリ内部にあるEXEやPluginを使うことで前章の３番目の項目「同じプラグインを共有した方が良い」をクリアしています。
ThinkPadがネットワークから切り離された状態で双方がレンダリングする場合はsubset命令でローカルのディレクトリをx/yドライブに設定します。
subst z: c:\LightWave
subst y: c:\user\gra
独立して動かす場合は予めコンテントディレクトリの内容をコピーしておく必要があります。
予めz/yドライブを準備してからLightWaveのインストールを行うとｃｆｇファイルの内容を変更する必要がなくなります。インストール時に作成されたcfgファイルをｚドライブに移動しそれを参照することでｃｆｇファイルの整合性を保つことが出来ます。
今回はノートがメインという変則的な構成だったこともありドライブを共通化する方式を取りました。しかし、この方式はドライブ名を使う為Linuxと相性がよくありません。今後Linux版LWSNが本格化した場合、構成をネットワークパス名方式に変えていく必要があります。
LWSNには独立して動く「-3」モードが存在します。「-3」モードを使うとLightWaveを起動せずにレンダリングを行うことが出来ます。
多くの人は「ネットワークレンダリングが行えるのに単独でLWSNを動かす必要が無いじゃないか」と思うかも知れません。しかし、ネットワークレンダリング中はLightWaveで編集することが出来なくなります。複数のLayoutを立ち上げれば他のシーンを編集出来ますが、負荷の問題から現実的ではありません。
このような場合、他マシン上でレンダリングを行い、メインマシンで別のシーンの編集やモデリングを行う事で効率的にレンダリングが可能になります。
LWSNを単独で動かす場合、LWSNコントローラを使うと操作が簡単に行えます。
LWSN コントローラー（LwsnC.exe）ツールはLWSN「-3」モードのレンダリングを制御するコントロールアプリケーションです。DStormのホームページからダウンロードすることで入手可能になっています。
もし、WindowsXPを使用しているならば、 リモート デスクトップ機能を利用して見ましょう。
リモートディスクトップとは他のマシンを遠隔から操作する事が出来るWindowXPのツールです。複数台のマシンを使うときディスプレイやマウス、キーボード等を複数個操作しなければならず非常に面倒でした。このリモートディスクトップならば操作感的にはリモートマシンとメインマシンの違いは感じられません。全画面表示にすればタスクバーもリモートマシンのものを操作することが出来ます。
LightWave7.5bにはLinux版 LWSNが追加されました。今後、大規模なレンダーファームを構築していく上でLinux版の存在は非常に重要です。
複数のマシンにWindowsXPをインストールするとOS代が大きなウェイトを締めることになります。また、レンダリングサーバはGUIも使用しないのでWindowsXPでは冗長です。こうした場合Linuxを使うとOS代を節約出来、GUI等もユーザが調整出来る為CUPパワーをレンダリングのみに使うことが可能になります。
早速、英語版LightWave7.5bからLinux版のLWSNをインストールしテストしてみました。
- rpmで提供されている為、RedHat系のディストリビューションが必要。
- rpm -ivh lwsn-7.5b-582.i386.rpmでlwsnをインストール。インストール後は/usr/share/lwsn-7.5b/に展開される。
- samba上のディレクトリでjobX,ackXを指定できるようにしておく。/mnt/sambaを利用してWindows上のディレクトリをマウントするかLinux上に共有のディレクトリを作成しjob/ackファイルを参照出来るようにする。
- Linux上でPATHは一応通しておく。.bachrcに
PATH="$PATH":/usr/share/lwsn-7.5b
- runsn2.sh /home/nobo/lwsn/job1 /home/nobo/lwsn/ack1
で実行。このときrunsn2.shの中でホームディレクトリを移動するのでjobX,ackXはフルパスで指定すること。
これでLayoutネットワークレンダーの初期化を実行して、種別にLinuxが見つかればOKになります。
ただし、現在はここでドライブ名指定が問題になります。Linuxではドライブの概念がないのでシーン内のモデルやテクスチャの指定がうまくいきません。これに関しては解決策が見つかっていない状況です。
パスを書き換えて(\->/変換する等の作業を行なう)runsn3によって単独でレンダリングすることは可能な様です。しかし、グーローシェーディングが正常に表現されなかった等の問題点もありました。