2010年2月11日木曜日

blender2.5向けLuxBlendについて調べてみた

この前書こうとしてたのはこれだった。思い出したのでメモ。


公式フォーラムのblender2.5向けエクスポータに関してのスレッドでは、ほとんどポストが
ないので、最初のアナウンス以降特に進捗は無いのかと思っていたわけです。
が、久しぶりにLuxRenderの開発版リポジトリを見てみるとluxblend25なるものを発見!


というわけで、早速ダウンロードしていろいろ試してみました。


ただ、結果としては動かすことすらできなかったわけですが。orz

問題としては
・レンダに必要と思われるpyluxモジュールが手元にない
・luxblend25のpythonスクリプトの導入の仕方がわからない。
の2点で全然歯が立たない状況なのが致命的。


luxblend25は2.4系の時みたいにLuxRender形式にファイルを一度エクスポートしてから
LuxRenderを起動して読み込ませるという流れではなく、blenderのpython実行環境を
利用してpyluxモジュール経由でLuxRenderのレンダリングAPIにアクセスするという
感じの流れになるらしい。

なのでluxblend25のpythonスクリプトだけでなくpyluxのモジュールも必要らしい。

というわけでpyluxもリポジトリから入手してみたもののうまく使えず。

自分の環境に合わせてリビルドするためのシェルスクリプトが用意されていたけれど
それでもうまく行かない。LuxRenderのソースコードに含まれるCMakeLists.txtを見ると
pyluxに関する設定らしきものはあるので、自前でビルドすれば自分の環境で動作する
pyluxモジュールは手に入るのかも。


さらに仮にpyluxがどうにかなったとしても、肝心のluxblend25のスクリプトの使用法が
分からない状況。2.4系はscripts以下に入れてメニューからluxblendを選択で良かったけど
2.5系ではそもそもどこにluxblend25のファイルを置いたらいいのかさえよくわからず。
しかもファイルが複数ありフォルダにいろいろ分かれているので、何をどう扱ったら
いいのかもよく分からず。

とりあえず公式wikiを参考にmodules以下に突っ込んでpythonコンソールからいろいろ
試してみたもののUIさえロード出来ず。luxblend25に関しての情報そのものが、そのwikiの
1ページ以外に見つけられなかったので使い方や導入のための設定も調べようがない感じ。


blender.jpのニュースで取り上げられていた2月7日付デベロッパミーティングノートの中の
LuxRenderに関する記述でも、"Blender への適切な拡張・統合作業は、夏以降になると予想
される"とのことなので、まだ開発者本人以外が気軽に試せる状況ではないのかも。
残念。

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

2010年2月9日火曜日

Freestyleのpythonモジュールに含まれる関数の調べ方。

公式ページのサンプルギャラリーではそのスタイルモジュールで出力された画像と
そのスタイルモジュールのソースコードを参照することができる。

で、そのソースコード中でpythonモジュール名がリンクになっている。

そのリンクをクリックするとpythonモジュールそれぞれの中身が表示されるので
モジュールに含まれる関数がわかる、という手順。

おとなしくテキストエディタでpythonモジュールの*.pyを見たほうが早いかも知れない。

ただ、

1. サンプルの絵を見る
2. その絵を出力するためにスタイルモジュールがどんな感じで何をやってるか確認する
3. そのためにはどのモジュールのどんな関数を使うか知りたい

という流れで見ていけるので、逆に自分でスタイルをモジュールを書く際の思考として
"コレをやるにはあの関数が使えそうで、そのためにはあっちのモジュールが必要だな"
的な発想がしやすくなったり、スタイルモジュールの処理の流れみたいなものが理解
しやすいかも知れない。

また、サンプルギャラリーのURLを見ていると、例えばshaders.pyを表示している場合は

http://freestyle.sourceforge.net/GALLERY/python.php?filename=shaders.py&headerfilename=pythonheader.txt
という感じなのでURLに適宜モジュール名を与えてあげれば中身を表示してくれるっぽい。

ちなみにshaders.pyの中には名前の通りそのままshader_listに追加してcreateに使える
シェーダがいろいろ含まれているので、手軽に試せて楽しい。

Freestyle統合版blenderにはスタイルモジュールがいくつか標準で添付されているので
おそらく殆どの人は初めにそれらのスタイルモジュールを試すんだろうけど、いまいち
イメージと違ったり、満足出来なかったり、標準のに飽きてきたりするんじゃないかと。

そんな時こそ以前紹介したような簡単なスタイルモジュールを書いてshaders.pyの中の
シェーダを試して行くとfreestylerとして活動を始めるいいきっかけになるかと思われます。

公式ページにFreestyleユーザーのこと(だと思う)をfreestylerと書いてあって、すごく自由な
感じが良さげなので使ってみたw


今日のわかったこと
・QuantitativeInvisibilityUP1D()は引数が1で陰線、0で見えている線を選ぶ。
今更こんなことに気づいたという。orz。


Freestyle以外にもLuxRender関連で何か書こうと思ったんだけど、だめだ。
今日暖かかったせいかやたら眠いし頭が回らない。花粉症はまだ早いだろうし。
なにか有ったはずってことだけ書いておけば思い出すかも知れないんで、
明日の自分、まかせた。

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


2010年2月2日火曜日

スタイルモジュールとかのメモ

少しずつ勝手がわかってきたのでチュートリアルから脱線して、いろいろ試行錯誤中。
勝手気ままにいろいろ試してるとはまることも多くなるのでちょっとメモ。



-スタイルモジュール編集はblender内蔵でない別のテキストエディタを使った方が良さげ

最初はモデルいじってレンダしつつスタイルモジュールのコード編集ができるので
内蔵テキストエディタをつかってたけど、Freestyle統合版は開発版ということもあり
たまに落ちる。特に当てずっぽうで変なコードを書いてそれを読ませてレンダすると
blenderごと落ちることが多い。

編集中のスタイルモジュールでレンダするにはレンダ前にコードを保存する必要が
あるので、『blenderが落ちたせい』で未保存の編集内容が失われるという自体は
今のところ発生してない。

何が問題かというと、内蔵テキストエディタは自動的にスワップと言うかバックアップ
ファイルを作るらしい。そこまではいいんだが、落ちたあとにblenderを再度起動すると
レンダ前に保存済みの本ファイルでなくスワップの方を開いた状態でテキストエディタを
表示していることがある。

で、スワップの内容は保存した状態よりもだいぶ過去の内容であることがほとんどなので
"あれ、あの関数を追加したとこが消えてる?おかしいな保存に失敗してた?"と思って
同じ作業を繰り返したり、さらに古い内容のスワップファイルで最新の変更内容が正しく
保存されていたであろう本ファイルを上書きしたり・・・orz。

面倒がらずにテキストエディタ起動しとけ<自分



-公式のチュートリアルが作成された時点からモジュールの構成に変更があった?っぽい

最初にやったチュートリアルではモジュールの読み込みを
from Freestyle import *
の一文で済ませている。そのファイルに追記しつつ色々試していると関数が見つからない
という旨のエラーに遭遇。エラーメッセージを見るとNotUP1D()が見つからないらしい。

その関数を使用するスタイルモジュールのサンプルがFreestyle統合版blenderに含まれて
いたので正しくレンダ出来るか試してみるとエラーもなく普通にレンダ開始&終了。
レンダ画像を見てもその関数を利用している部分は正しく機能している感じ。

サンプルのコードを確認してみるとモジュール読み込み部分がチュートリアルと違ってた。

from freestyle_init import *
from logical_operators import *
from PredicatesB1D import *
from shaders import *
from PredicatesU0D import *
from math import *

と言う感じ。
mathはPythonの標準モジュールのはずだけど、その他はFreestyleのモジュールだよなぁ。
from Freestyle import *でFreestyleモジュールを読めば、間接的に他の必要なモジュールは
すべて読み込まれたと思ってたんだけど変更が有ったのかも。
もしくはFreestyle単体版と統合版でモジュール構成がちがう?
ちなみにNotUP1D()はlogical_operatorsにありました。

モジュール関連の情報がないかとFreestyleの公式ページを見てみたらFreestyle File Listって
いうページを発見。そこに各モジュールにどんな関数が含まれるか書いてあるかと思いきや
Cのヘッダファイルのリストでした。

残念。

前にpythonのチュートリアルだかリファレンス的なハンドブックを読んでいたときに
どのモジュールにどんなクラスや関数があるのかを表示する方法を目にした記憶が・・・。
どこで見たっけなぁ。最悪ファイルをエディタで開いて確認してけばいいんだろうけど。

Freestyleのモジュール内容一覧みたいなのがあると便利そうなので調べてみるかな。


今日の進捗はこんな感じ。



ドーナツの内側、手前と奥のラインがそれぞれ3つずつに分かれてたのを1本に、とまでは
行かなかったけど比較的長いストロークにまとめることはできた感じ。
ただ、chain系の操作で接続処理の終了を判定させるための条件を指定するのに、何を
どう指定すればいいのかがわかっていないので、とりあえず繋がったというレベル。

外側の長いストロークを分割する方は手付かず。

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

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

2010年1月30日土曜日

スタイルモジュールの続き

昨日に続いて公式のチュートリアルを斜め読みしつつ、いろいろやってみた。
サンプルのスタイルモジュールでは色が変わるシェーダを使ってたけど、どっちかといえば
線の始点から終点にかけて変わるなら、色よりも線の太さが変わって欲しいところ。

で、チュートリアルの先を読んでいくと既存のクラスを継承して自前のクラスを作る方法や
メソッドを実装する方法なんかが説明してある。

その辺にImplementing your own PredicatesとかShadersとか書いてあるので、そこの
サンプルを試してみた。Predicatesはビューマップに存在する線の中でどれを描画する
対象として選択するかを決定するアルゴリズムのようなもの。Shadersは昨日書いたように
実際に線を描画するためのペンのような感じ。

で、シェーダのサンプルを見てみるとどうやら始点と終点での線の太さを指定して
その範囲で線の太さが変化していくというサンプルっぽい。
以下はそのシェーダ部分のコードの抜粋。短い。
class pyVaryingThicknessShader(StrokeShader):
    def __init__(self, t1, t2):
        StrokeShader.__init__(self)
        self._t1 = t1
        self._t2 = t2
    def shade(self, stroke):
        n = stroke.strokeVerticesSize()
        i = 0
        it = stroke.strokeVerticesBegin()
        it_end = stroke.strokeVerticesEnd()
        while it.isEnd() == 0:
            att = it.getObject().attribute()
            c = float(i)/float(n)
            t = (1.0 - c)*self._t1 + c * self._t2
            att.setThickness(t/2.0, t/2.0)
            i = i+1
            it.increment()
t1が始点での太さ、t2が終点での太さ。
ViewMapから選択された線がひとつづきの線であっても、実際には線分というか
節のようなものに分けられて取得されているっぽい?
この辺の仕様がよくわかっていないのでチュートリアルとあわせてクラスリファレンスとか
読んでくといいのかも。

細かいことはさて置き、まさにこんな感じのが欲しかったところなので早速試してみる。

blenderでこんな感じのシーンを準備。




レンダリングするとこんな感じ。



blender標準のエッジに比べると線に調子がでて良さげ。

ただ、みぎのドーナッツの内側の線が手前、奥ともに3分割されてるのを繋げたいところ。
手前で線が一本、奥で線が一本になるような具合に。
逆に外側の稜線はまるっと一筆で描かれているため、線が長く繋がりすぎていてちょっと
不自然な感じ。こっちは適当な長さで分割したいところ。

といった感じの線の接続・分割もスタイルモジュール内に記述することである程度は
いじれそうなので、次はその辺をいじってみる感じで。

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

2010年1月29日金曜日

Freestyleのスタイルモジュール作成に関してのメモ

Freestyleがblenderから受け取ったViewMapに対して行う処理の種類や流れは

・描画する線の選択
・線の処理(接続、分割、並べ替え)
・線を描画するためのシェーダの準備
・線の描画

というのが大まかなところ。

本家というかスタンドアロン版というか、blender統合でないFreestyleの
公式サイトのチュートリアルにあるサンプルがわかりやすい。
ソースは下のたった4行。
from Freestyle import *
Operators.select(QuantitativeInvisibilityUP1D(0))
shaders_list = [IncreasingColorShader(1,0,0,1, 0,1,0,1)] Operators.create(TrueUP1D(), shaders_list)
ざっと流れをさらっていくと
1行目はお約束。Freestyleのモジュールをインポート。

2行目は線の選択。
blenderのシーンから作成されたViewMapから描画する線をselect()で選択する。
QuantitativeInvisibilityUP1D()は引数に渡した実数以上の視認性がある線を返す
とかそんな感じみたい。
上記サンプル中では引数が0なので、結果としてとりあえずカメラから線として
見えてるものは描画する線として選択する、という状況。
もちろん物体の影になってる陰線は選択されない。

3行目はシェーダの準備。
例えるならどんなペンや筆で2行目で選択した線を描画するかを決める感じ。
IncreasingColorShader()は線の始点から終点にかけて色が変化していくペン。
最初の4つの引数が線の始点における色、あとの4つが終点における色。
4つの引数は頭からRGBA。
なのでこの場合、描画された線は始点が赤、終点で緑になるような色の変化をする。

4行目で実際に線を描画。
create()の1番目の引数に指定されているTrueUP1D()がよくわからん。
描画する線として選択した線は内部では外形線なのか、それともカメラの始点から
山や谷を見たときにでてくる稜線なのかといった具合に細かく分類されているみたい。
で、TrueUP1D()はそういった分類された要素のすべてを返すという感じっぽい。
2番目の引数は1番目に指定された線を描画するためのシェーダを指定する。
ここでは3行目で準備した赤→緑に色が変わるシェーダを指定していることになる。

結果としてこのサンプルのスタイルモジュールは、カメラから線として見えてるものを
すべて赤→緑に色が変わるペンで描いたような出力をするという感じ。

実際にFreestyle統合版のblenderでテストするとこんな具合に。
まずはblenderでのシーンのスクリーンショット。





で、統合版のFreestyleはViewMapを見ることができないけど
このシーンのViewMapはこんな感じのはず。




サンプルのスタイルモジュールを適用したFreestyleのレンダ結果はこんな感じに。
マテリアルがデフォルトの灰色のままなのでちょっと見づらいかも。




上記の公式サイトを見るとシェーダや線の選択や作成のアルゴリズムみたいなものまで
pythonで書いて拡張できるみたい。ペンというかシェーダのパターンに画像ファイルを
指定したりとかもできるっぽい。

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

2010年1月14日木曜日

Freestyle統合が更新されたようです

Freestyle統合の公式blogを見ていると約1週間から10日ほどの間隔で進捗のレポートが
ポストされているようで毎回とても楽しみにしています。

今回の進捗分のレポートをざっと読んでみたところ、カメラの捉えているビューポートに
含まれるオブジェクトの輪郭を検出する処理や、3D空間を2D平面へ投影する際の処理など
について改善が有ったようです。この修正により安定性も向上しているようです。


で、だいたいblogのポストと同じくらいのタイミングでsvnの更新も行われているようで
さっそく2010年初のFreestyle統合の更新分をビルドしてみました。

ついでに通常のblender2.5系の開発版もビルド。

blender250-Freestyle_svn25867_gcc.tbz
blender250_svn25965_gcc.tbz
2.5系の最初の頃は3Dビューをテクスチャ表示やテクスチャードソリッド表示にすると
テクスチャを読みに行ったまま落ちることが有ったんですが、気づけばその辺も修正された
ようでいい具合です。


で、この間のデコっぱちでテストレンダしてみるとこんな感じに。
まずはblender標準のトゥーン&エッジ。




次がFreestyleのエッジ。Japanese bigbrushをスタイルモジュールに選んでみました。




選んだスタイルモジュールがある意味正解すぎでした。正月の罰ゲーム的な状態にw。
輪郭線の入り抜きの表現など自由度の高さはさすがはFreestyleといったところ。

この他にもいくつかレンダリングしてみましたが、以前のバージョンではblenderごと
落ちたり、エラーが出て正しくレンダリングされなかったものも今回のバージョンでは
安定してレンダされるようになっている感じです。すこし処理も早くなってるかも。

動作の安定性も改善されつつあり、そろそろスタイルモジュールの作成に本気を
出さざるをえない雰囲気です。

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

2010年1月13日水曜日

LuxRenderのOpenCL対応状況

公式フォーラムのこちらのスレッドでLuxRenderのGPGPUやOpenCLへの
対応について議論されていたのですが、 昨年末あたりから試験的な実装が
かなりの勢いで進んでいてびびる。

あまりの進捗の早さにここの記事にするタイミングを測りかねていたら、
いつの間にか年が開けている今日この頃。今年もたまに更新する感じで。

気づけば公式ドキュメントにもLuxrender and OpenCLという項目が追加され
LuxRenderのOpenCLとGPGPUの利用に関しての現状がまとめられています。

今のところ、OpenCLで実装された幾つかのサンプルコードが動いているようです。

その中でも興味深いのはSmallLuxGPUというサンプル。
名前の通りLuxRenderのコードをベースに一部の機能をGPUで実行出来るように
OpenCLで実装された簡易レンダラのようです。レンダリング画像も掲載されています。

開発者のDavid Bucciarelli氏のページでソースコード、Linux64bit版とwin32bit版の
バイナリも公開されています。OSX版も上記スレッドでアップされています。
当然GMA950では動きませんでしたがw。

OpenCLを利用したアプリが出てくるのはまだまだ先のことだろうと思っていましたが
意外にも身近なところで、しかも想像以上に早く出てきそうです。

blender2.5系やFreestyle統合などもあり、楽しみな一年になりそうです。


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