LuxCoreRenderたのしい。

LuxRenderの次期メジャーアップデートとなるv2.x系にむけて現行のv1.x系で

平行してLuxCoreとして開発が進められていた新レンダリングエンジン。

そのLuxCoreがとうとう正式に新レンダラとして名前も新たに

LuxCoreRenderとしてβ3版が公開されました。

ここ数日遊んでたさいにはまったことやわかったことなどメモ。

・公式ページなど各種情報

    LuxCoreRender
        公式ページ　https://luxcorerender.org
            ギャラリー    https://luxcorerender.org/gallery/

            ダウンロード https://luxcorerender.org/download/

        公式wiki　　https://wiki.luxcorerender.org/LuxCoreRender_Wiki
        git              https://github.com/LuxCoreRender

    BlendLuxCore
        git              https://github.com/LuxCoreRender/BlendLuxCore

                           機能解説や、エクスポート可能なBlenderのフィーチャなどの説明あり

    

・インストール

    上記ダウンロードページからOSに合わせて対応したバージョンをダウンロード。

    LuxCoreはblender2.79b用のアドオン版と、単独アプリとして起動可能なスタンドアロン版がある。

    さらにそれぞれにOpenCL有効版と無効版があるので要注意。

    残念ながらmacOSはダウンロード可能なバイナリがないのでソースから自前ビルドするしかない。

    多くの場合blenderにレンダラアドオンとしてインストールして使用するケースが多いと思うので

　その場合は何も考えずに各OS向けのアドオン版をダウンロード。

    blenderのアドオン管理画面から直接インストールできるzipファイルがダウンロードされる。

    LuxRenderの場合と異なりそのzipファイルの中にblenderアドオンの*.pyと一緒に

    LuxCore本体の各種実行ファイルやライブラリも全部含まれているので楽ちん。

    

    zipファイルがダウンロード完了したら、ほかのアドオンをインストールするときと同様に

    user preferencesのAdd-ons、一番下にある"Install Add-on File..."ボタンをクリックして

    ダウンロードしてきたzipファイルを選択すればOK。

    問題なくインストールされれば、アドオン一覧のところに"Render:LuxCore"が表示されるので

    チェックボックスを有効にしてこれでインストール完了。

    あとはメニューバーのレンダラ一覧のリストから"LuxCore"を選択すれば準備完了。

・GPUレンダ

　OpenCL対応GPUでできる。

　インテルのiGPU、HD Graphics520とかでもレンダできるの良い。

・HDRI

　対応してた。

　こんなかんじ。

　LuxCoreと直接は関係ないけどHDRIHAVENさんありがてえありがてえ。

・ネットワークレンダリング

　"LuxCore Network Render"ボタンをクリックして表示される
　"PyLuxCore Tools Menu"でレンダサーバの起動やジョブ管理を行う。

　Ubuntu(というかおそらくLinux全般)で、上記のボタンをクリックしても
　"PyLuxCore Tools Menu"が表示されない場合はPySideがインストールされてるか
　要確認。

　手元のLinux環境、Ubuntu16.04で試したらPyLuxCore Tools Menuが全然表示
　されないので、調べてみたらそれが原因だった。

　で、

　$ sudo pip3 install PySide

　したら、"PySideが対応するpythonのバージョンは下記の通りで、

　今のこの環境には対応してないよー！"的なエラーがでてしまう。

　ので、

　$ sudo apt-get install python3-pyside

　したらインストール完了。

　ここで、あらためてblender起動して

　"LuxCore Network Render"ボタンをクリックしたら、

　"PyLuxCore Tools Menu"が表示されたのでOK。

　そもそもLuxCoreRenderのレンダサーバプロセスを起動するには

　実はわざわざblenderを起動する必要はなくて

　~/.config/blender/2.79/scripts/addons/BlendLuxCore/binで

　$ python3 ./pyluxcoretools.zip

　してもいいらしい。

　そうするとさっきの"PyLuxCore Tools Menu"が表示される。

　NetNodeを選択して表示される"Rendering Node Configuration"の中で

　最後の"Custom LuxCore properties"にレンダリングノードを起動する際の

　設定オプションを記載できるみたい。

　おそらくその内容はLuxCoreのSDLで記述するっぽい。(未確認）

　※LuxCore SDL

　　LuxCoreで各種設定ファイル(*.cfg)やシーンファイル(*.scn)の記述等で

　　用いられているscene description language(シーン記述言語)のリファレンス

　　https://wiki.luxcorerender.org/LuxCore_SDL_Reference_Manual_v2.0

　ネットワークレンダの手順としては

　　①レンダラをLuxCoreにしておいて、いつも通りシーンの作成をblenderでやる

　　②そのシーンをLuxCoreのバイナリ形式のシーンファイル(*.bcf)としてエクスポートしておく。

　　③どこかネットワーク上の別のマシンでLuxCoreのレンダリングノードを立ち上げておく

　　④手元のマシンでLuxCoreのレンダリングコンソールを開く

　　⑤レンダリングコンソールのジョブ管理画面で②でエクスポートしたbcfファイルをジョブに追加。

　　⑥ジョブに追加したbcfファイルのある場所にflmとpngで出力が保存される。

　　⑦停止条件を設定してなければ⑥の出力を確認しつついい感じになったとこで手動でジョブ終了。

　注意する点としてはネットワークレンダするさいに、レンダラをLuxCoreにしてると
　カメラタブに表示されるカメラのオプションで、トーンマッパーが選択できるけど、
　それがデフォルの"Linear"のままだと②のシーンファイルのエクスポートの際に

　"Use a non-automatic tonemapper to get tonemapped AOVs"って警告が出て

　そのあといくらジョブを追加してレンダを進めてもなにも出力が表示されない。

　なので、トーンマッパーは"Camera Settings"か"Reinhard"に変更しておくこと。

　トーンマッピング処理だからさいしょRenderタブになんかそんな感じのオプションが
　あるに違いない。とおもって、探してたけど全然見つからずはまった。

　トーンマッパーオプションはカメラオブジェクトを選択している時だけ表示される
　Cameraタブにあるので要注意。 

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

Freestyleでエッジの分割をコントロールする

Freestyleで描線をきれいにつなげられるようになったら、次は良さげな感じに線を

分割したくなるもの。というわけでFreestyleでのエッジ分割の設定をざっくりメモ。

まずは一番簡単な長さを指定して分割する方法。

これはラインスタイルのストロークで『2D長さ』を指定します。

サンプルとしてこんな感じのシーン(下図左)をつくり、前回の行って設定をしてエッジ

が全部繋がるようにしてレンダするとこんな感じ。(下図右)

　

これに『2D長さ』を左から100、200、300と指定するとこんな感じになります。　　

次は角度を指定して分割する方法。
こちらは2D角度で指定します。

こちらもサンプルシーンをつくってエッジが繋がるようにレンダするとこんな感じ。

　

これに『最小2D角度』を90°、100°、110°と設定してみるとこうなります。

　　

最後はマテリアルの境界で描線を分割する方法。
こちらは『マテリアル境界』をONにします。

前回のティーポットで試してみるとこんな感じ。
左が前回の設定のまま、右が先端だけ別のマテリアルを指定した場合。


で、マテリアルは内容が同じでも名前が異なってさえいれば境界にエッジが引かれるので
こんな感じに、注ぎ口の端面部分で描線を分割できます。

FreeStyleで描線がつながったきれいなエッジを出す設定

昨日行われたこちらのblenderユーザーのミートアップイベントに行ってきました。
で、内容はさっそくまとめが作られているようなのでこの辺りを見ていただくとして。

今回FreeStyleを実際の作品に使用されている事例についての発表があり、その中で
3Dモデルのエッジが細かく分割されすぎたり、途切れて欠けてしまうことがある。
とのお話が。

そういえば、自分も最初の頃はそんな感じで困ってたような・・・。
じゃあ、どうやって対策したんだっけ？と改めて考えてみると、普段は設定済みの
テンプレを使っているため意外と思い出せないもので。

で、いい機会なので復習ついでに手順をまとめてみました。
それでは以下から。

まずはじめに適当なシーンを用意しました。
プリセットオブジェクトのユタティーポットを追加、Subsurfモディファイヤで
細分化レベルを3にしています。こんな感じ。

で、FreeStyleを有効にして、線の太さの指定だけ絶対→相対的に変更して、
あとはデフォルト設定のままレンダしてみます。とこんな感じに。

早速注ぎ口の下側でラインが一部欠けているところがありますね。
このレンダのエッジがどのように分割されているか分かりやすくするために
線の入り・抜き設定をつけて再度レンダしてみます。

入り抜きはLineStyleの『厚さ』に『Along Stroke』モディファイヤを追加しています。
各項目の数値は画像を参照。で、この状態でレンダするとこんな感じ。

注ぎ口の形状で、上側ラインの本体につながる手前あたりの曲がった部分と、
下側ラインの先端から左下に向かって緩やかにカーブしていく部分のエッジが
描線が細かく分割されているのがわかるかと思います。
また注ぎ口の先端の開口部の稜線もかなり細かく分割されている感じです。

で、ここからが対策です。
まずはFreeStyleのオプションで『面のスムーズさ』をオンにします。

つぎにLineStyleの設定で『ジオメトリ』に『Bezier Curve』モディファイヤを追加。

最初から『Sampling』が追加されているのでその下に『Bezier Curve』がきます。
以上で対策完了。

これでレンダしてみるとこんな感じに。

最初の画像で細かく途切れていたエッジがそれっぽい感じにつながりました。
わかりやすく比較するために入り抜きの太さに加えて、色も変えてみるとこうなります。
まずは対策前のレンダ。

次に対策後のレンダ。

描線の入り側が細く赤く、抜き側が太く青くなるように設定しています。
いい感じにつながったエッジがレンダされるようになりました。

で、実際何がどう変わったのか？といえば、追加した『Bezier Curve』で
3Dデータのメッシュのエッジを直接レンダするのでなく、それらの頂点を含む
ベジェ曲線に近似した上でそのカーブをレンダする、という感じ。

3Dモデルをいじらずともお手軽にそこそこいい感じになるので良さげです。

GTX1070 ベンチマーク Cycles・Luxrender・OpenGL

GTX1070が先日発売されましたが、3DMarkなどゲーム系のベンチマーク結果
見かけるもののCUDAやOpenCLなどGPGPU用途での評価はあまり見かけないので
やってみました。
Cycles、LuxrenderのGPUレンダリングモードで試してみました。

環境は以下のとおりです。
　OS：Windows10 pro
　CPU：Core i7-5820K
　RAM：16GB
　GPUドライバ：GeForce Game Ready Driver 368.39
　GPU：GTX970、GTX1070

ちょうどGTX1070対応の上記バージョンが入手できるようになってたので
ドライバだけ先に更新してから970のベンチマーク、換装、1070のベンチマークという
ながれで実施しました。


各ベンチマークの内容は以下のとおりです

まずはCyclesでのベンチマーク。
定番の下記リンクにあるシーンファイル、BMW27.blendでテストしています。
Cycles benchmark (updated BMW)

ただしGTX1070を含むPascal世代のGPUではシェーダーモデルのバージョンが
6.1となり、現在のblender2.77aのCyclesではこのバージョンに対応していません。
このため通常どおりにインストールしたままの環境ではPascal世代のGPUを使って
CyclesでのGPUレンダはできないのですが、下記のページを参考に対応する
cubinファイルをcyclesのアドオンフォルダに追加することで、とりあえずはGPUレンダ
が動くようになります。

GTX 1080 GPU problem when trying to render in Blender

ただし、詳細は後述しますがあくまでも『とりあえず』といった感じです。


次にLuxrenderでのベンチマーク。
こちらも定番のLuxmarkを使用しました。
今回は最新版となるLuxmark v.3.1がリリースされていたので、Binariesの項に
あるWindows 64bit用のファイルをダウンロードして使用しました。


以上のベンチマークのスコアは下記のようになりました。
スコアはすべて970, 1070の順で記載しています。
スコアのとなり、丸括弧内の値は各ベンチマーク実行時の最高GPU温度です。
温度の取得はSpeedFanで行いました。


Blender 2.7 Cycles Benchmark rev4
　1:24.51 (75℃) 1:56.54 (67℃)

Luxmark v.3.1
　LuxMark OpenCL GPUs LuxBall HDR (Simple Benchmark: 217k triangles)
　11513 (73℃) 16623 (74℃)

　LuxMark OpenCL GPUs NeumannTLM-102 SE (Medium Benchmark: 1769K triangles)
　7450 (76℃)     9516 (70℃)

　LuxMark OpenCL GPUs Hotel lobby (Complex Benchmark: 4973K triangles)
　2508 (80℃)     3517 (78℃)


以上の結果で気になるのはLuxmarkで順当にスコアが伸びているのに対して
Cyclesでの値が逆に悪くなっている点です。これはどうやら追加でインストールした
CUDAの実行ファイルが古いバージョンのSDKで作られている可能性が考えられます。
Pascal世代のGPUに対応した新しいCUDA SDKは現在α版が公開されたようですので
こちらを利用してビルドされたものを使用して、再度評価をしたいところです。

で、CyclesはGPUレンダリングにCUDAを使用しているわけですが、Luxrenderでは
OpenCLをGPGPUのためのフレームワークに使用しています。
そのためCUDAのバージョン依存の影響を受けずGTX970に対して良い結果が出ています。
またスコアは3〜4割向上していますが、ベンチマーク時の最高温度はほぼ同じ程度に
とどまっているので消費電力あたりの性能が改善されていることが感じられます。

またGPU温度に関してはアイドル時の温度が手元の環境では室温28℃において
GTX970が37℃、GTX1070が41℃でした。
これは前者がメーカーオリジナルの開放型クーラーなのに対して
後者はnVidiaリファレンスクーラーという違いが大きいかと思います。

手元のケースではGPUを挿しているスロットがちょうどケース吸気ファンからの冷たい
外気が直接あたる位置にあるため、開放型クーラーではその恩恵をうけられていましたが
筐体外排気のダクト一体となった密閉型のリファレンスクーラーでは外気が当たったと
してもあまり影響はありません。

動作時の騒音としてはGPU換装の前後での違いは自分では感じませんでした。
ベンチの結果をみても冷却に問題はなさそうなので心配ないかと思います。


最後についでにOpenGL関連のベンチマークも行ったので結果を載せておきます。

CINEBENCH R15 OpenGL
156.00 fps　153.18 fps

SPECviewperf12
catia-04　　　 50.85　 69.89
creo-01　　　 30.64　 44.69
energy-01　　　 5.81　　 8.74
maya-04　　 94.56　117.86
medical-01　　27.40　 41.82
showcase-01　60.94　　94.49
snx-02　　　　 5.80　　 6.83
sw-03　　　　 45.73　  53.96

ゲーム系のDirectX関連の評価結果はよく目にしますがOpenGLの評価結果は
CINEBENCHくらいしかみないので、3DCGや3DCADでの利用も考慮すると
GPUの買い替えなどでの判断材料が少なくていつも悩ましいところです。

SPECviewperfではMaya、catia、creo(旧Pro ENGINEER)、Solidworksなど

の3DCAD、3DCGツールの描画エンジンをベースにベンチマークを行うので、

実際の各アプリケーション、特に3DCADでのOpenGL描画のパフォーマンスが

想定しやすくおすすめです。

結果としては、価格と性能、発熱や消費電力といったバランスがGTX1070の
良いところかなという印象です。発熱や消費電力などを気にしないのであれば
時期的に値段も落ち着いた980Tiも選択としてはありかな、という感じでしょうか。

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

LuxRender v1.5RC版が公開されていた

ふと気づけばLuxRenderの開発者のひとりjeanphiさんからv1.5RC1リリースのお知らせが。
さっそくそのリリースノート的なものを訳してみたのが以下。


LuxRender v1.5RC1 release


みなさんこんにちは

バージョン1.4のリリース以降、本当に多くの進捗がありました。
そして今ここにバージョン1.5系の最初のRC版を公開することができ
とてもうれしく思っています。
バージョン1.4ではLuxRenderそれ自身にはそれほど大きな変更はありませんでした。
しかし新たなレンダリングエンジンのコアとなるLuxCoreは従来のレンダリングエンジン
であるLuxRenderとほぼ同様の機能を備えるほどに多くの機能が実装されてきました。

レンダリングスピードの改善、ガスや液体などボリュームオブジェクトの処理の改良、
新しいマテリアルとテクスチャの導入、ボリュームエミッション、ストランドの改善、
より進んだBlenderや3DSMaxやその他ソフトウェアとの統合などです。

そういった新機能がどのようなものかはこちらのwikiで画像とともに説明されています。
Reality向けプラグインの作者であるPaolo氏が新しいレンダリングモードでの10倍以上の
レンダリングスピード向上についてテストした動画をこちらで公開しています。

このRC版について何か気づいたことがあればフォーラムやバグトラッカーでの報告を
お願いします。

LuxRenderの開発に関わるすべての開発者の絶え間ない取り組みと、ユーザーの皆さんから
のフィードバックに感謝いたします。

我々のプロジェクトを気に入り、LuxRenderのさらなる改善にご助力を申し出ていただける
方にはこちらでの寄付もご検討いただければ幸いです。

今回v1.5RCの配布用ビルドは公式ページのダウンロードエリアから入手できます。

またソースファイルは下記の当プロジェクトのmercurialリポジトリから入手できます。
LuxCore: http://src.luxrender.net/luxrays/commits/tag/luxrender_v1.5RC1
LuxRender: http://src.luxrender.net/lux/commits/tag/v15RC1
LuxBlend: http://src.luxrender.net/luxblend25/commits/tag/v15RC1


バージョン1.4からの変更点を以下にまとめておきます。

LuxCoreの新機能

・OpenCLマイクロカーネルの性能改善と、OpenCLコンパイル時の負荷を低減。
・nVidiaの協力のもとOpenCL関連のパフォーマンスが改善しました。
　(基本的にはnVidiaのハードウェアに依存するものではありません）
・バイアスドパスレンダエンジンがレンダリングの精度とスピードのバランスについて
　より細かな調整ができるようにいくつかパラメータが追加されました。
・IntelのEmbreeテクノロジーを取り入れることでトライアングルインターセクションの
　より高速な処理が可能となりました。
・エリアライトによる頂点カラーの補完が改善されました。
・レンダリングの終了条件を設定して適応的分割レンダリングが可能となりました。
・オートリニアトーンマッピングが利用可能になりました。
・ライティング検証のためのイラディアンスパスが導入されました。
・Blenderとのメッシュ変換のスピードが改善されました。
・カメラレスポンスファイルが更新されました。
・metal2マテリアルにフレネルパラメータが追加されました
・blenderのプロシージャルマテリアルを標準のlxsファイルパーサでサポート
・OpenCLのSobolサンプラーが改良されました
・以下のテクスチャが刷新されました。
　substract, blackbody, irregulardata, lampspectrum,
　fresnel (color, luxpop, sopra, preset), pointiness
・サイズが大きなテクスチャ画像を使用した際のメモリ使用量が削減されました
・新しいglossycoatingマテリアルの追加
・新しい平行投影カメラの追加
・雲をシミュレーションするためのボリュームクラウドテクスチャの導入
・バンドテクスチャに幾つか新しい補完モードを追加
・strandシェイプオブジェクトのサポート
・mixマテリアルのバグ修正
・ボリューム関連のバグ修正
・ライトの処理に関するバグ修正
・OpenCLでのレンダリング時のモーションブラーのバグ修正
・hybrid CPU/GPU レンダラの削除


LuxRenderの新機能

・luxcore レンダラエンジン選択時に新しくLuxCoreに追加された機能に対応しました。
・ソースコードからのビルドがより簡単になりました。 (WindowsとOSX)
・イメージマップの位置に関するバグ修正 (幾つかの条件で1ピクセルずれていました)

LuxBlendの新機能

・プロキシに対応
・アルファ透過への対応
・マテリアルのリアルタイムプレビューを改善
　（mixマテリアルの修正、ボリュームのサポートを追加）
・ライトグループに対応
・カメラクリッピングプレーンに対応
・hitpoint data形式のテクスチャに対応
・blenderでのリアルタイムシーンプレビューとエディットモードでの多くの改善
・UIの改善（統一性と安定性向上のためコードの大規模なリファクタリングを実施）
・イメージマップの処理に関する改善
・ボリュームテクスチャの改善
・カラーランプのサポート
・パーティクルのモーションブラーに対応
・オブジェクトの可視性に関する改善
・カメラシフトへの対応
・LuxCoreの新機能への対応を追加
・領域レンダリング時のバグ修正
・ボリュームエミッションに対応


ざっとですが以上となります。
最近リリースされたばかりのblender 2.75aでもv1.5RC1は利用できたので
あれこれ試していきたいところです。



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

Freestyleのマージが完了。

というわけでめでたくFreestyle統合版ブランチがtrunkへマージされた模様。
これに関して開発者の方からコメントが出ていたのでちょっと訳してみたり。


拝啓　親愛なるみなさんへ

　皆さんの多くが既にご存知のように、Freestyleブランチとして知られている
soc-2008-mxcurioniブランチがついにtrunkへとマージされ、BlenderにFreestyleが
統合されました。この新しい機能はblenderの公式リリース、バージョン2.67の一部と
して利用できるようになるでしょう。もともとGoogle Summer of Code (GSoC)
2008のひとつとしてはじまったこのプロジェクトは、5年の開発期間ののちに大きな
到達地点へとたどり着く事ができました。
　今回の統合によってblenderは3Dのシーンデータをもとに2Dのエッジをさまざまな
スタイルで描画可能なNPR(Non Photorealistic)表現のためのレンダリングエンジンを
備える事になります。

　Freestyle統合プロジェクトは多くの人々にサポートされてきました。
このような他に例を見ないプロジェクトに携わる事ができたことにたいして、様々な
手段や方法でそれを支えてくれた皆さん、励ましてくれた皆さんに感謝の言葉を
述べたいと思います。

　そうした謝辞を述べる上で一番に取り上げたいのはMaxime Curioni氏です。
彼はGSoC2008としてのFreestyle統合プロジェクト当初のリーダーです。全ての
統合に向けた作業は彼の手により始まりました。そしてGSoCの期間が終了した後も
彼はプロジェクトをさらなるステージへと進めました。この多大な尽力が無ければ
今のFreestyleは存在しなかったといっても過言ではないでしょう。

　同じくオリジナルのFreestyleの開発者であるFrédo Durand氏、Stéphane Grabli氏、
François Sillion氏、Emmanuel Turquin氏を忘れるわけにはいきません。

　またbranchのレビューワーとしてBrecht Van Lommel氏、Campbell Barton氏、
Sergey Sharybin氏、IRIE Sinsuke氏にも多大なご協力をいただきました。
レビューのコメントや提案は統合に向けたコード全体の品質向上とBlenderオリジナルの
コードとの統一性や一貫性の改善に心強い助けとなりました。

　Freestyle統合版は多くのコントリビューターの皆さんからのコード提供により機能の
拡張や改善が行われてきました。Alexander Beels氏からはすばらしいパッチを
提供していただきました。このパッチによりFreestyleのレンダリングスピードは
条件によっては最大185倍にまで高速化されました。その成果は4ヶ月にもわたる
テストと議論の賜物です。
　Bastien Montagne氏からはtrunkへの統合にむけて大規模なコードクリーンナップの
パッチを提供していただきました。彼の忍耐強い取組みによりコーディングスタイルに
関するコードレビューがとても順調に進んだ事に感謝しています。

　Freestyleのドキュメント整備についてはその多くがユーザーの皆さんの主導で行われ
ました。その中心となったFlokkievids氏、Light BWK氏、Lee Posey(jikz)氏に感謝を。
彼らの成果は公式のBlenderドキュメントの一部、Freestyleマニュアルの初版として
皆さんのお目にかかる事でしょう。

　そして、最後になりましたが最も大切なこと、Freestyle統合版をプロジェクトの
初期から支えてくれた皆さんへの感謝を忘れるわけにはいきません。
　5年にわたるFreestyle統合版の開発はたくさんの方々、アーティストやブランチのビルドやテストを行ってくれた皆さんに支えられてきました。そういったbranch段階からの
ユーザー、特にBlenderArtists.orgのFreestyleスレッドで、書き込みを盛り上げてくれた
皆さん、バグレポートを提出してくれた皆さん、ブランチのビルドを更新してくれた
皆さん、Freestyleを利用したたくさんの作品を投稿していただいた皆さん、
そしてそこでの多くの励ましの声に助けられてきました。
　彼らのサポートとフィードバックは、このようなボランティアによるフリーソフト
開発の本質である事は疑いの無いものです。以下に支援いただいた方々のお名前を
挙げるとともに、皆さんに感謝し喜びを分かち合いたいと思います。
(すみませんがコメントやアドバイスを頂いたものの名前を挙げきれない方も多くいます。
ご容赦ください。)

3Duaun, blendman, bmania, bupla, Chris Burton, Mark Cannon
(pyrosever), Vicente Carro, Cloud_GL, crazycourier, Dazzle, delic, devroo,
Écrivain, edna, FEDB, flokkievids, Forrest Gimp, hinabita, holly, Ike AhLoe,
IRIE Shinsuke, Naoki, Nathan Letwory (jesterKing), Johan Tri Handoyo, Jonathan
Hudson, JO5EF, mzungu, Lee Posey (jikz), Light BWK, loopduplicate, macouno,
mato.sus304, mclelun, mib2berlin, Mohe & Shiratama (Moonlight Jellyfish), NRK,
octane98, pancreasboy, patricia3d, Paul Hartsuyker (paulhart2), procreaciones,
robi, Rylan Wright (RONIN), s12a, Nakeyta Schulz, Stéphane Grabli, tksg8086,
treatkor (tkroo), tungee, Uncle Entity, Unhurdof, Victor / tokiop, viralata, and yoff.

2.67の正式リリースに向けて今後はFreestyleのバグフィックスとドキュメントの整備を
中心に進めていく予定です。
今後もバグレポートやコメント、提案などいただければ幸いです。

敬具



とこんな感じ。
開発者の皆さんひとまずお疲れさまでした。
かなり早い段階から自前ビルドして使っていたので、使っていただけどはいえ
感慨深いものが。

せっかくなので統合＆2.67リリース記念で何かやりたいところ。

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

Cube買った的な。

コンパクトカーだと思った？残念！3Dプリンタでした！！的な。

とりあえず本体のみ購入。

本体には緑色のPLAフィラメント1カートリッジ、固定用グルー、ACアダプタ、
USBケーブル、USBメモリなど出力に必要な最低限のものがセットでついてくる。
で、その本体に+$150くらいで、3DCAD、好きなフィラメント3カートリッジを
セットにできる仕組み。

本体のみにするか、セットにするか迷ったけど、追加のフィラメント買うにしても、
最初に感じをためしてから選びたかったし、3DCADはblenderがあればSTL吐ける
からいいか的な感じ本体のみを購入。

で、注文から到着までは…

　2/4　白Cubeをオンラインで注文。すぐにオーダー確認のメールが来る。
　2/18 発送予定のはずだけど連絡なし
　2/22 おかしいと思って問い合わせたら白に注文が集中してて在庫切れとのこと。
　　　　銀ならすぐに出荷できます、とのことなのでオーダー変更してもらう。
　2/25 銀Cube発送のメール来る。
　3/1　到着するも不在
　3/2　土曜の午前中に再配達してもらって受け取り完了。

という感じなので、順調に行けば注文から1週間くらいで納品されそうな予感。
問い合わせはメール書けばすぐに対応してくれたのでよさげ。

で、ものは届いたものの、玄関がぱんぱんだぜ的な。

茶色い段ボールの外箱は45 x 45 x 65cmくらい。
覚悟はしていたけどでかい。とりあえず開封してく。
この外箱開けるとこんな感じで内箱というか化粧箱的なものが。

これが36 x 38 x 47cmくらい。こいつをあけると・・・

本体が。
さっそく説明書に従って設定してサンプルデータを出力したのがこんな感じ。

よさげ。次はblenderで作ったデータを…

早すぎたんだ。腐ってやがる…的なsuzanneが出力される罠。
積層の方向とか、肉厚の取り方とか調整していきたい感。

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

Freestyleの薄い本的な。

そういえばCOMITIA103でサークル、スザンぬクラブにてblenderとFreestyleによる
イラスト＆解説本的なものを頒布していたりした。

というのを当日はおろか、終了して一ヶ月近く経ってからブログに書いたりする残念感。
おもしろかったのでまたやりたい。
あとサークルブースまでお越しいただいた皆様ありがとうございました。

というかもう一ヶ月経っちゃったのか。そろそろ次のなにかをやって行きたい感。

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

W530をベンチマークしたりする。 (OpenGL・DirectX編)

前回につづいてW530のベンチマークです。

まずはOpenGLのディスプレイデバイスとしての評価です。
SPECviewperfを使用しました。

4. SPECviewperf V11.0 (モード : 自作機 / W530 の順に記載)
catia-03 : 16.47 / 22.68
ensight-04 : 10.53 / 11.77
lightwave-01 : 25.78 / 44.21
maya-03 : 34.57 / 39.75
proe-05 : 9.88 / 12.63
sw-02 : 24.90 / 30.64
tcvis-02 : 15.06 / 22.38
snx-01 : 12.92 / 17.47

GPGPU関連ベンチではFermi世代であるQuadro600にあと少し及ばない状況に
なっていましたが、OpenGLの性能に関してはKepler世代のK1000Mが優勢です。
すべてのモードでFermiを上回るスコアを出しており、
最大で約171%、最小でも約112%の値となっています。


最後にDirectXベースのベンチマークです。

5. 3DMark06 (モード : 自作機 / W530 の順に記載)
SCORE : 8128 / 9541
SM2.0 SCORE : 3138 / 3360
HDR/SM3.0 SCORE : 2815 / 3747
CPU SCORE : 6813 / 6581

こちらもOpenGLと同様K1000Mが優勢な結果に。
CPUもi5-2500Kに対してi7-3720QMが96%ほどの値となっておりなかなか優秀です。
すでにあれこれほかでもベンチ結果は出ていますが、ディスプレイデバイスとしての
KeplerはOpenGL、DirectX問わず非常に期待できそうです。

ちなみに今回DirectX10や11での比較のため3DMark VANTAGEや3DMark 11も
用意したのですが、KeplerなQuadroへの対応がまだなのか、もしくはOptimusとの
相性がわるいのかそちらはプロセスは動き続けるものの、画面が表示されなかったため
比較には使用しませんでした。


と、こんな具合にW530購入時の目論見以上の結果でありとてもよさげな感じです。
また室温30℃の環境で評価を行いましたが、CPU・GPUともに低発熱で好印象。
ベンチマークによる負荷時の最高温度としてはCPUは60℃前半、GPUは50℃後半と
いったところ。どちらも生産プロセス縮小の恩恵にあやかっているという感じです。

というわけで、よさげなW530を使い倒してあれこれしていきたいところ。


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

W530をベンチマークしたりする。 (GPGPU編)

出先でもblender含めて動画編集とかそこそこのことができる環境が欲しい感が
強まってきたのでThinkPad W530をBTOしてみました。

ちなみに現在使用中の自作デスクトップPCはこんな感じ。

・自作機
Windows7 64bit
Core i5-2500K 3.3GHz (TB3.7 4C4T)
※統合GPUはIntel HD Graphics 3000
Z68
PC3-12800 DDR3-1600 SDRAM 4GB*2
ELSA Quadro600(1GB)
2.5inch 7200rpm 500GB HDD

なので出先で自作機の8割くらいのことができたらうれしいなぁと思いつつ
BTOしたW530の構成はこんな感じに。

・ThinkPad W530
Windows7 64bit
Core i7-3720QM 2.60GHz (TB3.6GHz 4C8T)
※統合GPUはIntel HD Graphics 4000
QM77 Express
PC3-12800 DDR3-1600 SDRAM 4GB*2
Quadro K1000M(2GB)
256GB SSD

非RetinaなMBP15インチなども検討しましたがMacは今の環境からあまり変えたくないこともあったり、
ThinkPadも以前と比べだいぶリーズナブルなお値段になってて驚いたりしつつ、構成決めて即注文、
10日ほどで手元に納品されました。

で、先ほどの構成を見比べてみると
・CPUの世代はSandyBridgeとIvyBridge
・高クロックで4TなCPUと相対的に低クロックで8TなCPU
・GPUの世代はFermiとKepler
・ディスクリートGPUでもデスクトップ向けとモバイル向け
などなどの違いがどれほど効いてくるのか、気になるところです。

というわけであれこれベンチマークしてみました。


まずはGPGPU関連ベンチから。モード : 自作機 / W530 の順に記載してます。

1. LuxMark v2.0 (OpenCL GPUs)
Simple : 701 / 2556
Medium : 101 / 130
Complex : 50 / 70

2. Direct Compute & OpenCL benchmark v0.45b
DirectCompute Score : D1258.4 / D1045.7
OpenCL Score : C717.3 / C626.4
CPU Score : M50.7 / M72.1

3. GPGPUベンチマーク v1.0.1
CUDA N-Body ウインドウモード : 118GFLOPS / 76GFLOPS

blenderのCyclesやLuxRenderを利用する上でGPGPU関連の性能は気になるところ。
Quadro600、K1000M、どちらもCUDAコア数96、その他もよく似た仕様なのですが
やはりKepler世代はGPGPU用途にはあまり向いていないようです。

LuxMarkでは一見Quadro600な自作機を大きく引き離しているように見えますが
じつはこの値はHD4000とK1000Mの両方がOpenCLデバイスとして稼働してる状況。
GPU別で測定してみると、SimpleモードでHD4000単体が2100ほどのスコアなのに
対して、K1000M単体では400くらいのスコアになりました。

IvyBridgeになり統合GPUが強化されOpenCLにも対応とは知っていたものの
こうして見てみるとかなり強力になっているのがよくわかります。

長くなったのでOpenGLやDirectX関連のベンチは次で。

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

Cyclesでのレンダ時にノイズを減らすための5つのポイント

blenderの公式wikiでCyclesのあれこれを調べていたら、"Reducing Noise"というページが。
詳細に説明してあるのですが、とりあえずすぐに役立ちそうなポイントを抜粋してみました。


1. レンダラの設定に関して

・パストレースのバウンスの設定を少なくする
・バウンスの設定を多くする必要があるシェーダーの使用を減らす。
diffuse、glossy、glassの順にバウンスを計算する必要がより多くなる。
・Integratorのプリセットで"Limited Global Illumination"を選択する。
(バウンスを抑制した設定と同等。)


2. 光源

・強すぎる光源やハイライトの領域がくっきりしすぎた光源を置かない。
具体的な内容としては
・周りのオブジェクトが白飛びするくらいのランプは調整する。
・コントラストがはっきりしたマップをエミッタに使用しているならブラーをかけてみる。
・スポットライトのフォールオフ半径を多めに設定する。
といったあたり。

・ライトのフォールオフを適切に設定する。
"Light Falloff"ノードのSmooth factorで光源と物体の距離がゼロでの光の強さを設定しておく。

・室内のシーンのレンダリング
カメラは屋内、光源は屋外。窓やドアなど開口部から入る光で室内が照らされているという
シーンはよくあります。このような状況では光源のパストレースを単純にするため、開口部の
代わりにemissionシェーダを設定したメッシュライトを設置するのもノイズ削減に有効。


3. コースティクスに関して

・コースティクスを無効にする。
コースティクスをレンダするには多くの処理が必要になります。
そのための十分な計算が行われない場合にはノイズを伴います。
"No Caustics"のオプションを設定することでコースティクスを無効にできます。
ただし、その場合光源に関する処理を一部省くためシーンがやや暗くなることがある。

・はっきりしたハイライトの存在する物体にあたった光が、ぼんやりとしたハイライトを持った
物体を照らしている場合もノイズの発生源となりうる。
この場合、"Filter Glossy"を設定することでノイズを減らすことができる。
ただし、処理としては反射にブラーをかけるため正確さは損なわれる。


4. マテリアルに関して

・シェーダーのcolor要素として1.0やそれに近い値を設定しない。
値は0.8以下に設定し、値をそれ以上大きくしたいならばライトをより明るくして調整する。

・emissionシェーダを利用し、"Sampled as a Lamp"が有効な場合ノイズが増える可能性がある。

・フェイクのガラスマテリアルを利用する
コースティクスの項で説明したように、"No Caustics"を有効にするとノイズは減りますが、
Glass BSDFシェーダを適用したマテリアルの場合、影に透明度がなくなってしまいます。
そんなときはGlass BSDFとTransparent BSDFシェーダを利用したフェイクガラスマテリアルを
作成するのもひとつの手です。


5. その他

上記の各種対策を行なってもノイズが出ることはあります。画面全体に白くポツポツと現れる
ファイアフライノイズというのはなかなか対策が難しいところです。
Cyclesでは"Clamp"の設定をすることでそのようなノイズを抑制できることがあるそうです。
"Clamp"は何を設定してるかというと、インテグレータが処理した各サンプルが、レンダ画像の
各ピクセルに対してどれくらい寄与するか？という寄与率の上限を調整することでノイズを
削減する、という仕組みだそうな。

まとめたけれど、実際に試せてないもの多いので何かシーンを作りつつ検証していきたいところ。

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

LuxRender v1.0RC1がリリースされた模様。

昨年冬頃のv0.8以降正式版のリリースではなく開発者向けのテストビルドが中心となって

いたLuxRenderですが久しぶりにv1.0として正式版のリリースが予定されているようです。

今回はそれに先駆けてv1.0RC版がリリースされた模様。

というわけで以下にリリースノートをざっくり訳してみました。

皆さん、ついにこの時がやってきました！LuxRenderの新しいRC版のリリースです。

LuxRenderがプロダクションレベルの制作に用いられるような品質に到達している、

ということは頻繁に目にするようになった様々なアーティストによる使用事例から

明らかです。

今回のバージョンアップではその実績を強調するべく従来の0.xのナンバリングではなく

バージョンナンバーは1.0としました。まだ荒削りな部分はいくつか残っていますが、

今後数週間で可能な限り改善しベストなものにしたいと考えています。

よりよい正式版リリースのためにも皆さんからのフィードバックをお待ちしています。

今回配布のRC版にはSLG(Small Lux GPU)も含まれています。SLGは依然開発段階で

ありますがGPUによる驚くほど高速なレンダリングと十分な実用性を提供するものです。

今回のリリースは多くの皆さんの手によって可能となりました。そんなすべての皆様、

特にv0.8リリース以後に開発に参加してくれたメンバーに感謝の意を表したいと思います。

ダウンロードはこちらのページから可能です。

正式版リリースに向けてスプラッシュスクリーン募集のコンテストも予定されています。

以前のv0.8からの変更点は下記のとおりです。

(ご覧のように大量にあります。いくつか大幅に改善された機能もあります。今回の

"大幅な改善"は、まさに文字通りのものであり驚くべき量の作業の賜物です)

・さらに改善されたSPPM(Stochastic Progressive Photon Mapping)レンダリング

・より改善されたHybrid Pathレンダリング

・新しいHybrid Bidirectionalレンダリング

・ネットワークレンダリング時の各レンダノードへの自動再接続に関する改善

・レンダリングの速度とメモリ使用量の改善

・GUIの修正

・点光源およびスポットライトにも面光源と同様のpowerとefficacyの設定が可能に

・ノーマルマップに対応

・アニメーションレンダに関する改善

・論文に記載されているモデルにより忠実な実装になるようにcarpaintマテリアルを改善

・ボリュームオブジェクトの見た目を定義するためにcolordepthテクスチャを利用可能に

・新しく導入されたlayeredマテリアルにより、複数マテリアルを自由にレイヤーとして

　重ねることができるようになりました

・新しいglossycoatingマテリアルを適用するとどんなマテリアルにも光沢を与えることができます

・新しいfresnelパラメータではRGBカラーやミックス、グラディエーションなど様々な要素を設定できます

・metal2マテリアルは以前のmetalマテリアルよりもより柔軟な表現が可能になりました

・カラースペースに関しての修正

・linearトーンマッパーが改善され現実のライティングのしくみにより近い挙動になりました

・loop subdivisionが有効になっているオブジェクトの処理が改善されました

・Bidirectionalインテグレータの光源に関するオプションについて、direct samplingが新しくなりました

・イメージバッファの扱いがより早くなりました

・新たに導入されたSQBVHアクセラレータにより従来のQBVHに較べ、よりよい結果が

　得られます。 (SQBVHは開発中の機能になります)

・いくつかのDLL導入に伴いビルド方法が変更されました。実行ファイルサイズが小さくなりました

・その他たくさんのバグ修正と全面的な改善

・ソースコードの入手について

ソースコードが必要な方は下記のHGリポジトリからv10RC1のタグが付いたファイルをダウンロードしてください。

http://src.luxrender.net/lux/file/08ae99830f8e

SLGを含むLuxRaysやエクスポータのソースはこちら

・LuxRays: http://src.luxrender.net/luxrays/file/396d39b06aa6

・Luxblend (古い2.4系向けのエクスポータ):　http://src.luxrender.net/luxblend/file/c16130cea655

・LuxBlend25 (現行の2.6系向けエクスポータ):　http://src.luxrender.net/luxblend25/file/8c20fa83f33f

以上ここまで。

ノーマルマップが使えるようになったのは非常に助かります。

マテリアルも従来からのもの、新規追加のもの、どちらも使い勝手がよくなっているようで

いろいろ試してみたいところです。他にもGPGPU関連や各インテグレータの改善などなど

満載という感じ。

v1.0正式版リリースのタイミングに向けてこちらに新機能の解説ページも準備されています。

今月末あたりにはblenderも2.63がリリースとなりそうな状況なので、こちらも楽しみです。

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

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

camera_distortion.pyなるものが。

ある日ツイッターで目に止まったこちらのブログのポスト、

記事のタイトルを見てみると

"Mesh deform with non-uniform perspective projection"

という非常に期待せざるを得ない感じだったのでさっそく訳してみました。

いつものように抄訳かつ適当に意訳だったりメモがわりの補足も含んでいるので

正確な内容を知りたい方はオリジナルの記事を参照してください。

で、以下から訳。

今回の記事は不均等な透視投影によりメッシュを変形させるエフェクトを実装した

BlenderのPythonスクリプトのコンセプトプルーフに関してです。

いわゆるセルアニメではキャラクターがシーンに存在するカメラや視聴者の視点に

近づいた際に、現実にはありえないような極端な変形を伴った絵として描かれることが

あります。例えば、キャラクターが腕を前につきだした時などです。そのときの腕の

大きさは画面に向かって手が伸びてくるような印象を与え、迫力を出すため、写実的な

表現として適切なサイズよりも大きく誇張して描かれることがあります。

今回のスクリプトの目的はこのような誇張のための変形をblenderで実現することです。

このスクリプトの基本的な考え方はカメラとオブジェクトの頂点間の距離に対して、

カメラの焦点距離を変化させてしまうという方法です。

焦点距離はblenderのカメラがもつパラメータの一つです。これは透視投影の際に画像の

アスペクト比を定義するのに用いられています。カメラとオブジェクトの距離を変えずに

焦点距離だけを大きくしたとすると、レンダ結果の画像に写るオブジェクトのサイズは

大きくなります。

今回のスクリプトはシーンに存在するメッシュオブジェクトに対して不均一な透視投影

処理を行うことでオブジェクトを変形させています。この不均一な透視投影のための

変換行列はカメラとメッシュオブジェクトの頂点間の距離から焦点距離を算出する関数と

して定義されています。カメラからオブジェクトの頂点までの距離はそれぞれの頂点ごとに

異なるため、算出される焦点距離も各頂点ごとに異なったものになります。

わかりやすく説明するため、焦点距離が50mmと80mmという二種類の値になったとします。

シーンの遠いエリアを焦点距離50mmのカメラで、その他の近いエリアを焦点距離80mmの

カメラでレンダリングして一枚の画像として出力すると、シーンは均一なパースにならず、

結果としてシーンに存在するオブジェクトは変形して描画されます。

実際にシーンをレンダリングする際には、先ほどの例のように焦点距離の値があまりに違い

すぎると焦点距離が切り替わる部分で出力される画像が滑らかにつながらず、ツギハギの

ような状態になってしまうことが予想されます。

そのためカメラと頂点間の距離から焦点距離を算出する際には下図のように滑らかで

連続した値が得られるように非線形補完を行っています。

[図1. カメラ-頂点間の距離と焦点距離の対応]

グラフの横軸はカメラと頂点間の距離、縦軸は焦点距離です。それぞれの最大値、最小値、

途中の区間で指定している値はデフォーマのパラメータとしてユーザーが定義できます。

以下の画像は不均等透視投影による変形の効果を示すサンプルです。

左端と右端の画像は同じオブジェクトを焦点距離50mmと80mmに設定したカメラで

それぞれレンダリングしたものです。

中央の画像は今回のスクリプトを適用して変形した状態のものです。モデル足元など

カメラから遠い部分は焦点距離50mmでのレンダリング、頭などのカメラに近い部分は

焦点距離80mmでのレンダリングに似た結果になっています。

[図2. 変形のサンプル(左から焦点距離50mm、変形を適用、焦点距離80mm)]

最後に上のサンプルで使用したスクリプトのリストを示します。

使用にあたっての制限事項としては

a. このスクリプトで変形を適用できるのはメッシュオブジェクトに対してのみ

b. シーンにあるメッシュオブジェクトそのものを変形します

　(オリジナルのバックアップのためのコピーなどは作りません)。

　また、オブジェクトを実際に変形させているためアニメーションのレンダリングには

　向きません。

c. ミラーモディファイアを使用している場合は事前に適用してモディファイアスタックから

　削除しておく必要があります。

また透視投影の仕組みを利用しているため、カメラはパースペクティブカメラでないと

適切な結果が得られません。

と、こんなところでしょうか。

まさに前回ふれたPencil+のパース変形モディファイヤ的なスクリプトのようです。

訳の最後にあるように制限がいくつかあるものの非常によさげです。

なんというか、ありがたいというか申し訳ないというか。

ありがたく頂戴しつつ作成中のモデルでテストしてみる感じで。

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

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

目玉つくった

今作ってるモデルの目玉は現状ボールにテクスチャ貼っただけ。

それだとちょっとつまらないのでトゥーン用モデル向けの目玉を作ってみたり。

bloggerのテストも兼ねて動画あげてみた。

これをベースにもうすこしいろいろ仕込んでいきたいところ。

あとは拍手お返事など。

＞モデルも線画もシェーディングも良い感じですね。

＞Twitterのほうを見ていて疑問に思ったのですが
＞perspective geometry modifierとはどういったモディファイアでしょうか？
＞透視変換行列を掛けるみたいな機能でしょうか。

ありがとうございますー。

Pencil+のパース変形モディファイヤ的なことができたらなー、とかなり適当に

つぶやいていました。詳細な仕組みや原理などはよく理解していません…。

すみません。

blenderでもラティスなどでモデルを変形させたり、コンポジットノードのレンズ歪み

等で似たような効果が出せないかと試してはいるもののなかなかうまくいかず、

freestyle統合版のシェーダー、もしくはモディファイヤとして実装されたら

それはとってもうれしいなって…という感じです。

というわけで、いろいろとうまいこととっかかりがつかめれば行けそうな気もする

けれどうまくいかず…そんな具合にしばらく試行錯誤してみる感じで。

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

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

仮想化ソリューションさん続き

体ができてしばらく放置気味だったけど、頭に着手。こんな感じ。

レンダリングはblenderのFreestyle統合版。

最近コードベースが2.59になってよさげ。

眉忘れてたので追加。大事なメガネも忘れちゃいけない。

眉毛とメガネって印象変わるなーと実感する結果にｗ

髪をそろそろ真面目に作り始めないと終わりが見えない予感。

次のイメージキャラクター的なものも出てきてしまったので

ペースを上げていきたいところ。

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

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

今のところこんな感じ

前回作り始めたの、とりあえずこんな状態に。

レンダはいつもと同じFreestyle統合版blender(ver. 2.58.1)

というわけで作り始めた某M$の仮想化ソリューションさん(仮称)ですが

作業時間は１日平均30分ほど。で、ここまで2週間くらい。

今までだとこれくらいまで出来上がるのは3週目以降な感じなのでかなり早い予感。

従来は頭部から作り始めていたのを、今回あえて体からつくるようにしたのが

よかったのかも。顔から作るとどうしてもいろいろテストレンダしては、

あまり意味なく悩んで手が止まったりしてしまうので。

あとblenderのToonとFreestyleのコツがなんとなくつかめてきたのか、

イメージする結果に寄せていく際に迷走することが少しは減った気も。

昔、Lightwaveとunrealのサンプルとして見たようなセルシェーディングは

blenderじゃ無理だろなーと思っていたけれど、標準でToonシェーダがついて

Freestyle統合版なんて素敵なものができたおかげで今やかなりいい感じに。

上の画像の時点ではまだ標準のToonとFreestyleのエッジだけでノードとかは

使ってないので詳細作りこみつつ、その辺も手を加えていく感じで。

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

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

なんかまたつくりはじめた

こんな感じ。



ツイッターのTLに流れてきたのを見て突発的に作り始めちゃったけど
今月中に終わらせたいところ。

多分Freestyle向けなのは相変わらずだけど、テストも兼ねてノードで

いろいろやってみたい感じで。

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

CUDA対応cyclesなblenderのビルドとちょっとしたベンチ

いろいろ迷いつつどうにかCUDAなCyclesをビルドできるようになったのでメモ。
ついでにCPUとGPUを比較するためのちょっとしたベンチも。


・使用したOSとハードウェア構成

OS:Ubuntu10.04LTS 64bit
CPU:PhenomII X6 1055T
チップセット:785G
GPU:Quadro600

GPUはCUDA対応のものを。ここ２・３年のnvidiaのGPUであれば多分大丈夫。
以下は手元のUbuntuなPCで行った手順を記載していますが、おそらくOSXや、
WindowsのCygwinやMinGWでも同様の流れでできるかと。試してませんが・・。



・CUDA環境の準備

まずはCUDA対応のGPUドライバとSDK、ツールキット等の開発環境の準備。
nvidiaのホームページからダウンロードしてインストール。
ドライバはv270系、SDK・ツールキットはv4.0を選択。

今回使用したのは下記のバージョン。
ドライバ:270.40
SDKとツールキット:ver4.0.13

以上のものがインストールできたら、自分のGPUが対応するCUDAのシェーダーモデルの
バージョンを調べておくとあとで少しばかり楽ができる。
CUDA SDKのサンプルに含まれているdeviceQueryやdeviceQueryDrvを実行して
確認してもOK。



・ビルドの手順

事前にインストールしておくライブラリやビルドの手順はblender.orgの公式Wikiを参考にしていけば
基本的にOK。ただし、Ubuntu10.04ではデフォルトでインストールされるboostのバージョンが
1.40と古いためエラーが出てビルドが通らず・・・それに気づくまでかなり嵌りました。

というわけでより新しいバージョンをソースからビルドしてもいいのですが、ppaでboost1.42が
提供されているのでそれを利用させていただく感じで。

$ sudo add-apt-repository ppa:lucid-bleed/ppa
$ sudo apt-get update

としてaptリポジトリに追加したら、aptitudeでいつものようにインストールすればOK。

あとはOpenImageIOとcyclesなblenderのソースをそれぞれダウンロードしてビルド。
この辺は先ほどの公式wikiに記載のとおり。

CUDA対応でビルドする場合のcmakeのオプションは手元の環境だとこんな感じ。

$ cmake ../blender
-DCMAKE_BUILD_TYPE=Release
-DCYCLES_OIIO=../oiio/dist/linux64
-DCMAKE_EXE_LINKER_FLAGS=-lGLEW
-DCMAKE_EXE_LINKER_FLAGS_RELEASE=-lGLEW
-DWITH_CYCLES_CUDA=ON
-DCUDA_INCLUDES=/usr/local/cuda/include
-DCUDA_LIBRARIES=/usr/local/cuda/lib64

CPUなどのスペックによってはcubinのビルドに時間がかかるので、始めに調べておいた
自分のGPUが対応しているシェーダーモデルのバージョンだけビルドしてもOK。

でcmakeが終わったら、あとはmake、make installすれば完成。



・実行

無事にビルドがエラー無く済んだら
$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:../oiio/dist/linux64/lib
という感じにライブラリのパスを設定して
$ ./bin/blender
で起動。

いつものblenderが起動したらレンダラを"Blender Render"から"Cycles"に変更して、
プロパティウィンドウの"Render"タブに以下のようなレンダリングデバイスを選択する項目が
表示されているか確認




上の図のようにCPUとGPUが選べるようになっていればCUDAに対応したCyclesが
正しくビルドされてblenderから利用できる状態になっている。

ちなみに何か問題があってうまく行ってないと下の図のような感じ。




ここまで無事に完了したら先程のライブラリパスの設定を
~/.bashrcに書いたり、起動用のシェルスクリプトを作成しておくとよさげ。



・CPUとGPUでベンチ

で、せっかくビルドが完成したのでGPUでのレンダがどれだけ早いかちょっとテスト。
下図のデフォルトのシーンをパス256、解像度1280x720に設定してCPUとGPUでレンダ



その結果、およそCPUで2分だったものがGPUで1分30秒という具合に。
解像度やシーンを替えてレンダしてみましたが、やはり平均で25%ほどGPUの方が早い感じです。

ところで、今回使用したGPUのQuadro600のGPUコアはGF108相当。
GeforceでいえばGT430相当のローエンドなスペックです。
それでもドライバの最適化等によりOpenGLアプリでディスプレイデバイスとしての
利用であればGeforceのハイエンドモデル以上(Nvidiaの発表によればGTX580以上)の
フレームレートが出るというのが面白いところ。

しかし、CUDAやOpenCLなどGPGPU用途での演算能力としてはコアが持っているシェーダー数と
動作クロックに準じたものとなり、コアが同等なGeforceローエンド相当の性能しかでません。
ひとつ上のQuadro2000でもコアはGF106相当なのでミドルレンジのGeforce GTS450程度です。

そんなGPUでもこれだけの差が付くのであれば、安価に購入できるミドルレンジのGeforceを
GPGPU用に追加するというのもよさそうです。GTS450の2倍のシェーダーを備えるGTX560Tiでも
20k円なのでCyclesだけでなくLuxRender等でのレンダも考えるとコストパフォーマンスの点で
かなり魅力的です。


Cycles自体もまだ開発の初期なので、これから効率が改善されていく可能性も十分にあります。
また現状インテグレータはパストレーサーのみですが、それ以外のアルゴリズムを実装する
予定もあるそうなのでそれによってもレンダリングの高速化が期待できるかと思います。

ただ、Cyclesのプロジェクトの予定としては今後1〜2年の間に既存のblender内蔵レンダラを
置き換えられるものにするのが目標とのことなので、しばらく気長に追いかけてくのがよさそうです。



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

Face Bone Toolを使ってみた

前回製作中だったやつ一応完成。レンダリングはいつもどおりblender2.57系Freestyle統合版。



最初は男性素体つくろうかなっていうのと、モーション練習用になんかキャラクタデータ欲しいなと思い
作り始めたもの。ただ作ってくうちにのっぺらぼうはつまらないので顔つくって、せっかくだから髪も・・
という具合になっていってこんな感じに。

今までは口を作るのが苦手でテクスチャで済ませていたけれど今回とりあえずモデリングできた。
時間もこれくらいなら以前に比べるとそれほどかけずにできるようになってきたのもよさげ。


で、せっかくなので顔の表情をつけてみたくなったのでFace Bone Toolを試してみたり。
2.56で動作するらしいけど、2.57ではどうだろう？と思いつつ試してみたらたまにエラーが出たりする。
けれどめげずにしばらくいじってたらこんな感じにボーンとウェイトのセットアップが自動で完了してた。



とりあえずちょっと表情をいじってみた。



おもしろい。これがボタン数回押すだけでセットアップ完了するなんてありがたすぎます。
ちゃんと位置やサイズの調整をすれば適切な場所にボーンが追加できそうなので調べていく感じで。


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

4月に作ったものとか5月に作る(予定の)ものなど

最近作ってたくろいこはぎりぎり4月中に完成してこんな感じ。

CG-SNSに投稿したのは眼鏡とゴルフクラブ装備のほむら(弱)バージョンだけど

改めて見るとこっちもなかなか。どちらも捨てがたい。

GW中はblenderが2.57に移行したのに伴いFreestyle統合版も2.57系になったので、

まとめサイトのチュートリアルの方もそちらに準拠するかたちで更新。

Python Scripting Modeについての簡単な解説も追加。

で、そのあとに作り始めたのは今こんな感じ。

パキっとしたいかにもトゥーンシェーダーってのはまだ作ってなかった気がするので

そんな感じで。あと男キャラの素体も作ったことなかったのでそんな感じで。

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