2011年9月11日日曜日

camera_distortion.pyなるものが。

ある日ツイッターで目に止まったこちらのブログのポスト、
記事のタイトルを見てみると


という非常に期待せざるを得ない感じだったのでさっそく訳してみました。
いつものように抄訳かつ適当に意訳だったりメモがわりの補足も含んでいるので
正確な内容を知りたい方はオリジナルの記事を参照してください。

で、以下から訳。



今回の記事は不均等な透視投影によりメッシュを変形させるエフェクトを実装した
BlenderのPythonスクリプトのコンセプトプルーフに関してです。

いわゆるセルアニメではキャラクターがシーンに存在するカメラや視聴者の視点に
近づいた際に、現実にはありえないような極端な変形を伴った絵として描かれることが
あります。例えば、キャラクターが腕を前につきだした時などです。そのときの腕の
大きさは画面に向かって手が伸びてくるような印象を与え、迫力を出すため、写実的な
表現として適切なサイズよりも大きく誇張して描かれることがあります。

今回のスクリプトの目的はこのような誇張のための変形をblenderで実現することです。
このスクリプトの基本的な考え方はカメラとオブジェクトの頂点間の距離に対して、
カメラの焦点距離を変化させてしまうという方法です。

焦点距離はblenderのカメラがもつパラメータの一つです。これは透視投影の際に画像の
アスペクト比を定義するのに用いられています。カメラとオブジェクトの距離を変えずに
焦点距離だけを大きくしたとすると、レンダ結果の画像に写るオブジェクトのサイズは
大きくなります。

今回のスクリプトはシーンに存在するメッシュオブジェクトに対して不均一な透視投影
処理を行うことでオブジェクトを変形させています。この不均一な透視投影のための
変換行列はカメラとメッシュオブジェクトの頂点間の距離から焦点距離を算出する関数と
して定義されています。カメラからオブジェクトの頂点までの距離はそれぞれの頂点ごとに
異なるため、算出される焦点距離も各頂点ごとに異なったものになります。

わかりやすく説明するため、焦点距離が50mmと80mmという二種類の値になったとします。
シーンの遠いエリアを焦点距離50mmのカメラで、その他の近いエリアを焦点距離80mmの
カメラでレンダリングして一枚の画像として出力すると、シーンは均一なパースにならず、
結果としてシーンに存在するオブジェクトは変形して描画されます。

実際にシーンをレンダリングする際には、先ほどの例のように焦点距離の値があまりに違い
すぎると焦点距離が切り替わる部分で出力される画像が滑らかにつながらず、ツギハギの
ような状態になってしまうことが予想されます。

そのためカメラと頂点間の距離から焦点距離を算出する際には下図のように滑らかで
連続した値が得られるように非線形補完を行っています。

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

グラフの横軸はカメラと頂点間の距離、縦軸は焦点距離です。それぞれの最大値、最小値、
途中の区間で指定している値はデフォーマのパラメータとしてユーザーが定義できます。


以下の画像は不均等透視投影による変形の効果を示すサンプルです。
左端と右端の画像は同じオブジェクトを焦点距離50mmと80mmに設定したカメラで
それぞれレンダリングしたものです。
中央の画像は今回のスクリプトを適用して変形した状態のものです。モデル足元など
カメラから遠い部分は焦点距離50mmでのレンダリング、頭などのカメラに近い部分は
焦点距離80mmでのレンダリングに似た結果になっています。

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

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

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

a. このスクリプトで変形を適用できるのはメッシュオブジェクトに対してのみ
b. シーンにあるメッシュオブジェクトそのものを変形します
 (オリジナルのバックアップのためのコピーなどは作りません)。
 また、オブジェクトを実際に変形させているためアニメーションのレンダリングには
 向きません。
c. ミラーモディファイアを使用している場合は事前に適用してモディファイアスタックから
 削除しておく必要があります。

また透視投影の仕組みを利用しているため、カメラはパースペクティブカメラでないと
適切な結果が得られません。



と、こんなところでしょうか。
まさに前回ふれたPencil+のパース変形モディファイヤ的なスクリプトのようです。
訳の最後にあるように制限がいくつかあるものの非常によさげです。
なんというか、ありがたいというか申し訳ないというか。
ありがたく頂戴しつつ作成中のモデルでテストしてみる感じで。

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

2011年8月22日月曜日

目玉つくった

今作ってるモデルの目玉は現状ボールにテクスチャ貼っただけ。
それだとちょっとつまらないのでトゥーン用モデル向けの目玉を作ってみたり。
bloggerのテストも兼ねて動画あげてみた。


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

あとは拍手お返事など。

>モデルも線画もシェーディングも良い感じですね。
>Twitterのほうを見ていて疑問に思ったのですが
>perspective geometry modifierとはどういったモディファイアでしょうか?
>透視変換行列を掛けるみたいな機能でしょうか。

ありがとうございますー。
Pencil+のパース変形モディファイヤ的なことができたらなー、とかなり適当に
つぶやいていました。詳細な仕組みや原理などはよく理解していません…。
すみません。

blenderでもラティスなどでモデルを変形させたり、コンポジットノードのレンズ歪み
等で似たような効果が出せないかと試してはいるもののなかなかうまくいかず、
freestyle統合版のシェーダー、もしくはモディファイヤとして実装されたら
それはとってもうれしいなって…という感じです。



というわけで、いろいろとうまいこととっかかりがつかめれば行けそうな気もする
けれどうまくいかず…そんな具合にしばらく試行錯誤してみる感じで。

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

2011年8月18日木曜日

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


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



レンダリングはblenderのFreestyle統合版。
最近コードベースが2.59になってよさげ。

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



眉毛とメガネって印象変わるなーと実感する結果にw
髪をそろそろ真面目に作り始めないと終わりが見えない予感。

次のイメージキャラクター的なものも出てきてしまったので
ペースを上げていきたいところ。

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

2011年7月31日日曜日

今のところこんな感じ

前回作り始めたの、とりあえずこんな状態に。
レンダはいつもと同じFreestyle統合版blender(ver. 2.58.1)



というわけで作り始めた某M$の仮想化ソリューションさん(仮称)ですが
作業時間は1日平均30分ほど。で、ここまで2週間くらい。

今までだとこれくらいまで出来上がるのは3週目以降な感じなのでかなり早い予感。
従来は頭部から作り始めていたのを、今回あえて体からつくるようにしたのが
よかったのかも。顔から作るとどうしてもいろいろテストレンダしては、
あまり意味なく悩んで手が止まったりしてしまうので。

あとblenderのToonとFreestyleのコツがなんとなくつかめてきたのか、
イメージする結果に寄せていく際に迷走することが少しは減った気も。

昔、Lightwaveとunrealのサンプルとして見たようなセルシェーディングは
blenderじゃ無理だろなーと思っていたけれど、標準でToonシェーダがついて
Freestyle統合版なんて素敵なものができたおかげで今やかなりいい感じに。

上の画像の時点ではまだ標準のToonとFreestyleのエッジだけでノードとかは
使ってないので詳細作りこみつつ、その辺も手を加えていく感じで。

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

2011年7月20日水曜日

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

こんな感じ。



ツイッターのTLに流れてきたのを見て突発的に作り始めちゃったけど
今月中に終わらせたいところ。
多分Freestyle向けなのは相変わらずだけど、テストも兼ねてノードで
いろいろやってみたい感じで。

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

2011年5月18日水曜日

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

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


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

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

GPUはCUDA対応のものを。ここ2・3年の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拍手

2011年5月17日火曜日

Face Bone Toolを使ってみた

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



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

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


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



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



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


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

2011年5月12日木曜日

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

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



CG-SNSに投稿したのは眼鏡とゴルフクラブ装備のほむら(弱)バージョンだけど
改めて見るとこっちもなかなか。どちらも捨てがたい。


GW中はblenderが2.57に移行したのに伴いFreestyle統合版も2.57系になったので、
まとめサイトのチュートリアルの方もそちらに準拠するかたちで更新。
Python Scripting Modeについての簡単な解説も追加。


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



パキっとしたいかにもトゥーンシェーダーってのはまだ作ってなかった気がするので
そんな感じで。あと男キャラの素体も作ったことなかったのでそんな感じで。

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

2011年4月18日月曜日

LuxRender v0.8RC3がリリースされた模様。

フォーラムでv08RC3のリリースノートがでてました。めでたい。

v0.8RC2からの変更点は・・・

・GPU支援によるパストレーサー関連のバグフィックス多数
・カメラレスポンスがプリセットに内蔵されました。別途CRFファイルを用意する必要はもうありません。
・IPv6ベースのネットワークをサポート
・マイクロディスプレイスメントの処理速度が向上しました
・IESファイルを使用したエリアライトに関するの問題を修正しました
・ファイル名の扱いに関する処理を改善しました。(パスの区切り文字、\と/に関する問題です。)
・STL形式のメッシュデータの読み込みに対応しました。
・GUIに"advanced"タブを追加。レンダラの設定に関する詳細な情報はこのタブに表示されます。
・blender互換、およびPBRTテクスチャを使用する場合、マッピング座標としてローカル座標、
 UV座標、ノーマル座標を利用出来るようになりました。
・エリアライトのテクスチャにimagemapもしくはbilerpを指定していた場合に光の強度が
 おかしくなっていた問題を修正しました。
・GUIにレンダリングの停止ボタンが追加されました。
 これによりレンダリングを一時停止することも、完全な停止もできるようになりました。
・LuxRenderのネイティブ形式のファイルにデータの埋め込みができるようになりました。
・EXR出力を選択した際にRGBに対してアルファチャンネルの乗算を行わない状態での出力も
 選択できるようになりました。(アルファチャンネルの乗算が行われる動作が一般的です。)
・トーンマッピングとポストエフェクトの設定をファイルへセーブ/ロードできるようになりました。
・多数の修正と改善を行いました。

といった感じ。
公式wikiにもv0.8の新機能についてのまとめがあるので、そちらも参考にするとよさげ。


予定としてはv0.8のRCは今回で最後となるようです。順調に行けば次がfinalということでしょう。
また、先日blender2.57がリリースされたことに合わせて、luxblend25の動作の安定化をblender2.57を
対象としてすすめていくそうです。

RC3がリリースされたばかりで次の話をするのは気が早過ぎるかもしれませんが、v0.8finalの
スプラッシュスクリーンのコンテストが現在行われており、その締切りが5月12日になっています。
おそらくv0.8finalは5月中旬あたりにリリースされるのではないか?という感じです。

しばらくはblender2.57とLuxRender v0.8の組み合わせが安定かつ標準的な環境になりそうです。

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

2011年3月28日月曜日

バランス調整中

前回の続き。くろいこ今のところこんな感じ。



頭身のバランスはそれっぽくなってきた感が。
細かいところの作り込みはまだまだなので横からみると今いち。



前回の赤い子よりもポリゴン多め、できるだけモデリングでつくり込むことを目標につづく感じで。


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

2011年3月21日月曜日

つぎを作り始めたり。

とりあえず今こんな感じ。



前回のあかいこを作ったおかげで少しは作業が早くなった感が。
今回も放置してモチベーション下がらないようにすすめたいところ。


あとは拍手お返事とか。

>CGにアップされているほう、エッジがきれいに出てますね。グッジョブです。
CGの画像はFreestyle統合版を使ってエッジを描画しています。
ポリゴン投稿を考えていたものの、エッジをだすための反転ポリゴンはデータの方に準備して
なかったので・・・。データもポリゴン数が少なくあまりエッジを出すのに向いてないかなーと
思っていたので、Freestyleのおかげでどうにかなった感じです。


>詳細な紹介記事ありがとうございます。
プロジェクトの公式ブログで開発進捗に合わせた有益な情報が公開されており、こちらこそとても
助かっています。今回もオプションが追加された事はUIを見て気づきましたが、オプションの意味や
内容の理解、プロジェクトの状況などを知ることができてよかったです。


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

2011年3月19日土曜日

Freestyle統合版のレンダリング高速化について

Freestyle統合版が更新されて、ビューマップの構築に関して大規模な改善がおこなわれ
レンダリングが大幅に高速になった模様。

公式ブログにこれに関する記事があったので冒頭をざっくり訳してみました。

以下から。


ビューマップの構築はFreestyleのレンダリングプロセスで最も時間がかかる工程です。
実例として規模が大きなシーンになると考えられないほど処理が遅くなってしまいます。
開発の人手やリソースが十分ではないため、全てのToDoの項目が完了し、頓挫していた
トランクへのマージが完了した後で、この問題の解決にとりかかろうとしていました。

しかし昨年12月に我々Freestyle統合に関わる開発者たちのもとにAlexander Beels氏に
よって大規模なコードが提供されました。彼が提供してくれたのは、まさに先ほど述べた
ビューマップ構築の最適化を実現したコードでした。彼はビューマップ構築のプロセスに
おけるパフォーマンスのボトルネックを特定し、内部のデータ処理を注意深く再設計して
最適化を施していました。

12月の最初のバージョンを足がかりに、プロジェクト開発チームと協力してAlexander氏に
よるパッチに対してコードレビューとテストがくり返し行われました。彼は複数の異なる
最適化の方法の模索と実装に多大な貢献をしてくれました。3ヶ月の間ひたすらテストと実装を
行い、それは非常に効率のよいビューマップ構築のコードとして結果が実ることになりました。

このコードはFreestyle統合版ブランチのリビジョン35525として採用されています。
以下にいくつかテストシーンでのレンダ結果を載せていますが、この最適化コードにより
驚くべきパフォーマンスの改善が行われていることがおわかりいただけるかと思います。

Alexander氏のすばらしい成果にこころからの感謝を!


ここまで。

という感じ。
元記事には上記の概要に続いて技術的な面からの解説やオプションの説明、テスト結果などが
記載されています。ここでは実際に使用する上で知っておくとよさそうな内容を中心にメモ。


今回のパフォーマンスの向上はFreestyleによるレンダリング処理の中でビューマップ構築に
関する部分に対して行われた最適化による結果。具体的には、ビューマップ構築のなかでも
『シルエットエッジの検出』と『エッジの視認性の計算』の部分で改善が行われたとのこと。

で、これらの改善、特に『エッジの視認性の計算』のアルゴリズムに関わるオプションとして、
Freestyleの設定に"Raycasting Algorith"というオプションが新しく追加されました。



このオプションでエッジの視認性計算に関わるアルゴリズムを以下の7つから選択可能に。

・Normal Ray Casting
・Fast Ray Casting
・Very Fast Ray Casting
・Culled Traditional Visibility Detection
・Unculled Traditional Visibility Detection
・Culled Cumulative Visibility Detection
・Unculled Cumulative Visibility Detection

最初の3つはオリジナル(おそらく統合以前のスタンドアロン版)のFreestyleで利用可能だった
ものと同様のアルゴリズムとのこと。"Normal …"がデフォルト、"Fast …"と"Very Fast …"は
正確さと引き換えにエッジの視認性の計算においてより高速な処理を実現するものです。

それ以下の4つが今回の最適化で導入された新しいオプション。
おすすめは"culled cumulative …"か"unculled cumulative …"で、将来的にはこの2つが
メインのオプションとして残る予定らしい。

じゃあ、"… Traditional …"って何なのか?とか、"Culled …"と"Unculled …"の違いは?と
気になったので調べてみたら以下のような感じ。


・"Traditional"と"Cumulative"の違い

今回エッジの視認性計算のアルゴリズムに関して手が加えられたことで、改善されエッジの
視認性に関してより安定した値を算出するようになった新しいオプションが"Cumulative"。
ただし、当然これは従来のものとは別のアルゴリズムなので、同様のシーンをレンダしても
従来と結果が異なる可能性がある。そのため最適化を行いつつ従来のアルゴリズムと同様の
結果がでるようにエミュレーションしたものが"Traditional"。


・"Culled"と"Unculled"の違い

culledとunculledの違いはカメラに写る領域に対してcullingを行うか否か、という点。
culledはカメラの視角外の領域(つまりレンダリングする必要のないエリア)を処理に含めずに
エッジの視認性の計算を行う。これにより処理速度は向上するけれど、除外されたエリアとの
関連性によってはレンダ結果においてエッジの連続性に影響がでる可能性があるとのこと。
unculledはシーンに存在するデータすべてを対象としてエッジの視認性の計算を行うもの。
なので、直接はカメラに映らないけどエッジの連続性に影響を与えるようなオブジェクトが
シーンに存在する場合などにはこちらの方がよさげ。


以上のTraditionalとCumulative、CulledとUnculledの組み合わせで新しいオプションは4通り。
で、ざっと見た感じCumulativeの方が良さそうで、場合によりCulledとUnculledを使い分ける
感じかなーとなるので、おすすめは先ほどの2つということらしい。


最後に、従来と比較してどれくらい高速なのかという部分。

いままで単純なシーン、オブジェクトだとFreestyleによるエッジ描画の有無であまり違いは
無いけれど、シーンが複雑になるにつれ急激にエッジ描画の部分に時間がかかってくる感が
ありました。

今回の最適化の結果としてその辺が改善されたのか、複雑で規模の大きなシーンほど従来と
比較して、処理時間の削減率が高いという数字がでているようです。シーンが大きく複雑に
なるに従って、今までの十分の一、百分の一という感じ。

詳しくは元記事の下の方に記載されている表を参照のこと。



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

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

2011年3月15日火曜日

赤いひと完成。

前回のFreestyle統合版blenderでつくり始めたのが完成。

赤い子こんな感じ。









レンダしたのはCGに投稿してみた。

ほんとはポリゴン投稿にしようかと思ったけど、ちらつきがなくせなかったので
プリレンダで投稿。初めてだったので対策とかよくわからなかった・・・。
データの仕様とかももう少し調べてから始めればよかったかも。
そのうち別の作ったらリベンジしたい感じ。

とはいうものの、ポリゴン投稿でぐりぐりして見れるようにテクスチャベイクしたり
データ整理とかして準備したので、せっかくだからこちらに上げてみたり。
DLパスは taiyaki です。今週いっぱいくらい置いとく予定。


今回は一ヶ月かからなかったので今後もこれくらいのペースで作っていきたいところ。
佐倉杏子の次は美樹さやかを作るべきだろか・・

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

2011年2月25日金曜日

Freestyle統合版でつくり始めた

ふと気づいたらこんなの作っていたり。



契約とかしませんから・・・。したのスザンヌまで邪悪な存在に見えてしまう罠。

思いつきで作ったとはいえ、これだけだと残念な感じが否めず。
せっかくだからついでに誰かつくろうと思ったものの、誰を作るか悩んだ末に
まずは赤い人からつくり始めてみた。

今のところこんな感じ。


細かいとこは後でもう少しつくり込む予定だけどフリルめんどくさそう。
これまでのに比べてそれなりに作業は早くなっているような。
とはいってもこの後放置してしまう可能性も無くはないので
まぁそんな感じで。


あと拍手のお返事など。


>Lux8、出たんですねー Render の Engine を hybrid
>Integrator を path ・AdvancedをONにして
>DirectLightをoneにしたらGPUレンダリングできましたー
>しかしbender2.4には入れられたけど2.5系は相変わらずまだっぽいですかね?
>いまいち2.4、2.5系でレンダリングが変わったっぽいのが分かり辛いです

開発版のluxやslgではかなり前からレンダリングのGPU支援は利用できていたので
目新しさはあまり無いのですが、v0.8finalに向けた今回のRCにOpenCL対応が
取り込まれたというのはバグフィックスなどの点で非常に意義あることだと思います。

RC2に向けて2.5系への対応も含めて他にもいろいろ動きがあるようで楽しみです。

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

2011年2月15日火曜日

LuxRender v0.8RC1がリリースされた模様。

リポジトリのバージョンタグにv08RC1が追加されていたのでそろそろだろうと
思っていましたが・・来ました、LuxRender V0.8RC1。

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


みなさんこんにちは

新しいLuxRenderのリリースのお知らせと共にフォーラムに戻ってきました。
今回のバージョンはまだ最終版ではありませんし、いくつかの機能はまだ改善が
必要な部分が残っています。しかし、このリリースが楽しんで利用していただける
内容になったと確信しています。そして、よりよい最終版リリースに向けてユーザーの
みなさんからのフィードバックを注意深く見守っていきたいと思います。

このリリースはOpenCLによるGPUアクセラレーションを実装した最初のバージョンに
なります。まだ開発中であり、全てのグラフィックカードやドライバで利用可能という
状況では有りません。そのためLinuxとWindows向けには2つのバージョン(OpenCL
サポート版と非サポート版)を用意しました。

もし対応している環境であるにもかかわらず、OpenCLサポート版を使用して問題が
あった場合にはぜひ我々に知らせてください。問題が起きた場合でもOpenCL非サポート
版であれば使用出来るはずですので、我々が問題を解決するまではそちらを試してみて
ください。

今のところpathインテグレータで一つの光源からのサンプリングを行う設定の場合のみGPU
アクセラレーションが有効になります。

また注意すべき点として、いきなりGUIを終了させるとデータの保存や一時ファイルの
削除などが行われずにレンダリングが中断されてしまいます。
レンダリング時の自動ファイル保存の間隔を長く設定している場合はGUIのウィンドウ
を閉じる前にメニューからセーブするのを忘れずに行ってください。

今回のリリース実現に向けてご協力いただいた皆さん、特にドキュメントの作成に
関わった方々に感謝いたします。このあともヘルプや関連情報のアップデートなど
多くの作業が残っています。ユーザーの皆さんや各種エクスポータの開発者の方々が
LuxRenderをより便利に使うための手助けとして、これらのドキュメントが役に立つ
ことを願っています。

V0.8RC1のバイナリはこちらの新しいダウンロードページから入手できます。


v0.7.1からの変更点は下記のとおりです。
(wikiのv0.8の新機能に関するページも参照してください)

・新たにGUIでレンダ結果を保存する際に、ライトグループの扱いやレンダリング情報の
設定が可能になりました。

・glossytranslucentマテリアルが追加されました。これは植物の葉などの
レンダリングに使用することを目的に開発されたものです。

・フィルムレスポンスカーブで実在するカメラのカラーレスポンスのエミュレートが
可能になりました。モノクロフィルム向けのカーブも含まれています。

・pathレンダラでLight strategyをOneに設定した場合にGPUアクセラレーションが
利用出来るようになりました。

・GUI版のレンダリングキューに複数のジョブを追加してバッチ処理を行うことが可能に
なりました。

・メッシュのサブディビジョンを利用している場合に分割されて独立している頂点も
正しく扱われるようになりました。

・ライトグループの処理が刷新され、ライトの色を調整した場合により精度の高い結果が
得られるようになりました。

・レンダリングプロセスにおける不適切な処理結果を除外するフィルタを実装しました。
(メモリの使用量とレンダリング時間は僅かに増えますが、ノイズは大幅に削減されます。)

・Extend Photon Mappingモードとしても知られている、PBRTレンダラのImproved
Photon Mappingプラグインと同等の機能が全て実装されました。

・bandテクスチャーが更新されより複雑なグラデーションが表現可能になりました。

・v0.7で導入されたボリュームアブソープションに加え、ボリュームスキャッタリングも
利用可能になりました。(現在のバージョンでは均一なボリュームでのみ利用可能です。)

・ply形式のメッシュデータを読み込む際の四角ポリ、テクスチャ座標、
サブディビジョンなどの処理が改善されました。また、従来はlux独自形式の
フォーマットでエクスポートされてましたが、外部ツールでの利用を考慮し
ply形式でエクスポートされるようになりました。plyの読み込みやエクスポート処理も
改善されより早くなっています。

・オンザフライでのマイクロディスプレイスメントがサポートされました。
メモリの消費をおさえつつ、より詳細な凹凸の表現が可能になります。

・その他多数のバグフィックスと改善を行いました。


とこんな感じ。

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

2011年2月5日土曜日

Freestyleのチュートリアル書いたり。

ここでたびたびblenderのFreestyle統合版についての記事を書いてたけど
インストールからレンダリングまでの一連の流れを説明したチュートリアル
っぽいものはまだやってなかったはず。

なのでサイトの方にblender2.5系のFreestyle統合版のチュートリアルを
書いてみた。

Freestyle -> チュートリアル

あとustreamのアカウントとってみた。
日付が変わるころに作業配信をしてたりするかも。よろしければどうぞ。

tmn_blndr on USTREAM

そんな感じ。

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

2011年1月31日月曜日

blenderクラッシュしても泣かない

前回の続きをやっていたらblenderが落ちたので気分転換にこんなの作って
しばらく遊んでいた今日この頃。



こっちはこっちでもう少し体を作りこんだらスカルプトの練習用に使いたい感じ。

あと、blenderが落ちても慌てず騒がず、『泣く前にFile→Recover Auto Save...
すればかなりの確率で復旧できるっぽいのがわかったのでよさげ。

そんなことやってるうちに気づけばblender勉強会だったりしたり。
気になっていたRigifyの使い方やPython&addon、Unity関連などなど
興味深く、ためになる内容。

勉強会後に参加した懇親会ではツイッターでフォローさせていただいている
方の数名とお会いすることができたりと、非常に有意義な一日でした。
楽しかったー。


勉強会の様子はUstreamで配信された映像が録画されアーカイブとして
視聴
することができるようになっています。
また当日使用された資料やファイル等も主催である日本ブレンダーユーザーグループ
勉強会用教材リンクからダウンロードすることが可能です。

当日参加できなかった方、勉強会のことを今知った方などはそれらを参照して
みてはいかがでしょうか?


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

2011年1月25日火曜日

髪とりあえず作った

細かい調整は必要だけどとりあえずひと通りポリゴンで面貼り終わり。



最初に正面から始めて、それ見ながら横と後ろ合わせていってこんな感じ。



前のモデルでblenderで髪作るときにどうしても作成した面があさっての場所に
できてたり、逆にめり込んでしまったりといい位置に持ってくるのが難しかったので
今回はちょっと頭を使ってShrinkWrapを使ってみたり。
なかなかよさげ。

今回の作業はustreamで配信しつつやってみたり。
時間を決めて配信するぞと始めると意外に集中できていい感じ。

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

2011年1月21日金曜日

blenderとMake Human

Make Humanはだいぶ昔に試していたのですが、その当時は安定していなかったり
blenderでのインポートがうまくできないことがあったりいまいちの印象でした。

が、ふと最近、現行のバージョンを試してみたらblenderでインポートも問題なく、
blenderで取り込んだ状態でモデルにボーンやウェイトマップまで適用済み。

というわけでいま作成中のデータ用のボディをMake Humanのモデルをベースに
作ってみたのがこんな感じ。



ちなみにインポートしたままのオリジナルデータはこんな感じ。



Make Humanのコンフィグで性別や体格といったパラメータを操作して
体型を調整できますがイメージに近い物とつくろうとすると、大まかな
調整だけMake Human側で行ってblenderで修正する方が良さそう。

結局イメージした形状に近づけつつ、面の流れが自然になるように、blenderで
ほとんどの頂点・ポリゴンをいじっているのでそれなりに手間はかかります。
それでも、ゼロから面を貼っていってフルスクラッチで作るのに比べれば
最初から人のかたちになっているのでとても楽ちん。

今回作成中のモデルはSubSurfなしでトータル5500ポリゴンを目標にしています。
冒頭の状態で2000ポリゴン程なのでとりあえずこのデータをもとに作業を続けて
いく感じで。

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

2011年1月20日木曜日

モデリング三日目。

髪つくろうと思ったら、よく見たら耳が微妙にでてるので急遽耳追加。
毎度のことながら耳は手こずる。ぐりぐり回してさらに全体を調整。



で、ここから髪作成開始。まずは3Dビューに背景画像追加。



背景画像はモデリング用の仮テクスチャと同じ物。で、ガイドも表示。



画像を参考に正面からざっくり髪のあたりをつけていく感じ。



で、正面のラインにあわせて側面もなんとなくあたりをつける。
正面から見ると背景画像があるので違和感を感じにくいかもしれない。
けど、正面のラインを参考にしつつ引いた側面のあたりをみると、3次元の
立体としては髪のボリュームがありすぎなのがわかる。

というわけでその辺の2次元と3次元のつじつまを合わせつつよさげな感じに
モデリングしていく作業はこれからだったりするわけで。

そんな感じで続く。

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

2011年1月16日日曜日

モデリング続き。二日目。

頭のポリゴンひと通り貼り終わり。



今日はあまり進まなかった・・というか、頭部が出来上がるとチェックと修正と
称してFreeStyleで遊んだりするから進まないという噂も。
ただこれも前回と比べれば後頭部のポリゴンのまとめ方や顎から首にかけての
面の貼り方などをあまり迷わず作業をすすめられているので大分早くなった感じ。

明日は髪の毛を終わらせたいところ。

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

2011年1月14日金曜日

次を作り始めたり。

最初の板ポリが



こんな感じになって



こうなるまで結構不安w。ちゃんと頭の形になるのかと



ここまでくればあとはぐるぐる回しながら修正



こんな感じの一連の作業に前回は二日ほどかかってたけど、今回はおよそ2時間で完了。
最初のカエルの次に人物のモデリングをやったのは、かなりハードルが高かったけど
いい勉強になってた感じ。

前は途中で放置しちゃうとモチベーションが下がる -> するとまた間があいてさらに
モチベーション下がるという悪循環に陥るというのはよくわかったので今回は計画的に
さくさく進めていきたいところ。


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

2011年1月10日月曜日

Luxrenderでフィギュア風な感じにレンダしてみるテスト

とりあえずボーン入れてポーズ取らせられるようになったのでやってみた。



実際のレンダは作業フローのテストも兼ねて上記の倍の解像度でレンダしてます。
サイズが大きいのでオリジナルはこちらにアップしてみたり

作業の流れは、Macbookでblender2.5系を使用してボーンやウェイト設定などの
データ作成まで。2.49bでデータを開いてLuxrenderのシーンファイルを書き出し。
Ubuntuのレンダサーバにluxのシーンファイルを渡してluxconsoleでレンダリング。
luxはhg版のv0.8devを自前でビルドしたものを使用。

ある程度sppを積み上げられたら一時中断して、GUIのluxrenderで再開して
様子を見ながら各種エフェクトを適用していくという感じ。

今まではネットワークレンダでやっていたけどある程度時間をかける、もしくは
時間がかかるのがわかっている場合は今回のようにレンダサーバに丸投げの方が
いいかも。

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