2010年11月17日水曜日

オブジェクトごとのスタイルモジュールの割り当て

FreeStyleを使っていて不便だと思っていたのが指定したスタイルモジュールがシーンに
存在する全てのオブジェクトに適用されてしまうところ。blender標準のエッジも同様の
仕様なんだから仕方が無いというか、そういうものなんだろうと思っていました。

が、よく調べたらFreeStyleの公式ブログの進捗情報にヒントを発見。

詳細は上記ブログを見てもらうとして、ポイントはビューマップに存在するエッジがどの
オブジェクトのものなのか?が参照できるようにになっていたという点。上記ポストには
これを利用してシーンに存在するオブジェクトの名前を指定して、そのオブジェクトの
ビューエッジを取得するObjectNamesUP1Dクラスがサンプルとして掲載されています。

こんな感じ。

class ObjectNamesUP1D(UnaryPredicate1D):
    def __init__(self, names):
        UnaryPredicate1D.__init__(self)
        self._names = names
    def getName(self):
        return "ObjectNamesUP1D"
    def __call__(self, viewEdge):
        return viewEdge.viewShape().getName() in self._names

これを利用して

upred = AndUP1D(QuantitativeInvisibilityUP1D(0),
                ObjectNamesUP1D(["Cube"]))
Operators.select(upred)

とするとカメラから見えて、かつCubeという名前のオブジェクトに含まれる、という
条件に当てはまるエッジが取得できるという仕組み。

早速これを利用したスタイルモジュールを作成して実際にレンダリングしてみました。
まずはこんなシーンを作る。



これを各オブジェクトに異なるスタイルモジュールを指定してレンダするとこんな感じ。



やったことは

最初にシーン全体に対して汎用な設定のモジュールでエッジを描画。
次にシーンのSuzanneには左上から順にm01からm12までの異なる名前をつけてあるので
  上段(m01〜m04):それぞれ色を変更したスタイルモジュールで上書き
  中段(m05〜m08):それぞれエッジ検出とタッチを変更したスタイルモジュールで上書き
  下段(m09〜m12):最初に指定した汎用設定の描画のまま上書き無し
という感じ。

ファイル構成としては最初はシーンで使うスタイルモジュールを1個にまとめられないかと
いろいろ試していました。が、スタイルモジュール中で一度作成したビューエッジのを
解放、もしくは上書きしてビューエッジを再作成する、というのがうまく出来ず・・・。
結局シーンで使用するスタイルの数だけスタイルモジュールを作成しています。

というわけで、上記シーンの下段4つは個別のスタイルを割り当てていないので使用した
スタイルモジュールの数は、m01〜m08用にそれぞれ設定を変えた8個+全体描画用の
汎用設定1個の合計9個を使用しています。

ついでに上記シーンのファイルをこちらにアップしてみたり。

個別設定のスタイルモジュールsmod_m01.pyからsmod_m08.pyの8個、全体設定用の
スタイルモジュールのsmod_main.py、シーンの.blendファイルが含まれています。
freestyle関連は設定済みなので、ファイルを開いてレンダすればスタイルモジュールを
適用した状態でレンダされるはずです。

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

2010年11月12日金曜日

osxとnvidiaな環境でLuxRenderをビルドしたり。

前回からのつづき。ようやくLuxRenderのビルドもできるようになりました。

いろいろてこずったんでメモ。
luxraysがすんなりいったのでluxも楽勝だと思ったらそうでもなかった。

参考にしたのはLuxRender公式wikiとフォーラムのこのあたり。
・[Tutorial] Build on Mac OS X with Xcode
・OSX-renewing buildprocess -out-of-the-box-compile-
・LuxRays - Building on Mac OS X
手順は、必要なライブラリやツールを準備、ソースのダウンロード、ビルド設定
ファイルの編集、Xcodeのプロジェクトファイル出力、Xcodeでビルド、という感じ。
詳細は以下に。


1. ライブラリやツールの準備

必要なパッケージの明細は上記リンク先で確認するとして、ここでは嵌った点のみメモ。

ひとつはcmake。
portで導入するとバージョン2.8がインストールされるけど、いろいろ調べるとcmakeは
バージョン2.6が推奨らしい。またフォーラム等ではgui版を利用した手順の方が比較的
多く目についた感じ。

というわけでcmakeはこちらからGUI版のcmake2.6.4のdmgパッケージをダウンドード
して インストールするのがおすすめ。既にportで2.8をインストールしていてもport版は
 /opt/local/bin、dmg版は/usr/binにインストールされるので併存させても問題無さげ。
ちなみに一応2.8でも試してみたけどうまくいかなかった。cmakeのバージョン以外に
問題があった可能性は否定できないけど推奨環境にしておくのに越した事はない。

もう一つはQt。
こちらもportでインストールしたものだとOSX SDKのフレームワークのインストール先に
Qt関連のフレームワークセットが作成されず、Xcodeでビルドする際に面倒なことに。
なのでQtもdmgで配布されてるインストーラ付きパッケージを利用するほうがよさげ。
こちらからQt SDK for Mac(LGPL版)をダウンロードしてインストールすればOK。

最後にLuxRenderの最新の開発版をビルドする場合にはLuxRaysライブラリが必要に
なるので、そちらを先にビルドしておく。その辺は以前すませているのでここでは省略。


2. ソースのダウンロード

mercurialを使ってcloneする。
$ hg clone http://src.luxrender.net/lux
$ hg clone http://src.luxrender.net/luxrays
$ hg clone http://src.luxrender.net/macos
src.luxrender.netからclone出来ない場合はbitbucket.org/luxrenderを試すと良さげ。


3. ビルド設定ファイルの編集

cmakeの設定ファイルであるCMakeLists.txtを自分の環境に合わせて編集。
途中いろいろいじったけど、結果的にはOpenCL関連の修正だけでよかったみたい。
85行目あたりにあるOPENCL_INCLUDE_DIRSとOPENCL_LIBRARYの部分を前回の
LuxRaysの時と同様に修正しておく。


4. Xcodeのプロジェクトファイル出力

最初にインストールしたcmakeのGUI版を起動する。
"Browse Source"のボタンをクリックしてcloneしてきたluxのフォルダを指定。
"Browse Build"のボタンをクリックしてこちらも同じフォルダを指定。
次に下にある"Configure"ボタンをクリックすると出力ファイルの形式を尋ねられるので
ファイル形式は"Xcode"、オプションは"Specify options for cross-compiling"を指定。



で、"Continue"をクリックして次に行くとプロジェクト詳細設定のダイアログが表示される
ので下図のように設定。OSやSDKのバージョン、CPU種別は各自の環境に合わせ要変更。



で、"Done"をクリックすると最初のウィンドウに戻って設定が始まる。プログレスバーが
進んで完了してもリストのアイテムがいくつか赤いままに残っている場合は、"Configure"
ボタンをクリック。再度設定が行われると赤いのが消えるはず。設定が問題なく済めば
"Generate"ボタンが有効になるので、それをクリックしてXcodeのプロジェクトファイルを
出力させる。luxのソースフォルダにlux.xcodeprojというファイルが作成されていればOK。


5. Xcodeでビルド

まずは先ほど出力したプロジェクトファイルをXcodeでひらく。
メニューの"プロジェクト"→"プロジェクト設定の編集"でビルド対象のアーキテクチャや
最適化オプションを自分の環境に合わせて指定。あとはメニューの"ビルド"→"ビルド"して
完了するのを待つ。問題なく完了すればソースフォルダのRelease以下にLuxRenderを
はじめとするビルドされたファイルがあるので起動してみる。



こんな感じのウインドウが表示されればOK。

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

2010年11月8日月曜日

nVidia GPU環境でのslgとLuxRenderビルド

さらに続いてはSmallLuxGPU(というかLuxRays)とLuxRender。

Ubuntuのデスクトップでslgをビルドするための環境を構築したときの経験をもとに
今度はnVidiaのサポートからOpenCL SDK的なものをダウンロードしてくるんだろうなーと
探してみる。

が、OpenCL SDKのダウンロードリンクらしきものが発見できず。

とりあえずOSX用のCUDA Driver、CUDA Toolkit、CUDA SDK入手してインストールすると
/Developer/GPU Computingのフォルダが作成され、OpenCL関連のファイルも含まれている模様。

が、いろいろ試してみてもうまくビルドが成功しない・・。

再度グーグル先生に聞いたらLuxRenderの公式wikiにosxでのビルドについて詳しく書いてあった。

気になってたOpenCL SDKについても説明されていて、Khronos Groupが提供しているcl.hppを
利用してビルドすればOKとのことらしい。ただし、自分の環境ではwiki通りにやっても1カ所
うまくいかないところがあった。cmakeするともらってきたcl.hppが見つからないため正しく
インクルードされず、ビルドエラーがいくつか発生する。

なのでinclude/luxrays/luxrays.hの34行目
#include <OpenCL/cl.hpp>を
#include <cl.hpp>に変更すると今度はエラーなし。

であとはいつものようにmakeしてビルドが完了するのを待つだけ。無事にビルドできたら

$ ./bin/slg

としてデモモードで起動してみる。ちゃんと起動すればいつものウインドウが表示される。



こんな感じ。LuxRenderはまさに今ビルドしているところなのでとりあえずここまで。

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

MacPorts導入とblenderビルド

というわけでまずはMacPorts導入から。

MacPorts自体の入手先とかも含めていろいろ忘れてたのでまずはここを読んで復習。
・MacWiki-MacPorts

MacPortsをインストールしたらblenderをビルドするために必要なものを確認。
・Building Blender 2.5 for Mac

portで明示的にインストールしたのは下記のもの。
実際は依存関係解消に必要な他のパッケージも自動的に追加されてるけど面倒なので省略。

mercurial
cmake
boost
freeimage
qt4-mac @4.7.0 (aqua)
glew
doxygen

boostは+python26とかオプションをつけておかないとboost_pythonが無いって
いろんなところから怒られる。

あとよく考えたら+universalをつけておいたほうが良かったのかもしれない。
で、ビルド時に基本-m64なり-march=core2とかして、だめなら-m32で妥協する作戦の方が
良さげな予感も一瞬したけど気にしない。

ここまでできたらblenderがビルドできるか先にテスト。
まずはソースもらってくる。
$ svn checkout https://svn.blender.org/svnroot/bf-blender/trunk/blender
$ svn checkout https://svn.blender.org/svnroot/bf-blender/trunk/lib/darwin-9.x.universal

で、ここをみるとffmpegがシステムにインストールされている必要があるとのことなので
あらかじめインストールしておく。ついでにsconsもいれておく。

$ sudo port install ffmpeg
$ sudo port install scons

無事にblenderはビルドできたので次はSmallLuxGPUとLuxRender。

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

新Air購入を検討していたと思ったらMBP13インチを買っていた

・・何を言ってるのかわから(ry

というわけで、新マシン投入に伴う作業環境の移行・再構築関連でいろいろメモ。
基本的にメインはノートで作業。本番の重いレンダリングはデスクトップという体制に。


Ubuntuなデスクトップを自作して以降、ほぼそちらがblender専用マシンとなっていたわけです。
が、アニメーションやLuxRender、SmallLuxGPUなどで長時間レンダリングをすることが増えて
レンダとそれ以外の作業用でマシンを分けたいなーと感じることが多くなったり。

また、これまでMacBookで動作を少しでも軽くするため表示モードの切り替えやレイヤー分けを
駆使しつつモデリングしていましたが、デスクトップのGLSLでテクスチャ表示したまま作業できる
環境を体験しまうと不便さは否めない感じ。さらに今のMacBookは初Macとしてここ4年以上に渡り
メイン環境としてよくがんばってくれましたが、さすがにあちこちガタが出始めている感もあり
・・・といった状況。

というわけで、今年に入ってからずーっと検討していたMacBookの買い替えを実行。
初めは新Airを考えていましたが、そこまで可搬性は必要ないのとユーザーによるストレージ、
メモリ増設の可否、有線LANの有無を考慮して最終的に後継はMacBook Pro 13インチに決定。

MBPは旧MBと同様チップセット内蔵GPUとはいえ性能の差は歴然。テクスチャ表示しながらでも
さくさくです。ついでにCPUも64bit対応になったのでビルド環境も含めてまっさらな状況から
構築しなおしてみました。

長いのでわけました。
・MacPorts導入とblenderビルド
・nVidia GPU環境でのslgとLuxRenderビルド

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

2010年10月28日木曜日

blender2.55とLuxRenderとかSLG

いつものように手元のsvn版を更新して起動してみると何かがおかしい。
何か雰囲気が・・と思ったらスプラッシュスクリーンが変わって2.55.0の文字が!



一応自前ビルドした2.55.0(r32749M)で確認したところluxblend25、render_smallluxgpu
どちらも使えたので、今までどおりLuxRenderやSmallLuxGPUでのレンダも大丈夫かと。
めでたい。

ひとつ前の2.54のときもsvnのスプラッシュが変更されてから、公式に配布が開始されるまで
それほど時間はかかっていなかったはずなので今週末辺りには配布がはじまるのでは・・。

また2.54での話ですが、2.4と2.5系のデータ互換性に関してモデリングとボーン入れまではOK、
一部コンストレインが非互換というのを最近教えてもらったので、2.4をLuxRenderの動作確認
とモデリングデータ変換用のバックアップ、2.5をメイン環境でしばらく併用していきたい感じ。


最後に拍手お返事とか。


>私の環境ではluxBlendを使ってもまったくテクスチャが
>反映されないんですが、どうすればいいんでしょうか・・?


・・・luxblendってことはblender2.49bですよね・・・。


『まったくテクスチャが反映されない』という状況はちょっと記憶に無いですね。
テクスチャの『位置が反映されない』ならばマッピング関連の設定かと思うのですが・・・。
お役に立てずすみません。

どんな状況でもここではなく、より多くの人が集まるほかのCG関連の掲示板やフォーラムで
質問する方がよいと思います。同じ問題を経験して既に解決済みの方もいるかもしれませんし。

LuxRenderの公式フォーラムにもユーザーサポートのカテゴリーがあるので、そちらを利用しても
よいかと思います。設定や使用法の問題でなくバグである可能性まで考慮すると、一度は公式な
情報を確認しておいた方がいいかもしれません。

フォーラムの閲覧はアカウントが無くても可能ですが、アカウントを作成して質問を書き込んで
しまうのが一番早いと思います。アカウント作成はメールアドレスだけあればいいので簡単です。

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

luxとSLGのテクスチャとエミッタを調べてみた

blenderでテクスチャを貼ったデータをSmallLuxGPUやLuxRenderでレンダしてみたら
テクスチャが正しく表示されないことがあるのでいろいろテストしてみたり。

テストの結果からすると
・SLGではオブジェクトのエミッタがオンの場合テクスチャが無視されて表示されない
・SLG、lux共にテクスチャにアルファ付きのpngを使用すると透過情報が正しく反映されない
という状況っぽい。


やったテストはこんな感じ。
まずはテクスチャ用の画像を作成してアルファ付きのpngファイルとして保存。



でblender2.54でテクスチャを貼ったオブジェクトを作成して、テクスチャのuse alphaとemitの
ON/OFFを切り替えてレンダするとこうなる。



左からemit:OFF,alpha:OFF/emit:OFF,alpha:ON/emit:ON,alpha:OFF/emit:ON,alpha:ON。
blenderでレンダした場合はこんな感じにほぼ意図したとおりの結果に。


次に上記のシーンをrender_smallluxgpuを使用してSmallLuxGPUでレンダしたのが下の画像。
emitとalphの組み合わせはblenderのレンダ結果と同じ順。



最初の2つのemitを設定していない場合を見ると、alphaの状態にかかわらずpngの透過情報が反映されている。さらにテクスチャで無くオブジェクト自体がアルファ抜きされて肉が抜けている。
後ろ2つのemit有効の場合ではどちらもテクスチャが表示されていない。

という状況なのでSLGでテクスチャに使う画像は透過情報を持たないフォーマットの方が混乱が
少なくてよさそう。ただエミッタ設定とテクスチャが併用できないのはどうしようもないかなぁ・・・。


最後にLuxRenderでレンダするとこんな感じ。エクスポータはluxblend25、luxはv0.7.1開発版。
luxではテクスチャのもつアルファ情報の使用を切り替えるオプションがないので
アルファ無し、有り2種類のテクスチャ作成してレンダ。なので順番としては、左から
emit:OFF,alpha:無/emit:OFF,alpha:有/emit:ON,alpha:無/emit:ON,alpha:有。



テクスチャにアルファ有りのpngを使用した時の結果がおかしいのはSLGと同様。
ただしluxの場合はエミッタを設定していてもテクスチャは表示される模様。
面の周囲の黒い縁取りが表示されてないのはuv座標のオフセットがずれたのかも。
おそらくエクスポート時の設定で調整できるはず。


というわけで、普通に使うならおとなしくLuxRenderを使用するのが良さげ。
SmallLuxGPUは開発者向けのテスト兼デモプログラムという扱いなのであまり突っ込んでも
意味がないので、OpenCL対応という点では次のLuxRender v0.8に期待したいところ。

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