バランス調整中

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



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



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


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

つぎを作り始めたり。

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



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


あとは拍手お返事とか。

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


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


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

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拍手

赤いひと完成。

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

赤い子こんな感じ。









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

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

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

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

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

Freestyle統合版でつくり始めた

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

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

思いつきで作ったとはいえ、これだけだと残念な感じが否めず。

せっかくだからついでに誰かつくろうと思ったものの、誰を作るか悩んだ末に

まずは赤い人からつくり始めてみた。

今のところこんな感じ。

細かいとこは後でもう少しつくり込む予定だけどフリルめんどくさそう。

これまでのに比べてそれなりに作業は早くなっているような。

とはいってもこの後放置してしまう可能性も無くはないので

まぁそんな感じで。

あと拍手のお返事など。

＞Lux８、出たんですねー　Render の Engine を hybrid

＞Integrator を path ・AdvancedをONにして

＞DirectLightをoneにしたらGPUレンダリングできましたー

＞しかしbender2.4には入れられたけど2.5系は相変わらずまだっぽいですかね？

＞いまいち２．４、２．５系でレンダリングが変わったっぽいのが分かり辛いです

開発版のluxやslgではかなり前からレンダリングのGPU支援は利用できていたので

目新しさはあまり無いのですが、v0.8finalに向けた今回のRCにOpenCL対応が

取り込まれたというのはバグフィックスなどの点で非常に意義あることだと思います。

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

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

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

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拍手

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

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

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

Freestyle -> チュートリアル

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

tmn_blndr on USTREAM

そんな感じ。

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